Advertisements
  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 24 other followers

  • Archives

Systems thinking avoids wastes

Systems thinking avoids wates in any environment. Here we look ways that helps avoiding wastes in software.

Over estimated time and efforts : Teams thought process is calculate each and every team member’s individual tasks and add up the total. This is a gross mistake and contributes to lots of waste as unproductive time in project progression. How? Welcome to Critical Chain project management of Theory of Constraints. Calculate the total effort required for the project completion and add project buffer as a central buffer available to total project. This way not only the project progress is focussed, it also creates an atmosphere of system thinking among the team members and every one starts to focus on project rather than individual productivity. Scaled Agile Frame work (SAFe) have addressed this to a certain extent.

Advertisements

Kaizen-Kanban Keys of continual improvement

Yesterday’s post shared thoughts about how multi tasking could lead to decreased productivity in project management activities. We have also briefly touched upon how group reviews can help overcome burden of a project manager who handles multiple projects. Kanban diagrams and kaizen principles can be coupled to address the multi project multitasking challenges. While Kanban is a great tool in visualization of project milestones with clear visibility to all stake holders, kaizen is an improvement tool that provides continual improvement functions to key activities. Visibility to all stakeholders coupled with continuous improvement means projects and people perform progressively as they move along the milestones. In Agile projects the impact of the Kanban-Kaizen will be reflected in the improved velocities between successive sprints and releases. These tools in addition providing direct impact on productivity of projects that applies these, they collect the process assets and knowledge along the way. These lessons learnt will be key assets for the organization for learning and development for future projects

Group reviews avoids bad multitasking

Multitasking : Much used term in management especially in services sectors like IT. Theory constraints sees multitasking as an activity which mostly reduces the productivity. If a project manager has to run three projects simultaneously with three different customer domain (which is the case generally in SMEs) say retail, health care, BFSI etc he/she  will be mostly doing management of people deployment and the progress of deliverables. All the three customers will be equally demanding the deliverables w.r.t to agreed milestones, as per schedule with acceptance criteria for the quality (that’s the very reason the projects are given to the It vendors)

If the project manager is focusing on all the three projects, with tight deadlines from all of the, switching between tasks and projects will be tasking and will create much pressure on the project manager. This will lead to none of the projects are delivered on time or even if that be the case there will be compromise on quality or extra resources deployment. Any of these symptoms is an extra cost due to non value addition caused by bad multitasking. We are not talking here about a multi skill and trait a manager need to posses in terms of leadership, technical competency, managerial acumen or communication abilities. These are all multi skills which will be naturally used by an effective project manager during project management (as against multitasking).  Having special horizaontal groups like Subject matter expertise, advanced technology group, Software  Process Engineering group, Business Analysts, UX group and using their exprtise to do reviews at appropriate levels and phases will ease out the pressure from project teams. This is one way an organization will improve overall productivity which help teams avoid bad multitasking.

Just my thoughts. Please share your views on this.

System thinking helps superior products development

I have discussed about CTQ and CTC in this post about Agile development addresses Critical to Quality and Critical to Customer dimensions.

As Quality and Customer requirements have become more clear due to the collaborative nature of Agile and Lean Development, products are developed faster and better. No issues upto this. Another parameter along with ‘better and cheaper’ that needs to be inbuilt is cheaper (competitive context), this where the flow and systems thinking that need to be embraced within the organization and its customers and suppliers.

Theory of constraints (TOC)  offers Drum buffer rope, Critical Chain project management and Thinking tools to address this third critical parameter (cheaper = competitive) of any product. Processes can be automated to the possible and required limits. However Thinking process differs from project to project depending upon the many stakeholders involved. It takes domain, experience and System thinking skill sets to achieve the smooth flow . lean and TOC have their focus mainly on Systems thinking and on careful, patient and full application of these management models, super productive systems can be achieved.
Continue reading

Budgeting for success

Budgeting – for sales, production, inventory, finance, quality, testing, new initiatives, Research and many more functions / departments is done as per the context and the focus of any organization. Organization take into consideration factors like  revenue streams, cost of compliance, support and future business etc.

Best results will be accrued by reducing operating expenses  and minimizing inventories. inventory. Theory of constraints key focus is around these premises. While it is understandable in principle on reducing operating expenses  and minimizing inventories, in practice it is not very easy to achieve this goal. How can we make a positive difference in realizing these improvements? One way could be after identifying budgets for each and every function, the leadership should look at the interfaces and interplay between multi departments and then work out suitable budget booth in terms of cost and effort. To understand the interplay and interfacing activities, it is better to set up a small team by choosing good champions from each department and create one interrelationship maps between all the teams and leadership together. Then every six month this interface map should be reviewed and revised as per the current realities.

Now it will be easier for management to understand the effort and cost allocation and budget to the each team. After the allocation, the champions teams  can take their respective teams into confidence and impress upon them about details. This way organization will have more probability for smooth sailing as flow.

Team work between domains

Teamwork – When did we perform best and felt elated about reaching our targets / goals at work? Just think on these lines whenever there are challenges due to competition, complexities, changes, technical advancement or any change agent that is coming your way.  Perhaps the solution will come to us by deeply analyzing about our best performances in the  past , someone else’s best performance about how did they beat all odds to become successful in what they did.

Sometimes, you get ides and insights from external sources like domains completely unrelated to you. Keep watching Ted Videos, and other platforms both in digital and non digital spaces. I am sure it will throw a lot of new ideas that will be refreshing. Agile, SAFe, LeSS, PMI have all been inspired some way or the other from Lean Manufacturing, Toyota Production System, Systems Thinking, Supply chain domains. Now Agility have improved upon these models and mapped to IT environments by created great concepts like Scaled Agile Framework (SAfe) and impacted breakthrough improvements in the way software products / services are delivered. Not only this, Agile concepts have started giving back to manufacturing on the improvements and new thought processes where manufacturing gets benefited. This way the system of systems keeps evolving. Let us be attuned to Systems thinking.

Convergence is the key strength

Convergence of all sub system produces one super system called organisation.

Light getting dispersed through Prism produces brilliant colours like Rainbow. The White light sums of all the seven colors and shines forth brilliantly.

Sales, pre sales, account management, development, business analysts, testing teams, UX, HR, Facilities, Administration, Finance and Leadership all put together form a brilliant organization. We can’t say Red color is better than blue , green is better than yellow et al. All departments are components of a great chain, and the interfaces between them are links that binds the values of the organization.

If one or few of the interfaces / links get too much stressed out or lagging, rest of the teams and interfaces can get into huddle with the struggling interfaces and can offer their support to improve the working. This is self-organization in Agile, subordinating all activities to critical constraints in Theory of Constraints, Systems thinking in lean. Different  models, similar values.

Gemba Walks Evaporates cloud

Gemba walks by Leadership teams occasionally to the desks where action is happening will be a great boosting moral for the teams. However it needs to be performed without giving a feel like micro managing of teams. Some ways and thoughts on Gemba walks by senior management.

Visit to the real place and seeing teams putting their work , genuinely understanding if the teams need more support in terms of tools, training and helping hands in resolving any technical issues goes a long way in having empowered employees. Teams will not only be happy they will also go to the extra miles bracing any limitations on their way.

Gemba walks originally designed for operations place like shop floor reviews, we can use the spirit for motivating people to become empowered.  This way Gemba walks rings true with Evaporating cloud phenomena of Theory Of Constraints. (TOC)

Quality Assurance (process) key focus

Quality Assurance (Process QA) function in IT organizations are normally viewed as compliance and certification function.  What are the ways by which Process QA can get more attention?

QA should capture the best metrics that define the business and its growth dimensions. Typically Throughput of the product / services delivered by organizations are super effective indicator of the business and its progress.

QA should design the processes considering key critical success factor for maximizing the throughput of the organization. It will be better to have the Top down approach in identifying the business objectives and then deriving at the project level objectives. Measure team’s outcome and not individual’s output.

How are the Win4all factors integrated in formulating the throughput metric?

Does each and every department’s / program’s processes are focused towards attaining this Win4all?

Since QA has more visibility with most of the departments of the organization, they should proactively work with all teams and enable the entire system works towards achieving / exceeding organizational goal.

Avoid Creating an impression that QA is compliance function . Go to teams during normal working days. Don’t focus only during audits.

Being empathetic and understanding about Business processes: Each and every team might be different, make metrics and processes relevant to the team based on their contexts

Only measure Team metrics relevant to business

Share industry knowledge and latest trends through links, materials, webinars etc  to team.

Update your  technical skills of the core functions to a level where you get some useful inputs as to how best the team’s process can be tailored.

Appreciate good work always and don’t just restrict to raising non conformances.

Process should be enjoyable as the end product.

Co create innovation.

 

What’s in it for me? – harmonize all stakeholders expectations

What’s in it for me?

If me = Employer,  it will be employee productivity, employee billing capacity, employee developing himself / herself and the teams, employee loyalty, et al.

If me = Customer, it will be Faster, Better and Cheaper not in any particular order, it will be trust, trust about feeling confident that the customer data, design, requirements, proprietary assets are safe with vendor, it will be vendors help customer’s business grow

If me = Supplier, it will be good business, show casing of vendor’s capabilities that delights customer, repeat business and of course invoices getting paid on time, referrals and testimonials

If me = Statutory and Regulatory bodies, it will be good compliance to regulations and applicable acts.

If me = Project manager, it will be mile stone completion by teams, less attrition, cooperation and team development

If me = team member, it will be good work that satiates their technical appetite , good growth for them in the corporate ladder, motivation, work life balance et al.

Then we have other categories like research and development team, testers, finance, sales and marketing where we can derive the “whats in it for each one them” if they are equated to “me”?

How the enterprise understands all the “in it for me” considering all the “me personalities”  will determine the business in the long and short-term. There is need for creating total organization’s “in it for me” by combining all of the individual “in it for me”

Some of the awesome concepts like System thinking, Theory of constraints, Lean and Total Quality management either independently or in combination can improve the harmony of the organizations.  Great leaders have been able to demonstrate in all walks of lives, this super enlivening harmony and created lasting positive impressions.

 

Key considerations for new initiatives

Some key considerations for deciding to go with any initiatives to get maximum success.

  • Boosting Employee morale
  • Increasing the ROI to all stakeholders
  • Helping to get Decisive competitive edge
  • Believing in inside out approach
  • Doing it when size is relatively small and then sustain while scaling
  • Self driven in line with market trends
  • Improving the Automation efforts
  • Helping in scaling
  • Leading to Systemic benefits not local efficiencies

What are your thoughts?

 

 

Risks and opportunities – interplay

Risks and opportunities

Risk – has been in focus of Management for many years since initial industry years.  We had Quality control, Quality Assurance, Total Quality Management, Project Management et al . Each of these and many other management suits discussed and implemented Risk Management with reasonable success.

As regards  to Opportunity – its identification , nurturing them, taking organizations / units towards break through improvements have been discussed through Lean, Toyota production system (this is an exception in that it has been for many years) , Agile frameworks and some other models relatively  recently. Much less done in terms of implementation.

Risks and opportunities have been complimentary, opposites and mutually exclusive. Sometimes controlling risks will lead to opportunities. For example retaining great talents by managing attrition, leads to great products and in turn result in company’s growth.  Here identifying the attrition as risk and managing it served as a great opportunity (complementing activities) for business growth.  Automation of business processes and deliveries to a large extent improves productivity and cut the costs of labour / manual effort.  Here the opportunity is mutually exclusive of any risk. Keeping the stakeholders like customers, employees and suppliers in a balance of serving their best requirements could be sometimes be seen as reduced satisfaction among some group of the stakeholders. For example, if outsourcing takes major chunk of an organization’s activities suddenly, this will impact the employees count or reduce their contribution suddenly owing to business requirements.

IMHO it is a challenge for any organization to continuously innovate by bringing new changes in terms of technology, automation, management models while keeping the current work force happy and feeling motivated. One way it can be done is to leverage the premise of Global outlook recommended by System thinking principle of Theory of constraints. Involve people at all levels, make the operations flow smoother by managing critical bottlenecks.

What are your views?

Improving productivity by proactivity

Some ways to improve productivity and reduce non value added activities / wastes :

Use Agile practice of stand up meeting discussing three key questions :

what tasks are planned today,

what were the tasks executed yesterday and

what is the main bottleneck

Encourage group reviews – this reduce waiting time and avoiding duplicate questions from different people who might have same views. Quick response to customers and stakeholders, Complete team will be in sync.

Involve Senior management – to the critical decision and commitment for the programs on needed basis.

Learn, develop, test, relearn and again learn

Leverage common teams Create pool of teams / tribes – for domain, technology, security, innovation and communication. Leverage them for all projects

Evolve, change and adapt to not only technology but innovative thinking too.

Gemba walks and Thinking tools

Gemba walks principle has been successfully used in many manufacturing Industries. It means ‘the real place’. Taiichi Ohno from Toyota believed and leveraged these concepts to a great extent in Toyota.

Toyota believed that the activity is happening in the shop floor, operations area and not in conference rooms. This led to Gemba walks in production and operational areas and the executives were able to get direct inputs on machines, working, men and all their issues.

Using Five WHY techniques asking the right WHY’s during the Gemba walks produced brilliant solutions. The deep root causes can be identified and systematically eliminated by observing what is happening in the real operational floor. In TOC too, thinking tools like Current reality tree, conflict clouds (Evaporating clouds) are very useful in depicting the real picture of current problem. Cause and effects are categorized and analyzed in detailed steps and finally Undesirable effects are identified. These Undesirable effects are prioritized and treated using thinking tools like future reality trees and prerequisite trees etc.

Though the models Lean and TOC are called in different names, the central focus in both of them are  ‘the real place’ . Gemba walks are used in observing, identifying and eliminating the real harmful effects to produce grand solutions.

Bottleneck – neither over load nor starve

Systems’s view of any organization is like a chain connected by links. TOC sees the weakest link as determinant in deciding the strength of the chain.  Taking one step back we need to identify the weak links / bottlenecks and make them fit in the perspective of the entire chain.

If there are ten processes for producing a product / service, there will be a bottleneck process which needs to be regulated  to ensure the smooth flow happens in the production line. Suppose if process no 5 is a bottleneck, it will process the product line at lower rate compared processes 1-3, and that will leave the downstream processes 6-10 waiting with delays. These waiting times are waste (non value added process) and increase the cost of the product directly due to long cycle times. Inventory is also getting built up at process 5 that will have cost impact depending upon the product nature.  The aim of the system should be to ensure bottleneck is relieved of its inventory and waiting time. It should neither starve nor over accumulating the work in progress due to slow capacity.

People are good – all roles matter

We keep seeing leader vs manager debate in many social media platform, inside the company and other places. While most of them give a big thumps up for ‘Leadership’ with all the great qualities and attributes it truly deserve. This post I want to look at the Leader, Manager debate as a wholesome perspective. Any organization irrespective of flat or structured will have leadership team that will be a small fraction say around two percent of the whole company.  Some of the leaders have made it to the top by being excellent managers of their respective assignments.  So can we not think a manager to be a future leader, getting evolved continuously. Algebra need to go before calculus.  As most of the organizations need manager roles and few leadership roles, we need to have traits of both leader and manager in different combination at various roles and levels.  Whether a leader or a manager it would be great to be non judgemental, open minded and seeing the whole picture from wherever every one are placed. This way everyone one in the organization remain motivated and feel self confident in their role.

In a software application all layers (presentation, interface, database, server et all) matter. All roles are equally important right from business analyst, developer, UX engineer, tester, release administrator, QA etc. Sales and other support functions play a vital role in meeting customer expectations. Same way in an automobile hundreds of parts required for awesome performance, right from nuts and bolts to engine, gear box, wheels, electrical components etc.

IMHO best things will happen by having an open mind and being non judgemental. Happy Global optimization!

Lean practices for endorsement to great initiatives

Project managers and delivery teams always get concerned over what should be the minimum criteria for any project  to apply and comply with standards like ISO 9001(Quality Management), ISO 27001 (Information Security Management) or CMMI or any other standard per se?

While it is easier to be enforcing on any project regardless of their size and nature to follow standards completely, the stakeholders need to be  clear and convincing on enforcing these. QA folks, auditors, senior management / relevant stakeholders , if start insisting all teams be comply with x number of policies, y number of procedures and z number of templates without demonstrating the outcome / returns, any initiative be it ISO / CMMI / TOC / Lean will fail in the long run for sure. In service organizations there are cases like many simple maintenance or bug fixing projects that are executed. QA teams coming up with long checklists of “Do’s and Dont’s” covering 100+ specific and generic practices of CMMI and multiple controls from ISO 27001, will demotivate the teams and resources permanently. All initiatives need to start much before certifications. This can be achieved by designing the processes as “Just enough”, Lean and Agile. Over a period of time teams embed these practices using tools and would have become “the way we do things here”. Then certifications / initiatives will be easier, sustainable and successful. You get certified / assessed to certain standards / practices by endorsement and not by ‘conformance’.

What do you say?

You before I, TOC vibes

In my earlier post UB4I, I briefly touched upon how Agile development is pro-people and has ingrained team spirit in its working methods.

As I have also gained over few years experience in Theory of Constraints (TOC), I see there is a greater synergy of this UB4I (You before I) spirit.

In its Four pillars of ‘Inherent Simplicity’, ‘Every conflict can be resolved’, ‘People are good’, ‘Never Say I know’  TOC is replete with the great team / organizational phenomenon of working as a whole and for the whole.

Estimation is one area that is posing great challenges for large teams particularly in software  development. Many factors can be sources for incorrect and inaccurate efficiencies.  Complex requirements, too many scope creeps, market conditions influence  accuracy of estimates.  TOC helps here by focusing on only three basic metrics like Turn around time, Operating expense and Inventory costs.  Operating expense is defined as the money system spends to convert inventory into Through put.  Here the focus is only on the system throughput and not on individuals / project level.  Team will be highly motivated and will have solid clarity of the role and expectations from them to align to the system’s Goal. IMHO, I see this as inherent simplicity.

Agile and Lean software development focus on collaborative development and working. Greater visibility for all stakeholders, involving vendors right from requirement stage / product design stage, create a super positive environment for great product development and innovative solutions. Daily sharing of the progress of the release and sprints with customer and solving any issues / conflicts by shared understanding lead to quality products to customer and confidence to vendors. I see this as ‘Every conflict can be resolved’ principle of TOC.

Self organized teams, feeling of ownership and common goals in terms of stories to be burnt by team and its members, truly vibe with ‘People are Good’ pillar of TOC.

Systems thinking is one of key component of Scaled Agile Framework (SAFe). Typically many groups (some times called tribes) like Technical Architect, Domain experts, Compliance team and other types of subject matter experts work in harmony to produce innovative products and solutions. Here the matching principle of TOC is   ‘Never Say I know’, implying many teams and teams of teams work in cadence.

 

 

 

 

 

SIPOC for organizational policies

In identifying context of the organization , ISO 27001 / ISO 9001 standards recommend to look for external parties / internal stakeholders under common term called interested parties.

Let us try to understand these using SIPOC methods. Understanding the needs and expectations of interested parties – SIPOC way

Supplier Inputs Process Outputs Customer
Customers Functional, Non functional, Information Security, Legal and statutory requirements Request for proposal, Contractual requirements, Scope of work Agreed contractual requirements, features and needs statement, Statement of work Software Vendors
Senior Management Organizational mission, vision and policies Organizational policies, procedures, code of work, Key Responsible Areas. Codified procedures, statements and Roles and Responsibilities Employees
Delivery and support functions Expectations and roles statements Communication during project / functional induction and work activities

 

Task Assignments, Team management expectations, targets, etc Team members / employees

Learning and Development, a system’s endeavor

Learning and Development – feels better than training and development, with due regards to ‘Training and development’.

Any initiatives when started will go through pilot to programs. Samples / case studies of concepts will add more confidence and assets (knowledge based). So any principle / concept / paradigm gains more insights as much as it provides the knowledge to the user community when implemented. Similarly people who take training to participants pick up more insights on their own subjects. Every participant is the source of sharing knowledge when he/she asks questions / add views to the teachings of the trainer.

This is akin to “Never say I know” pillar of Theory of Constraints. Learner, learning and learned all contribute to System’s improvement.

Innovative problem solving methods

Problem : A two digit number. 10th place has value 3 times that of unit place. When the number is reversed it is 54 lesser than the original number.

Effective solution : —> 10 (3x) + 1( x) – 54 = 10(x) + 3x

Step 2 –> 31x – 13 x = 54

18x = 54 , x = 3.

Step 3 —> no is 93, reverse is 39 which is 54 less than 93.

Quick solution:

possible two digit numbers satisfying the condition could be :

31

62

93

on quick elimination we can see 93 starightway fits the solution.

However we cannot possibly work quick solution, if the question to be found are a multi digit say 5 digit or more in these perumutation / combination. Hence we need to write generic program / alogorithm that can be used for each problem as per the complexity involved.

That my friends, as regards problems of numbers or math involved. In reality when organizations are facing abstract problems about major decision like make or by, outsource or develop, offshore Vs onshore development, there very many different factors that come into play. It will take a combination of management models to work and solve. Some of the great models are Theory of Constraints specifically Thinking processes tools, Lean and Enterprise agility, TRIZ et all.

People are Good – a key pillar of Theory Of Constraints (TOC)

People are Good. One of the four pillars of Theory of Constraints.

How does project information flow from an Analyst to Sales to Program / Account Manager to Project Manager to Developer?

While in most cases Functional requirements, Non functional requirements (performance) do get transmitted along the organization levels till developer. Does the developer have Information Security related requirements for the applications he is supposed to develop in time? Does he have domain specific requirements? What about information related to legal and regulatory requirements that are required to be followed by development teams?

Availability of product information from all perspectives mentioned above will help the project team to meet the customer expectations to full extent. In some of the projects I have managed there were views expressed by developers / testers, that they would have carried out their tasks effectively had they known the complete requirements of product right from the beginning as regards to security, legal and any other non technical requirements.Surely team will do a great job in building righ product at right delivery schedule with right data available at right time.

Proactively eliciting technical and all other requirements by the project managers and sharing just relevant data about them to project teams will make the team feel confident. Confident teams will have high level of motivation and build excellemmnt products.

Trust the team, share relevant data. People are Good to go for the Goals.

Premise fit – TOC vs Lean

Complimenting premise of Lean and TOC:

Lean Theory of constraints
Muda – Non value added activity or waste

Example – Reworks, multiple check ins of source code

Constraint exploitation and subordination of non bottlenecks to the main bottleneck. Taking help from horizontal teams. Availing surplus efforts from team that can contribute
Mura – Inconistency Each individual teams having local goals / objectives for their projects / functions not relating to the oveall Goal of the organization
Muri – Excessive strains in the system Too many localized measurements that takes time and effort and ultimately not solving the system’s goal. TOC recommends only three metrics viz., Throughput, Operating Expenses and Inventory. These are directly related to Organization’s goal units. Any other metrics that do not map to Goals is waste that should be avoided.

Theory of Constraints – improvements by creating TOC culture

Improving the culture through TOC within organizations.

While the real big benefit is achieving the Goal of the organization concerned that implements TOC, there are many additional benefits that get accrued by some of the great concepts of of TOC.

In the Critical Chain Project Management, TOC advocates to use buffer at the project level by cutting down sizable individual task estimates. This will create a culture (if implemented in spirit and action) that will enjoy sharing their extra time/effort to the real bottleneck issues of the organization Goals. This culture is partly practised in Agile implementations by forming groups / teams who work at horizontal layers to all projects of the organization. These organizational groups contribute in multiple ways like tech reviews, automation, release practices, Quality Assurance activities for all the projects in scope. If core project teams itself start looking at providing project buffers rather than at individual levels, real breakthrough improvements will occur in projects that will slowly radiate towards organization as a culture. Leadership and senior management should appreciate and support TOC practices with patience to reach this level.

These are some of my views would like to hear from your experience on this.

 

Theory Of Constraints (TOC) – Some applications

In my experience I have used TOC approaches successfully in some occasions. In addition to TOC as a core innovation and improvement tool, TOC practices like Drum Buffer Rope and Thinking process likes Current Reality Tree, Future Reality Tree, Evaporating Clous, Pre requisite tree and Transition trees can be of great help in pre sales / sales processes, resource management, decision making when there are close conflicts and many project management areas.

When we face situations like client prospects give incomplete problem statement (because they might not be also having full data on problems) , we have tried to draw trees like Current Reality, Future Reality and Evaporating clouds with the information provided by the prospects. It turned out that prospects got more ideas from these trees and further gave more data and clear problem statements. It helped both parties and the solution mapping was effectively defined and implemented.

Similarly we used Critical Chain Project Management concepts of keeping project buffers by cutting some percentage of individual tasks buffers that fetched us more benefits like on time delivery with high quality of products / services and of course customer satisfaction.

Drum Buffer Rope techniques were used by some programs very effectively leading to better flow and lesser waiting times in the product / service work flow.

Whats your expereince on applying TOC application?

When we face situations like client prospects give incomplete problem statement (because they might not be also having full data on problems) , we have tried to draw trees like Current Reality, Future Reality and Evaporating clouds with the information provided by the psopects. It turned out prospects got more ideas from these trees and further gave more data and clear problem statements. It helped both parties and the soloution mapping was effectively deined and implemented.

Similarly we used Critical Chain Project Management concepts of keeping project buffers by cutting some percentage of individual tasks buffers that fetched us more benefits like on time delivery with high quality of products / services.and ofcourse customer satisfaction.

Drum Buffer Rope techniques were used by some programs very effectively leading to better flow and lesser waiting times in the product / service work flow.

Whats your expereince on applying TOC application?

Challenges in applying Theory of Constraints (TOC) in service industries

Some Challenges in applying Theory of Constraints (TOC) to service industries.

Dynamic business demands of the customer types 

In Small and Medium Enterprise segments with their varied customer types, its difficult for the projects / teams to arrive at common Goals of the enterprise. Each account is driven by customer processes and they tend to follow the work flow / engagement style of the customers. It is possible to have best practices defined at the company level, and even complied by teams to a good extent by all teams. However at best these could be conforming to some best practices of standards like PMI / CMMI /ISO guidelines. Aligning the work flow to Throughput maximization, one of the key metric of TOC may not be possible as the standards and practices do not lead to organization goals at a common level in practice.

Leadership commitment in supporting TOC approach

Since the adaptation of TOC in the services are not many, leadership is skeptical on the services sector for initiating TOC. Also the nature of services in providing diffrent types of solutions to different customers make its difficult to arrive at common unified TOC Goals for the organization. Though in the recent times some implementations are happening successfully, when compared to manufacturing sectors the ratio is much less.

Identifying the Goals

Product companies might find it easier when compared to service industries in identifying TOC goals, owing to the nature of complex customer base and their requirements.

Identifying the bottlenecks

Even if Goals are identified, finding the right priority bottleneck to attack will take long time and analysis. Since most of organizations these days follow Agile practices, they teams and organization will not have much patience to invest time and effort in finding bottlenecks let alone resolving them

Evaporating Cloud

Adi Sankara’s gem of a work is “Viveka Chudamani” (Crest Jewel of Wisdom) – In this there’s verse that talks about the nature of the Sun ( philosophically represented as Knowledge) and cloud. A line form that work goes here:

“The formation of clouds generated by the Sun’s rays come to veil the very same Sun and appear clearly manifest in the sky..”

In Goldratt’s Theory of constraints, one of the thinking tool talked about by Goldratt is Evaporating Cloud (EC). EC is about finding a solution to a conflict between two parties or points of view.The method requires participants to find win-win solutions. In my experience of working on improvements in some projects / programs, I came across situations like team / program heads mostly focusing on the initial project releases and do the planning and allocating resources / budgets just for the initial release. However in the long run (for the entire life cycle)the projects / programs end up spending heavily than what they originally budgeted for. This is a case of not looking at larger picture, the Goal ( Life Cycle planning) and trying to cut costs by improving local efficiency ( initial release budgeting).

Does this ring true for you in your work situations?

One Global Optimum

Sage of Kanchi, Mahaperiyavar has given a great reference of Non-Duality (Advaitha) appearing in the Elegy penned by great poet Shelley for John Keats. Here goes a piece from the elegy with explanation from Mahaperiyavar.

The One remains, the Many change
Heaven’s Light forever Shines, Earth’s shadows Fly
… Life like a dome of many-coloured Glass
Stains the White Radiance of Eternity!”

Sage in his inimitable style explained the above verses like :

One remains – refers the permanent nature of the Absolute entity. (Adwaitha Philosophy). Many change refers to the changing nature of plurality (Dwaitha philosophy). He goes on to explain the “many-coloured Glass Stains the White Radiance of Eternity!” in an awesome manner as follows:.

Just as White light when enters the prism it gets separated into many colours , the Absolute One entity manifests as many on getting reflected at individual levels.

I was awestruck on reading the explanation of the part of the Elegy. It rings true with Eli Goldratt’s Theory of constraints where he recommends achieving One Global optimum as Goal as against focusing on local efficiency at individual levels.

Happy New Year 2018!

 

Form (ever) Follows Function

Ice, Water and Steam- Three forms of the same source serve different purposes. Each form serves multiple unique purposes. Force fitting these forms for functions not meant for them, don’t help and fails miserably.sample

This is a great natural example of “Form Follows Function” theory expounded by great architect Louis Henry Sullivan through his favorite design phrase, “form (ever) follows function,”

All great concepts like SAFe, LeSS, Lean,etc do insist on achieving the Goal collectively as an engaged organization. TOC nicely summarizes and advocates to Increase the throughput to maximum using leverage points / constraints.  Choosing a or a combination of any concepts before applying to any program should be judged by the function it should deliver rather than fitting the function into the templates of pre-determined concepts.

Common causes of failures of new initiatives in my experience are attributed to predetermined “Management flavor of the season” initiatives rather than focusing the function that need to be served.

What is your experience? please share your thoughts.

Release the Air, let the Value Flow

An engineer (Tech Arch) in a car manufacturing company designs a world class car.

While trying to bring out the car from the plant area, they realized car is few inches taller than the entrance. (Root Cause – Not factored all non functional requirements – Test and user environment set ups incomplete)

Engineer felt bad as he has not factored this requirement.

Painter (UX engineer) suggested they can bring out the car and there will be few scratches that can be touched up later on. (Applying patch after retrospective = extra cost)

Engineer suggested breaking the entrance (More cost, schedule delay), taking the car out, and later redoing the entrance.

A Gate Keeper was observing and remarked “Sir, the car is only few inches taller than the entrance, so simply release the air from the tyres, which will reduce the height and then you can easily take out the car”.

slide1

In TOC, this is an example of Inherent Simplicity and Never say I know – two key pillars of TOC.

Lean stresses this in its Lean Principle Respect People

In Agile parlance, it is involving all stakeholders during design retrospective (apart from Tech , DEV team include support teams as relevant) and be open minded and good listener.

Don’t look problems always from expert points of view.

There’s always a layman’s outlook that might provide an alternate solution.

Inherent Simplicity – A Key Pillar of TOC

 

Organizations have been finding it difficult to gather metrics data and trends that are directly impacting the business objectives. This pain is more pronounced in software organizations.

Dr Eliyahu Goldratt advocates that if we map causes, effects and opportunities, then reality turns out to be very simple. He calls this great concept as Inherent Simplicity – the home ground for TOC.

InSimple

The Metric Y can have many input parameters Xᵢ to Xn.

Business Objective  -> Program/Project Metrics   Y = F (X)

There are many  metrics(Y) we derive like Productivity, Velocity, Effort deviation, Schedule deviation, Defect slippage, Turn around time for resolving bugs / defects, Rework and more. While there are different categories of Y,  in most of the metrics that business needs to monitor and achieve is just two input parameters(X) Size (number units )and effort (time. Days) to arrive any metrics. Since we know for sure input variables (X) are just two i.e size and effort, it is important for the organizations to ensure capturing these inputs data accurately while the tasks are carried out in the system. From these accurate simple data organizations can derive metrics that are relevant to them.

Do you have any examples that used simple solutions to address large points. Please share.

TOC – 3,4 and 5. Putting all together

TOC  Framework  – Three key points

What to change:  The system pains points that are needed to be changed.
To what to change to:  To be state.
How to cause the change:  Mechanism to be adopted.

TOC  – Four Pillars

Inherent Simplicity.
All Conflicts can be resolved.
People are Good.
Never Say I Know.

Five Focusing steps.

Identify the Constraint
Exploit the Constraint
Subordinate to the constraint
Elevate the constraint
Go to step 1

 

DOD for Agile rationale – UB4I

UB4I  – DOD for Agile rationale 

Value delivered is the most effective metrics in Agile. Prioritization by Product owners  and relevant stakeholders make the user stories for first few sprints.

‘Don’t measure people but product’ paradigm is best  represented by Agile model.

You before I mindset is the greatest skills for an Agile team member. Like we have definitions of done for various  stages of Agile product development, an attempt at DOD for successful Agile practitioner is UB4I.  

Some traits for UB4I

  • teams share their work expertise
  • caring for other issues
  • Committed to common Sprint and product goals
  • pitching in whenever team requires help
  • Collaborative
  • co-creative
  • Be a product developer as against coder
  • wearing multiple hats in the projects

please add on…

 

Lean lifts Muda drags

Lean lifts Muda drags

Logic for lean appears magic for mediocre

not only weed out wastes, sets fire on them

path is unfurled, value flows without wait

conduit unconfined, elevating through upscale

continuously glued to innovation

where’s the work, its living spirit

embodying people, where product

stages disappear as if to reflect

oneness of sea, without plurality phenomenon

whether it’s the sea or waves or water or all one

so does product made of lean stature

not being different in concept, construct,

test and release. Product, people

and the consumers revel in reverence.

Lean lifts and Muda drags.

Lenify Flow

Lenify flow – Optimize the flow through bottleneck

Group review of software work products is one of the effective ways in reducing the work flow of Product through various gates of software life cycle. Typically the time taken using Group review methods to review software work products  like Software requirements, Design work products, Code, Testing documents is reduced up to one third of effort, it would otherwise take if these are reviewed by individual people.

For example the if the software development team after receiving business requirements from customer, review the requirements as team consisting of Project Manager, Project members, Architects, Quality group, Business Analysts and support functions they might take together say 3-5 hours for a requirements review. All these stakeholders will come out with their queries that can be consolidated and sent to customer on the same day for clarifications. On the other hand, If the project team reviews individually they might take say 2-3 days and then send to others for their inputs. This might involve more than 3 days since it not only involves review effort but also the waiting time from each of the stakeholders plus additional communication overheads.

The group review method is one of good technique that can be put reduce the waiting time, reduce the total effort and to increase the speed and the increase the product flow during the software development process. Group review of software work products is one of the effective ways in reducing bottleneck and accelerates the flow of work products.

SIPOC for Ideas Launch

SIPOC for Ideas Launch

Supplier Inputs Process Outputs Customer
Employees( trigger) Innovative suggestions Brainstorming the suggestions Output pointers Senior Management
Senior Management Ideas considered Preliminary validations Prioritized backlogs of ideas Department heads
Department Heads Share their project viability and plans  on prioritized ideas Weighing the cost vs benefit Benefits expectations on the prioritized backlogs All department heads,

Management

Management Listing of top five ideas Launching top three Business plans for the launched ideas All employees

When fix is painful than defect (Medicine pains more than illness) – Get to theory- 3.4 couplet

When fix is painful than defect (Medicine pains more than illness)

Get to Theory

~3.4 couplet

A small half cup (like that of cough syrup bottle) will contain 1 KG of water vis-a-vis around 74 mL of water. This is the practical way of informing the density concept to children, instead defining in formal physical terms like ratio of unit mass to unit volume expresses in kg/cu.m etc.

However as the child grows perception of density becomes a concept and understand the definition formally. When the child was not able to visualize concept, a direct visual demo was required as the child could not apply the density with just basic perception. However when the child becomes grown up, it will need to understand and extend the concept to broader areas and will be able to derive the density of various substance on its own use the property of density in the relevant application.

The point am trying to suggest is that quick and hot fixes in the name of Agile, will impair the long term solution/product rather than strengthen it.  Here we need the help of theory and concepts. Addressing the root causes and systematically eliminating them will make the model more solid and ensure that product / service is evolving in consistent and effective manner. There are cases where the fix is taking so much effort and cost than the leaving the actual defect in the system, resulting in more CoPQ.  Looking at this way also predictive capabilities if remain the focus and applied in true manner, then will ensure meeting long term objectives of all customers.

Solid grounding on basic concepts will help, in the words of great Toyota way provide the customers with what they want when they want and in the amount they want.

Handling is good, Awareness is better – of Muda

Being aware of process and project MUDAs is more important than handling them. As it is rightly considered in software engineering that defects are injected into the work products at various stages and not inherent in the system. (Though in Six Sigma parlance we have 1.5 sigma shift caused due to passage of time, is in different context altogether)

At the beginning of any project inconsistencies in understanding between customer/end-user requirement and software vendor understanding of the requirement, there is waste called MURA that is created. This is not created by the system rather caused unintentionally between the stakeholders viz, software vendor development team and customers. This is where awareness of MUDA or any types of wastes is really going to benefit the teams. Tools are deployed, Business analysts are employed , still there will be some inconsistencies  May be, it is impossible to get the same and right understanding between development team and customer on round one of the discussion on requirements. However all parties involved should be just aware that the wastes of different nature like MUDA,MURA and MURI can get introduced into system in spite of the best skills displayed by the team. Experienced teams should keep a list of assumptions on the possible wastes that they feel at each stage. Over a period of time and project progress, the assumptions can be validated by the reviews of work products along the common goals shared by all stake holders.

This is true for all phased of software development. Wherever there is an input, process and output sequence involving multiple interfaces of people, there will be wastes injection. Just the awareness and recording of these wastes assumptions will help the team to review and progress gradually towards a great product vision.

The Lean coach therefore drives the awareness of MUDA,MURI and MURA more than handling them. Because as it is said in PM circles one size does not fill all, much the same way  there is no common list of wastes that can serve as check-list for different product development working with different vision and stakeholders.

Being aware of the Waste is more important than handling them

 

Handling Service MURA and MURI

Service MURAs:–

is understanding terms differently within the same organization. One common situation is that Agility is interpreted with multiple meanings from different sections of the organization depending upon the size of the project, engagement model, offshore-onsite structure, delivery criteria, experienced levels of resources etc It is suggested to have knowledge sharing sessions on the common contexts of the company policies including processes, models and procedures. This will clear our inconsistencies in meanings of concepts and models within the organization. Although project level inconsistencies need to be removed, this might be little easier when compared to removing organizational inconsistencies. Trainings and awareness sessions, quizzes and book reading sessions will help to spread the consistencies of concepts quickly and effectively within the organization.

Service MURIs

could be duplication of procedures and non value added activities that strains the  flow of the development / delivery processes. When the lean tools are applied to effectively eliminate non value added activities, there will be less strain on the work flows that will quicken the product outflows. Multiple reviews in excess for a same stage process, passing same information to multiple locations at different times, gold plating of work products that are not required are some of the MURIs in service industries. Some thoughtful actions like group reviews (as against multiple reviews), conference collaboration with all stakeholders in different locations at same time, developing and focusing on just enough requirements could do well in eliminating service MURIs

 

Unreasonable, helps innovation

Unreasonable customer is the reason that the organization runs. For if it were reasonable users, there expectation are known and follow logic, there will be a huge set of vendors who could offer normal products or services and its very hard out there to sustain in the long run.

A sustainable business can leverage and PULL the unreasoning from the customer and use those logic defying requirements to build futuristic products or services. The actions that the companies need to take for converting unrealistic requirements should be equally ‘unreasonable’ by putting all efforts to ensure word class products are built without compromise.

When Chester Carlson invented photocopier even bigger companies were not sure about the photocopiers market and use. The success is now very well known and it kind of revolutionized the way the business were conducted for more than three decades.

Twitter is another contemporary example of Superlative success of micro blogging giant with just 140 characters. When the current digital age is obsessed with High resolution GUIs, pictures, video based contents, this simple 140 characters text giant is making sweeping trend all over the world.

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.

— George Bernard Shaw

Quality principles and Agile

Customer Focus:

Internal and external customer focus. Pulling of values by customer. High level of customer transparency

Leadership

Servant leadership  – everyone owns the product

Involvement of People

Full stakeholder collaboration including developers, end users, QA, Management, etc

Process approach

Elimination of non value added steps and ensuring focus remain closely with respect to current priorities

System approach to management

Keeping in mind the bigger picture of product vision each sprint is developing a theme towards the making of final  product. Automated testing and continuous integration form system approach

Continual improvement

Learning from the previous deliveries of iterations of scrum, incorporating the customer / stakeholder feedback and striving for elimination of NVAs(non value added wastes) from the processes demonstrate continual improvement.

Factual approach to decision making

Decisions are taken through real data obtained through direct stakeholder like customer and end users. All iterations / releases can be directly consumed by users. User feedback gets incorporated into subsequent sprints. Great way of factual approach.

Mutually beneficial supplier relationships

Supply chain efficiency is at its best in Agile / Lean development since customers, vendors and all stake holders are in continuous contact with each other monitoring the product development. Software vendor delivers product to immediate customer, gets the billing done, customer releases products to end customers through various sales channels and monetize the product releases. End users get their requirements fulfilled

Preferable over Pleasurable III – Minimizing Cost of poor Quality

If the delivery schedule is very tight, process has to be tighter. Process here does not mean the extent of the work products/documents rather the right thinking and synergistic actions that excites all the stakeholders in getting the results they want.

Many projects world over have repeatedly experienced higher Cost of poor  Quality  in their projects due to fire fighting activities like fixing production bugs and issues.  Right mix of planning in terms of dealing with preventive, appraisal and failure costs would have saved lots of dollars in many cases. Getting on the same page with regard to product prioritization, in the context of current sprint theme could be main key in avoiding failure costs in Agile projects. Having good average of right experienced team resources will reduce the training costs that contribute to prevention costs.

Using the automated reviews and just enough measurements systems normalizes the appraisal costs effectively.

Similarly focusing on Just enough features in the sprint context will lessen if not eliminate failure costs.

Can’t stop wondering genius of great poet Henry Wadsworth Longfellow  on this great management wisdom, delivered two centuries ago.

It takes less time to do a thing right, than it does to explain why you did it wrong.

Right metrics or (getting the) metrics right – Use systemic thinking

Makes one wonders why there are many differences in measurement systems between many projects.  Automatically goes to prove that a good input and standard way of using measures to derive metrics is essential.  Best results can be achieved by making all the projects and team understand the agree on what should be unit time and effort consist of.  For example an ideal use case in case of Agile projects can be made as 6 hours excluding break and lunch times, assuming average experience of all team members does not vary beyond +/- 10%. Similar approach can be followed for all metrics.

As it is obvious that with just two inputs like time and counts literally all metrics like effort /schedule variance, productivity, defect density, turnaround time etc can be measured, it will a world of good for the project teams to agree upon the standard definitions on various units used in the projects. A slight tuning and agreement will sure do the trick in getting project measurements right.

A tool is just as good as the user. Whereas systemic thinking and applications equalises most of the fluctuations.

Whats in a name – ceremony or practices

Agile ceremonies like sprint planning, stand-ups, visual boarding, refactoring have been sounding like very formal customs that must be practised by all teams. Hence some people/teams prefer using the words practice instead of ceremony.

IMHO it is contextual, and can be used interchangeably. For instance a team that’s new to Scrum project management it should consider the activities like scrum planning, estimation, stand-ups, collaboration, review, refactoring et al, as ceremonies as these need to be minimum steps in ensuring project deliveries.  For a team that has matured through many sprints these activities become practices, implying that customs/ceremonies put into regular routines and become practices.

Also evolution means accommodating and modifying new elements into project management practices, that might involve replacing few practises. This is the essential spirit of Agile – embracing the changes.

As far as teams, learn, practise and perfect – sprint of Agile – What’s in a name?

A rose by any other name would smell as sweet.

Muda Agility Mapping

MUDA AGILITY MAPPING
Over Production  Heavy Code Base, extra  WPS, more buffer resources contributing to non required features, obsolete WPs
Waiting  Unnecessary Hand-offs,  Excessive change request approvals,  in efficient Server set up time, unwanted tools installation, unplanned leaves
Unnecessary Transport or
conveyance 
Unnecessary movement of work products at different levels within the project, as against Kanban and collaborative Hub
Excess Inventory  Product / Application – Waiting for cross platforms, multi OS testing because the testing and user environments are not yet ready.
Over processing  requirements gold plating, design gold plating, etc., poor tools selection
Motion / Unnecessary
Movement 
Wastage of time and energy. Spread out teams of same product, too much to and fro , no knowledge sharing
Defects  costs heavily to the vendors and customers alike.  Detecting the defects early by using Agile approaches likes TDD, Pair programming, Extreme programming

Right First Time (TQM) Vs Fail early (Agile)

As one who believes both in the solid principles of TQM as well as agility of Agile, wanted to share my perceptions about Right First Time, Every Time principle of TQM along side of fail early view Agile methodologies of software development

In order to get it right first time, there need to be lots of wrongs that should have happened early in the evolution of product development. This is true everywhere, be it in industry, theatre, art, paint  or sports, et all. Any aspiring champion will have to put in enormous effort to be aware, learn, practice and perfect his own endeavour. So may be the intent by saying Right First Time can be taken as applying the mindset to the current priorities, it may be practice, rehearsal or any work in progress to remain focused on the present. It will help them to achieve the ‘future Right’ whenever that will come.  Any activity be it product development, theatre play, music or sports will involve series of preparatory steps and each of the steps will be important to get the final desired outcome. Each of these steps individually has sub goals and those need to be ‘got right’. A step’s objective may also involve learning, as far as the learning is obtained  by the pursuer, she got it right. When all the individual steps got what they wanted as outcomes, end outcome is it Right, and indeed Right first time, because for that nth step, what has been achieved is first time event.

While Agile focussing on adaptability and quicker ROI for all stakeholders understands and is flexible in admitting that first 2/3 sprints there will be missed deliveries of few features. Also there might me lessons learnt from review and retrospective phase of sprints. These lessons learnt are indeed one of the sub goal of the sprint that meets the criteria ‘Right first time and every time’ too. Ultimately during the last sprint if all the lessons of the earlier sprints are effectively applied along the way Product delivered will be right first time. Individual sprints looked at the perspective of each sprint goal accomplished their objectives Right. As well they have contributed to ‘fail early’ part of Agile, due to the evolving nature of Product backlog and in the same time helped the overall Product Development Vision by solid lessons learnt practices.

True to ‘embracing the change’ nature of Agile, It will good to consider Right First Time and fail early as truly complimentary principles.

Agile TQM!

Seed Lean, Weed Muda and Yield Revenues

In general context Waste will be something that is not adding value to a system or process or output. Specifically in industrial applications whatever is extra to the present current activity is considered as waste. In  Agile parlance non required activity / feature is waste for the sprint in context. Hence we can interpret wastes in Agile as over documentation, lengthy meetings, too much steps for any activity, maintenance of documents in too many places are some examples.

One solution to help curb wastes will be to follow MSCW methodology –  for feature prioritization for the current sprint, which indeed will help in eliminating wastes effectively.

M – Must be requirements

S – Should be requirements

C – Can be requirements

W – Won’t be requirements

In addition to prioritization, waiting times like sign-offs, document approvals, too many reports / records for the same artefact in multiple machines, including non stakeholders in stand-ups all these can be contributing to Wastes.

Seed Lean, Weed (out) Muda and Yield Revenues

Preferable over Pleasurable II – experience over perception

Breakthrough improvements – Prefer experience over perception

It is very easy to breach than honour processes for the sake of meeting delivery schedules, more so in Agile context.  However solid standardization practices will help any team to get to the basic project  control mode quickly while giving project teams a way to think and innovate beyond.

The path of least resistance (PoLT)syndrome affects almost all teams taking shade under the Agile cloud. Even agile advocates refactoring and review phases during sprint ends. Then we have automatic unit testing tools, continuous integration tools, code checkers etc that are used in Agile projects generate good enough data for the organisation to better their performances in future sprints.

Skipping processes for the sake of Agility is like saying that the Sun is hidden by the cloud.

The irony is that

  • Sun creates cloud,
  • cloud is nowhere near Sun on distance front and
  • to sight the cloud itself Sun is required.

Similar note, Agile is created by good process and team work, till the sprint zero we have to have good software engineering processes like BRM, SRS ,Architecture, Design, Planning etc. To recognize good agile projects we need to have tracking process like Velocity, average velocity, defects reduction while scaling up the sprints. Good Unit testing and integration methodologies should also be implemented to ensure great agile deliveries.

Many real time project managers experienced that Agile is great with just enough processes.  In the same note it s just a (PoLT) perception that Agile needs little or no processes.

Choose the Preferable over Pleasurable

If Agile Sprint is fastest – process should be disciplined

Jenson Button’s pitcrew set a new world record for the fastest-ever pitstop in Formula 1 history: 2.31s at Santander German Grand Prix.

While appreciating this unbelievable performance of Jenson pitcrew in F1, a thought came on the Agile sprint deliveries.

For achieving this kind of superlative service performance, surely  an enormous amount of practice, planning and execution would have gone behind.

Assuming a normal agile sprint of 2 weeks service delivery, project teams and stake holders  are many times reluctant in following disciplined process of project management and tend to skipping reviews, not tracing the requirements effectively, poor estimation or nil estimation etc.

May this great clinical performance by McLaren’s team will help Agile Project Managers in believing to deliver fastest sprint delivery and still following required processes and indeed use those processes effectively for achieving greatest performances.

Just enough process accelerates breakthrough performance. Happy 2013!

2012 in review

The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

600 people reached the top of Mt. Everest in 2012. This blog got about 3,500 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 6 years to get that many views.

Click here to see the complete report.

Five focusing steps ensures value stream

Path of least resistance, is an enabler for Electric current flow as per Ohm’s law. This universal law suits Theory of constraints best in its premise. When the resistance is identified and well-managed to ensure that the flow across it is optimized full flow of product / service occurs.

Five Focusing steps ensures optimized flow by ensuring minimum or almost nil resistance to value

  1. Identify the resistance – bottle neck impedes values
  2. Exploit the resistance by having right value stream available at right place
  3. Subordinate everything else to above value stream – meaning let all subsystems, parallel system work to achieve real value flow
  4. Elevate the value system once the value stream is established, so that it becomes automatic value stream.
  5. Repeat the cycle from step 1 – continuous innovation

 

Being the change helps teams succeed

Being the change like Mahatma Gandhi said, is a great leadership Quality. Its universal law applicable in personal, professional and social planes.

Personal context : Walking the talk, practising what we say to our kids be it reading, hard-working, maintaining consistency in efforts at tasks, waking up early are best performed than told. Children are more likely to follow these healthy habits if it was done by parents than told to them. Contrary to these habits, watching TV Shows, Mobile gazing, procrastinating, being inconsistent will be impacting kids in way that’s unbelievable, they pick up very quickly. Yes, bad habits are easily picked up as they are short cuts to momentary happiness.

Professional Context : Showing up on time, being committed, caring for details of tasks and giving attention to teams’ goals/ efforts in addition to managing the projects will be having significant positive effects on teams commitment and motivation. Most of the time team will follow suit.  Obviously lack of commitment from the project manager will be reflected in the team’s attitude and performance.

Social context : We need not over emphasize, less said the better. Treat people in a way you want to be treated. Always be good and helpful.

 

Checklists – use them prudently

Checklist uses and misuses.

Checklists have been in use for many years in manufacturing and IT industries. In IT typically development, testing and review activities have been using  checklists for complying to both process and technical requirements. In Manufacturing industries checklists are widely used for all operations in shop floor. It has helped the operational staff to ensure adherence to customer specifications, process standards and legal requirements.

However checklists should be used with right purpose and not as ticklists. Some times for audit compliances check lists are used and evidenced for audit purposes. This will reduce any innovation and improvements.

Use checklists prudently and go beyond checklist for innovation. After innovation review checklists and update for continuous processes. This way checklists will be effective and fully used.