Monday, May 18, 2009
More blogosphere buzz about Lean & Kanban
John Strickler has this thoughtful piece about Lean & Kanban and how he was introduced to Agile via Mary Poppendieck and Alan Shalloway following a background that including reading Factory Physics and learning Six Sigma. Nice to see someone with a background in reducing variation and an understanding of queuing theory talking about this stuff. So few Agile folks seem to understand what I mean when I say Kanban has an underlying model.
Meanwhile, Jeffrey Palermo picks up on my piece for Borland on why you should just say “No!” to an formal Agile transition initiative, Why Agile Transition Initiatives Might Fail!
Margaret Rouse highlights Kenji Hiranbe and I and observes that Kanban is a way to visualize bottleneck in a software development project.
Keith Henry’s been researching how to tailor agile to your organization. While he cites my work on Agile+CMMI he might enjoy my series for Borland more: Agile Transition Initiatives - Just Say No!; Creating an Agile Culture!
Jason Yip rediscovered one of my older gems identifying that liberal versus conservative culture is a bigger influence than high trust versus low trust in driving Agile adoption.
Pascal Van Cawenberghe asks “Why Estimate?” and cites several leading thinkers on this space including Amit Rathore, Joshua Kerievsky and me.
Richard Veryard tickled me with his wittily titled Restaurant at the End of the Universe over at his Demanding Change blog.
Defense Industry Daily was so impressed with my Top 10 rated talk at the SEPG conference that they suggest it’s time to Sharpen Yourself a Kanban System for Software Engineering. Yes indeed! :-D We already have a Kanban implementation with the Danish Department of Defense. I’m hoping for more traction in the defense sector in the next year. I really do hope that Kanban becomes the unifying force that brings the Agile world and the big software and system engineering firms together.
Hillel Glazer noted that my SEPG session on high maturity metrics and Agile was packed and locked out and no one left early. I wonder who I impressed? His notes from Wednesday tell the tale of the Agile + CMMI open space with a super picture of how many people we had at that session and then with another wonderful picture of one of my slides we get Hillel’s take on my Agility & High Maturity talk - naturally Kanban is at the heart of it but Hillel calls it correctly - set high maturity behavioral expectations early and choose metrics and data wisely. His Tuesday notes cover the CMMI + Agile: Why not embrace both talk given by Mike Konrad and supported by Hillel, Jeff Dalton and I.
The folks at Enthiosys (Luke Hohmann et al) have been thinking about Agile maturity models and comparing my work on Agile + CMMI with Bas Vodde and Jeff Sutherland’s Nokia Test.
Allan Kelly gives us a list of 10 Things to Know About Kanban Software Development. Very handy! Allan also helps us to Make Sense of Kanban.
Meanwhile, Boris Gloger describes my use of Kanban as “harmful for software development.” How many people actually doing it believe that? I wonder if Boris has ever tried it? Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban, CMMI, Software+Engineering, Project+Management
Posted by david on 05/18 at 01:31 PM
Goals for using Kanban
At the formation meeting of the Lean Software and Systems Consortium, Dean Leffingwell challenged me with the question, “What are the goals when choosing to use Kanban?” I struggled to articlulate an answer off the top of my head as I hadn’t thought about it that way. I found just a week later that I had to answer Dean’s question in order to complete Chapter 5 of my Kanban book manuscript, “Getting Started with Kanban.” A later part of this chapter appeared a few days ago on my blog, How to Start with Kanban. The remainder of this post is yet another extract from Chapter 5…
The Primary Goal for our Kanban System
We are doing Kanban because we believe it provides a better way of introducing change. Kanban seeks initially to change as little as possible. So change with minimal resistance must be our first goal.
Goal 1. Improved performance through process improvements introduced with minimal resistance
Secondary Goals for our Kanban System
We’ve learned that Kanban allows us to deliver on all 5 elements of the Recipe for Success. However, we might want to word the goals slightly differently from the wording in the recipe and some of the points in the recipe need to be expanded to reflect that one point can help us deliver on more than one goal.
Goal 2. Deliver with High Quality
Kanban helps us focus on quality by limiting work-in-progress and allowing us to define policies around what is acceptable before a work item can be pulled to the next step in the process. These policies can include quality criteria. If, for example we set a strict policy that user stories cannot be pulled into acceptance test until all other tests are passing and bugs resolved, then we are effectively “stopping the line” until the story is in good enough condition to continue. With a new team doing Kanban we may not have such a strict rule but there should be some policies relating to quality that focus the team on developing working code with low numbers of defects.
Goal 3. Deliver a predictable cycle time by controlling the quantity of work-in-progress
We know that WIP is directly related to cycle time and that there is also a correlation between cycle time and a non-linear growth in defect rates So it makes sense that we want to keep WIP small. It makes our life easier if we simply agree to limit it to a fixed quantity. This should make cycle times somewhat dependable and help us to keep defect rates low.
Goal 4. Give team members a better life through improved work/life balance
While employee satisfaction often gets lip service in most companies, it is seldom a priority. Investors and senior managers all too often take the view that resources are fungible and easily replaced. This reflects a cost-centric bias in their management or investment approach. It doesn’t take into account the huge impact on performance that comes with a well motivated and experienced workforce. Staff retention is important. As the population of software developers ages, they care more about the rest of their lives. Many lament wasting their 20s locked up in an office slaving over a piece of code that failed to reach market expectations and became obsolete a short period later.
Work/life balance isn’t only about balancing the number of hours someone spends at work with the number of hours they have available for their family, friends, hobbies, passions and pursuits. It is also about providing reliability. For example, a team member with a passion for art wants to take a painting class at the local middle school. It starts at 6.30pm and runs every Wednesday for 10 weeks. Can your team provide certainty to that individual that they’ll be free to leave the office on-time each week in order to attend the class?
Providing a good work life balance will make your company a more attractive employer in your local market. It will help to motivate employees and it will give your team members the energy to maintain high levels of performance for months or years. It’s a fallacy that you get top performance from knowledge workers when you overload them with work. It might be true tactically for a few days but it isn’t sustainable beyond a week or two. It’s good business to provide a good work/life balance by never overloading your teams with too much work.
Goal 5. Provide slack by balancing demand against throughput
While the 3rd element of the Recipe for Success - Balance Demand against Throughput - can be used to avoid overloading team members and allow them a reliable work/life balance, it has a second effect. It creates slack in the value chain. There must be a bottleneck in your organization. Every value chain has one. The throughput delivered downstream is limited to the throughput of the bottleneck, regardless of how far upstream it might be. Hence, when you balance the input demand against the throughput, you create idle time everywhere in your value chain with the exception of the bottleneck resource.
Most managers baulk at the idea of idle time. They’ve generally been trained to manage for utilization (or “efficiency” as it is often called) and inherently it feels like changes can be made to reduce costs if there is idle time. This may be true but it is important to appreciate the value of slack.
Slack can be used to improve responsiveness to urgent requests and to provide bandwidth to enable process improvement. Without slack team members cannot take time to reflect upon how they do their work and how it might be done better. Without slack they cannot take time to learn new techniques, to improve their tooling or their skills and capabilities. Without slack there is no liquidity in the system to respond to urgent requests or late changes. Without slack there is no tactical agility in the business.
Goal 6. Provide a simple prioritization mechanism that delays commitment and keeps options open
Once a team is capable of focusing on quality, limiting WIP and delivering often, and balancing demand against throughput, they will have a reliable, trustworthy, software development capability: an engine for making software! A “software factory” if you will! Once this capability is in place it would behoove the business to make optimal use out of it. To do this requires a prioritization method that maximizes business value, and minimizes risk and cost. Ideally a prioritizations scheme that optimizes the performance of the business (or technology department) is most desirable.
The software engineering and project management fields have been developing prioritization schemes since software projects began perhaps 50 years ago. Most of the schemes are simple. For example, “High, Medium, Low” provides three simple classifications. None of these have any direct meaning for the business. Some more elaborate schemes came into use with the arrival of Agile software development methods such as MoSCoW (“Must have”, “Should have”, “Could have”, “Won’t have.”) Other methods such as Feature Driven Development featured a modified and simplified version of the Kano Analysis technique popular amongst Japanese companies. Yet others advocated strict enumerated order (1, 2, 3, 4, ...) by business value or technical risk. The challenge with this latter scheme is that it often creates a conflict between the high risk items that should be prioritized first and the high value items that should also be prioritized first.
All of these schemes suffer from one fundamental problem. In order to respond to change in the market and evolving events, it is necessary to reprioritize. Imagine for example you have a backlog of 400 requirements prioritized in a strict enumerated order 1 to 400 and you are doing incremental delivery with an Agile development method in one month iterations. Every month you have to reprioritize the remaining backlog of up to 400 items.
In my experience, asking business owners to prioritize things is challenging. The reason for this is simple: there is so much uncertainty in the marketplace and the business environment. It’s hard to predict the future value of one thing against another, when something might be needed and whether something else might be more valuable to have earlier. Asking a business owner to prioritize a backlog of technology system requirements is to ask them a very hard set of questions of which the answers are uncertain. When people are uncertain they tend to react badly. They may move slowly. They may refuse to cooperate. They may become uncomfortable and dysfunctional. They may simply react by thrashing and constantly changing their minds, randomizing project plans and wasting a lot of team time reacting to the change.
What is needed is a prioritization scheme that delays commitments as late as possible and provides a simple question that is easy to answer. Kanban provides this by asking the business owners to refill empty slots in the queue while providing them a reliable cycle time and due date performance metric.
We already have 6 lofty and valuable goals for our Kanban system and for many businesses that might be enough. However, I and other early adopters of Kanban have discovered that two other even loftier goals are both possible and desirable.
Goal 7. Provide a transparent scheme for seeing improvement opportunities enabling change to a more collaborative culture that encourages continuous improvement
When I first started to use Kanban systems, I believed in transparency on the work-in-progress, the delivery rate (throughput) and the quality because I understood that it built trust with customers and more senior management. I was providing transparency onto where a request was within the system, when it might be finished and what quality was associated with it. I was also providing transparency into the performance of the team. I did this to provide customers with confidence that we were working on their request and when it might be completed. In addition, I wanted to educate senior management on our techniques and performance and build their confidence in me as a manager and my team as a well formed professional group of software engineers.
There is a second order effect from all of this transparency that I hadn’t predicted. While transparency onto work requests and performance is all very well, transparency into the process and how it works has a magical effect. It lets everyone involved see the effects of their actions. As a result people are more reasonable. They will change their behavior to improve the performance of the whole system. They will collaborate on required changes in policy, personnel, staff resourcing levels and so forth.
Goal 8. A process that will enable predictable results, business agility, good governance and the development of what the Software Engineering Institute calls a “high maturity” organization
For most senior business leaders that I speak to, this final goal really represents their wishes and expectations for their business and their technology development activities. Business leaders want to be able to make promises to their colleagues around the executive committee table, to their board of directors, to their shareholders, to their customers and to the market in general, and they want to be able to keep those promises. Success at the senior executive level depends a lot on trust and trust requires reliability.
In addition, they recognize that the world today is fast paced and change happens rapidly: new technologies arrive; globalization changes both labor markets and consumer markets causing huge fluctuations in demand (for product) and supply (of labor); economic conditions change; competitors change their strategies and market offers; and market tastes change as the population ages and becomes wealthier and more middle class. So business leaders want their business to be agile. They want to respond to change quickly and take advantages of opportunities.
Underlying all of this they want good governance. They want to show that investors’ funds were spent wisely. They want costs under control and they want their investment portfolio risk spread optimally.
To do all of this they’d like to have more transparency into their technology development organizations. They’d like to know the true status of projects and they’d like to be able to help when it is appropriate. They want a more objectively managed organization that reports facts with data, metrics and indicators not anecdotes and subjective assessment.
All of these desires equate to an organization operating at what the Software Engineering Institute defines as Maturity Level 4 on its 5 point scale of capability and maturity in the Capability and Maturity Model Integration (CMMI). Level 4 and 5 on this scale are known as the “high maturity” levels. Very few organizations have achieved this level of maturity regardless of whether they have sought a formal SCAMPI appraisal or not. It is no wonder then that most senior leaders of large technology companies are frustrated by the performance of their software engineering teams. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban
Posted by david on 05/18 at 09:57 AM
Lean & Kanban (UK) 2009 Sep 27-29 London
My friends Rob Hathaway (who gave a really great presentation at Lean & Kanban 2009 Miami) and Jason Smith (of Indigo Blue in London) together with Karl Scotland (EMC Consulting) are organizing a European version of our Miami conference. It’s called Lean Kanban (UK) 2009 and it’s in London at the Royal Society for the encouragement of the Arts (RSA) on September 27th - 29th. The list of speakers is impressive with confirmed key notes from Don Reinertsen and Mary Poppendieck as well as an appearance from John Seddon who is a well known Lean advocate in the UK and experienced introducing Lean to Healthcare and Government sectors. Other speakers include Hal Macomber of the Lean Project Institute who uses Lean techniques in construction project management plus leading Kanban thinkers such as Corey Ladas, Kenji Hiranabe and Jeff Patton.
On-line registration opens soon. You can pre-register today by calling Indigo Blue directly. Places are filling up. Our event in Miami created quite a buzz. Numbers are limited to just 200. Do not miss out. Kanban has a lot of momentum in London and we fully expect the event to sell out early. I hope to see you in London in September.
Use conftag #lkuk09 when discussing the event on TwitterTechnorati tag: David+Anderson, Agile+Management, Agile, Lean, Kanban
Posted by david on 05/18 at 12:49 AM