A classic use of Kanban is in field support. Trouble tickets arrive on their own schedule. Team members take a Kanban course or read a book. The team puts up a board, sticky notes, and watches as the tickets flow across the workflow, pretty much as they did before. No real improvement except that the manager can now claim that her team is using Kanban and there is greater transparency. (Everyone is happy, and now the team can tick off their “Agile” box–done.)
Traffic slows to a crawl on the Monash Freeway in Melbourne, Australia through peak hour traffic. (Photo credit: Wikipedia)
Even when WIP limits are put in place, they are ignored. “This customer issue is too urgent so we have to exceed the WIP limit” is the logical and customer-focused rationale for the decision. A few weeks or months go by and the team has not stopped to examine why their activities do not flow faster. Kanban does not work. The flow data is not being parsed nor dissected to understand how to improve throughput. Does this sound familiar? Continue reading →
Plan-Do-Check-Act Deming circle, also known as the Shewart cycle, since Deming claimed he took the idea from him. Later Deming changed it to be Plan-Do-Study-Act, but the first version seems more popular and has become the defacto standard. (Photo credit: Wikipedia)
Walter A. Shewhart (Photo credit: Wikipedia)
We’ve all seen PDCA – the famous process control cycle. While delivering a Product Owner Class at our offices in New Jersey, the home of Bell Labs, I learned something I didn’t know about PDCA. One of my colleagues pointed out that W. Edwards Deming was NOT the inventor of it! I had been attributing PDCA to Deming. It is often referred to as the Deming Cycle or Deming Circle. The person who came up with PDCA was Walter A. Shewhart. Dr. Shewhart worked at Bell Labs! I’ve always been impressed with the innovation at Bell Labs, so learning about the origin of PDCA was particularly satisfying.
Shewhart was also credited with the statistical control chart and the distinction between assignable-cause and chance-cause variance. These ideas go to the heart of LEAN manufacturing, and ultimately, Agile development. For example, the notion of work loading assumes that chance-cause variance is not removable, and as a result, we engineer throughput to take chance-cause into account, and simultaneously use PDCA to remove assignable-cause variance. And we focus on adjusting the process to remove assignable cause variance.
PDCA is sometimes misapplied. We plan a whole release,, we do a whole release, we check a whole release, and then we attempt to improve the whole release. Instead, applying PDCA on increments of a release brings us closer to the ideal of continuous improvement. Shewhart introduced this idea during the development of telephone transmission systems.
This is a follow-up post to Dinner with Jeff Sutherland, where Jeff talked about Systematic and the two LEAN metrics for driving improvements; 1) Process Efficiency, and 2) Fix time after failed builds. More details are now available in a paper titled Mature Scrum at Systematic.
Systematic combined a LEAN operating model, SCRUM as the project management framework allowing for flexibility and adaptability, and CMMI to institutionalize these elements into the culture of the organization, driving discipline and measurability. More information as well on how User Stories are prepared to a READY-READY state before being allowed to enter the Sprint. The grooming of the backlog and preparing User Stories is done in parallel to the Sprint.
Becoming Agile is about changing the way we think and act. Many organizations train their people to operate in a “command and control” environment, where the decision making and control lies with the managers. Design managers, test managers, project managers, program managers…etc. What is built and how it is built is defined by the business teams and architecture teams. The size, scope, feature content, overall structure of the solution is defined with estimates provided not necessarily by the people doing the work. The work is then carved up into pieces and distributed across the different functions to be implemented, which amounts to a structural decomposition of the product is mapped to the structure of the organization that will do the work of building the product.
These organizations measure performance and progress of functional groups discretely. They optimize within teams, within organizations, within the boxes they work. Incentives are awarded on the basis of these optimizations. This is the traditional method of operating for many enterprises. Agile methods and Lean thinking demonstrate that this creates waste and slows development velocity. Wasted time, resources, and knowledge (e.g. knowledge lost during handoffs between teams).
Lean Thinking Lean Thinking is at the heart of Agile. Lean Thinking is all about looking at the path from quote to cash and eliminating anything that does not provide value to the customer. One question of Lean Thinking is:
“If a customer was in front of me, would he/she gladly pay me for what I am doing at this moment?”
Every step in the process should create value. To achieve this, management control shifts from controlling the work, to controlling the process. The development teams self-organize around the work. In this way, the organization is built around the work to be done, rather than organizing the work to fit the organization.
Lean is about excellence in processes and process control. But Lean Thinking comes from manufacturing. How do we translate Lean thinking into the world of software development? A white paper from Mary Poppendieck, called “Principles of Lean Thinking” maps the ideas of Lean Thinking to the world of software. You can find it here.
Monday, March 29, I had the opportunity to have dinner with Jeff Sutherland and other RTP leaders. The dinner was a fundraiser for CITCON, which came to RTP in April. This was an opportunity for Agile practitioners and experts to have an informal chat about the challenges and opportunities of using Agile in the world of work.
I was interested in learning more about Systematic, a CMMI level 5 company that implemented Scrum across its entire business. One thing that sets Systematic apart from other companies is that it has really good data to prove that Scrum works, and it is a software company that can execute perfect waterfalls every time. Systematic created hyper-productive teams, and by Jeff’s definition, they are at least 4 times more productive than industry average. They cut TTM in half and the development costs by the same as well.
The Theory of Constraints (TOC) is all about flow, and identifying and removing bottlenecks in the flow. Think of the analogy “the chain is only as strong as its weakest link”. The weak link is the bottleneck in the flow from from quote to cash.
A simple example is to look at manufacturing where scarce machinery or skills creates a backlog of work directly in front of it. Inventory piles up as teams in different departments build excess stock in the production chain which the bottleneck resource cannot keep up with. Software is no different. In our world, we see it all the time. Scarce skills, people with specialized expertise cause those who need their services to queue up in front of them.
Root cause analysis is at the heart of TOC – something that we in the software industry understand very well. TOC applies 5 focusing steps to identify constraints and their root causes in the context of a continuous improvement exercise. These 5 steps are:
Identify the constraint
Decide how to exploit the constraint
Subordinate and synchronize everything else to the above decisions
I love this quote from Fujio Cho, President of the the Toyota Motor Corporation, 2002.
We place the highest value on actual implementation and taking action. There are many things one doesn’t understand and therefore, we ask them why don’t you just go ahead and take action; try to do something? You realize how little you know and you face your own failures and you simply can correct those failures and redo it again and at the second trial you realize another mistake or another thing you didn’t like so you can redo it once again. So by constant improvement, or, should I say, the improvement based upon action, one can rise to the higher level of practice and knowledge.