A new CEO met privately with his predecessor on his first day in charge. The CEO who was stepping down presented him with three numbered envelopes.
‘Open these—one at a time—and only when you run up against a crisis that seems beyond your control,’ he said.Things went along pretty smoothly, but six months later, sales took a downturn and he was catching a lot of heat. He remembered the envelopes. He went to his drawer and took out the first envelope. The message read,
‘Blame the previous CEO!’The new CEO called a press conference and tactfully laid the blame at the feet of the previous CEO. Satisfied with his comments, the media and Wall Street responded positively, sales began to pick up, and the problem was soon behind him. A couple of years later, the company was hit again with a dip in sales combined with serious product problems. The CEO thought, ‘Aha! Time for envelope two!’ The CEO opened the second envelope. The message read,
‘Blame the economy!’Times were tough for everyone in the industry. This seemed to work fine. He was ready for another business cycle. After several consecutive profitable quarters, the company once again fell on difficult times. The CEO closed his office door and opened the third envelope. The message said,
‘Prepare three envelopes!’it’s a great reminder to all of us that we shouldn’t panic after our first setback. If we’re lucky we might even get another free pass before it’s too late.
Scrum is by far the most popular of the Agile processes. In fact, when software companies say they are doing agile development you can be pretty sure they are talking about Scrum.
The question that is worth asking is “How successful is Scrum over the long haul? Are we seeing diminishing returns after say a year of practice?” My own experience as an agile instructor and coach has been mixed. At the beginning of the organization’s transformation there is great excitement and desire to blow the doors off of productivity. After a couple of rocky sprints, the teams do become hyper productive. And everyone’s happy…for a while.
A dozen sprints (or so) later we begin to consistently see the following complaints from both management and the team:
Kanban is a much better process once the system has reached a steady state and the focus becomes process improvement, maturity and improved cycle times.
Scrum is an outstanding process to adopt when you want a radical departure from the past or if you’re a start up. Scrum is disruptive and pretty heavy by its nature but results in huge productivity increases in the short-term. But if you’re a mature company with an existing revenue stream from products you’re better off starting where you’re at and making conscious, gradual and continuous process improvements using Kanban. I believe this approach is both more affective as well as politically prudent.
As in every craft, it’s important to use the best tool for the job. In my opinion, Scrum is being used in many situations where Kanban is a more appropriate fit. As an agile coach it’s my job to steer my clients towards the most suitable processes for them. I think over the next year, we’ll be seeing many Scrum shops migrate towards Kanban as their products, processes and teams mature.
-Armond Mehrabian
Senior Consultant, Portofino Solutions, Inc.
amehrabian@portofinosolutions.com
Assessing people’s character is simple. All you have to do is ask three questions:
Only when you can give a definitive “YES” should you invest in the person.
- Lou Holtz (author, football coach)
Try it out on someone you know; it works every time.
“It is my duty and mission to put to work what I am good at, rather than to do what I love to do.” — Peter Drucker (Forward to Half-Time by Bob Buford)
In a recent post Net Objective’s CEO, Alan Shalloway made the following statement:
“…almost all Scrum teams have several of the same challenges:
(go here for entire article)
Does your Scrum team have these issues?
I’ve seen optical illusions but this one wins the prize. Prove it to yourself by looking at the squares in a paint program…that’s what I had to do.
“Think of a product you love, one you’d recommend to a friend. What makes the product valuable? While I’m not a mind reader, I’m confident you weren’t thinking: “lack of bugs” or “time to market.” The most difficult part isn’t delivery, but the discovery of products that are truly valuable to the people that use them. Jeff Patton explores applying Lean thinking to product discovery.” — Jeff Patton
This is the third part of the Lean-Kanban post based on a training class I recently attended by David Anderson (aka @agilemanager) and some additional reading on the same subject. I will admit that I now favor this method of collaboration far more than Scrum and one of those reasons is Kanban’s explicit limitation of work made visible and enforceable through the Kanban board.
In Part 1 I covered some of my takeaways from the training and basic tenets of Kanban. In Part 2 I focused entirely on the notion of process policies. In this post I want to discuss the Kanban board, one of the key artifacts of the Kanban software development process.
At first glance, a Kanban board looks just like a Task board used in most Scrum environments.
(This board was reconstructed from photos of boards used at Yahoo.)
So how is it different than a task board? The answer to this question will be the topic of the rest of this post. I will answer this question by also pointing out the key differences between Kanban and Scrum
Kanban explicitly tracks a stories passage through each step in the flow so that it can control the work in progress within each step and identify bottlenecks in the flow so that they can be removed.
Steps can be added or subtracted as necessary. Kanban explicitly tracks a story’s passage through each step in the flow so that it can control the work in progress within each step and identify and deal with bottlenecks as they arise. Cards can be moved back to a previous step if they need rework.
4. Explicit work in progress (WIP) limits are set across the entire work flow written on the bottom of each step. In this example, the entire WIP limit is set at 17. That is, no more than 17 user stories can be on the card wall at any given time. In addition, each step has WIP limits. In our example, the testing step has a limit of 3 user stories. What this means is that as soon as there are 3 stories in the test area no more cards can flow through to testing. Developers will need to stop producing work for the testers but instead, ask them for ways they can ease their burden. There are best practices for setting step limits but that is beyond the scope of this post.
5. Kanban makes provision for urgent user stories (usually production issues) that need immediate attention. These stories are “fast tracked” ahead of those currently in the system. There is no longer the “no interrupt rule”. The “Expedite” lane is where these types of user stories cross through.
6. Instead of tracking the throughput by the number of story points accomplished (velocity), Kanban measures the cycle time of each story. This is also explained as the average wait time for a user story. In our example, from the time a user story is placed on the Story Queue it can be expected to complete in 18 days.
Even though there are no iterations, there are periodic product demos, and retrospectives as deemed necessary by the team and other stakeholders.
I really appreciate the flexibility afforded by the Kanban system with the emphasis placed on Lean concepts of optimizing for flow and limiting work in progress. In my opinion, there are many teams who will benefit greatly by adopting Kanban. This is especially true If you are leading a maintenance or sustained engineering organization.
Read the story of David Anderson at Corbis for further inspiration.
I hope you’ve enjoyed this article. I would greatly appreciate any comments.
Regards,
Armond Mehrabian
Sr. Consultant, Portofino Solutions
San Diego, CA
This is the second part of the Lean-Kanban post based on a training class I recently attended by David Anderson (aka @agilemanager). I recommend that you read Part 1 to get a better context.
One of the key differences between Kanban and other agile methods (e.g. Scrum) is Kanban’s reliance on well defined process policies. Kanban requires that process policies are defined explicitly for each implementation. It is important to think of a process as a set of guidelines that govern behavior. These policies are under the control of management and can (and should) be periodically examined and modified especially as the organization matures.
I think for most of us the term “policies” conjures up images of large binders with the words “Policies and Procedures” on a manager’s bookshelf that contained waterfall-style documentation that no one reads. That is NOT what Kanban means with policies but rather a minimal set of process rules that define how work efficiently flows through your process. Hear are a few examples of the type of questions that process policies answer:
Rather than make teams less agile, process policies are meant to help a team stay focused on the task without having to repeatedly answer the same questions. For example, if you have established that pair-programming produces better quality results then make it a policy. It is through process policies that best practices are institutionalized.
Another important purpose these policies serve is make both management and knowledge worker trust one another and prevent the undesirable downward spiral into micro-management. Once a policy is established such as “all source code must comply with our StyleCop policies document” management no longer needs to “checkup” on whether the team is adhering to the coding standards and can focus on more pressing issues.
There is much more I could say about this topic but I would much rather engage in a conversation based on your comments.
In my next post I will talk about visualizing the work in progress through the Kanban board.
Recently, a number of Cutter Consortium IT consultants were asked to give predictions on upcoming trends for 2010 and beyond. Most of what they say about knowledge workers and their methods of collaboration are quite positive . In this post I have attemped to summarize what they said about collaborative software development methods.
(for the entire list click here)
Sanjiv Augustine, a senior consultant, believes that:
Claude Baudoin, a senior consultant, expects contractors and consultants to be in demand, and many of them will be ex-employees who, having found their past employer’s loyalty in short supply, will now be more interested in being their own boss than in rejoining as an employee. 2008 and 2009 saw a bloodbath in IT ranks. Never well-protected from corporate misunderstanding and even mistrust, IT was forced to cut everything that the CEO and the CFO did not understand - which is a lot. As activity picks up in 2010, there is no spare capacity to start new projects, and rehiring takes some time. Expect contractors and consultants to be in demand, and many of them will be ex-employees who, having found their past employer’s loyalty in short supply, will now be more interested in being their own boss than in rejoining as an employee (with fewer benefits than before they were released). There was already an erosion of the traditional employment model in favor of a contingent workforce. Expect that curve to go through a step function as a result of the crisis.
He believes that the outsourcing trend will lead to Innovation vs. Commoditization: A consequence of the recent crisis is that management has been looking to outsource everything in IT - often not even keeping enough people to problem-manage the contracts with outsourcers, provide sound governance, keep ownership of master data, etc. Innovation didn’t seem so important in 2008-2009, and didn’t Nicholas Carr say that IT didn’t matter anyway? Companies that followed this to an extreme will no longer have the internal talent to re-innovate when they need to, nor can they rely on companies halfway around the globe whose contract is purely about reducing the cost per transaction while maintaining a service level barely above acceptable. By 2012, expect that compelling user features, the kinds of things that make people camp out overnight in the rain in front of an Apple Store, will come from those companies that understood how to maintain, then quickly ramp up, an investment in IT innovation and in the people capable of it.
Gil Broza, a senior consultant, believes that in 2010-2011, Agile adoption will increase considerably, while the certification of newcomers will drop sharply in price and scale. As companies regroup post-recession, they will firm up co-located, on-shore development; any growth in off-shore efforts will be in the form of increased business representation.
Ken Collier, a senior consultant, believes that although Agile adoptions will proliferate, we will see an increase Agile project failures due to misunderstanding, misapplication, and misguided attempts to follow an “agile recipe.” Kanban will emerge as a powerful Agile technique for managing support and maintenance activities by software product companies.
Jim Highsmith, a senior consultant, states that in 2010 a small but significant number of organizations will “get it” when it comes to agility. They will begin to appoint Chief Agility Officers (CAO) who may initially report to the CIO, but over time will report to the CEO. These organizations understand that business responsiveness — agility — is key to their success and that creating a CXO-level officer to focus on responsiveness is as critical as creating CIO or CTO positions. The CAO’s role will be to extend agility far beyond agile software development or agile project management to agile customer solution delivery that might involve marketing, sales, distribution, or services delivery.
Mark Levison, a senior consultant, believes that there will be some big public agile adoption failures this year. These will be companies that tried to agile in name without understanding the change in values and mindset.
Bart Perkins, a senior consultant, believes:
Dave Rooney, a senior consultant, make predictions for the upcoming decade…
“I see Agile Software Development following the same pattern as two other game-changing trends — Relational Database Management Systems and Object-Oriented Programming. After early initial work in both of these areas, it took about 20 years for them to reach the Late Majority and Laggards phases of Rogers’ Technology Adoption Lifecycle. At the 10-year mark, both industries had significant breadth in terms of companies and their approaches and tools, and indeed there was fragmentation of exactly what RDBMS and OO even meant at that point.
Wow, lots of mostly-positive things said about 2010! It will be fascinating to track these predictions. Of special interest to me is the adoption of Kanban in the enterprise given that Scrum (the most popular of the agile methods) has met with mixed results. In organizations that have not succeeded with Scrum, the managers do not want to go back to waterfall (although surprisingly many have) but are discouraged by the Scrum community to modify Scrum in any way (“don’t be a ScrumButt” is the popular phrase). Kanban brings a viable alternative with its roots firmly planted in the Lean community. It will be interesting to see how widely it is adopted over this year.
Please leave a comment if you found this post useful.
Armond Mehrabian
Agile management consultant and coach