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.

‘Blame the previous CEO!’

‘Blame the economy!’

‘Prepare three envelopes!’

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:

• We’ve never been able to get our sprint backlog to “done”. There’s never enough time at the end of the sprint for thorough testing. This leads to mounting technical debt.

• Daily meetings made sense in the beginning but they’re not adding much value any more. Scrum Masters find it increasingly difficult to maintain enthusiastic participation during daily stand ups.

• Certain work items are long-running-tasks by their nature: database upgrades and conversions come to mind and can’t fit into a single sprint. Splitting them up doesn’t always make sense.

• Certain individuals like to specialize in their craft like UI design, database; Scrum values cross-functional skill sets over specialization.

• Management wants more responsiveness and engagement from the team as soon as and opportunity arises. Waiting until the start of the next sprint is not acceptable in many cases.

• Management needs more visibility and top-down input into the whole program, not just individual teams. The Scrum-of-scrums is a weak substitute for this since it’s designed to be bottom up.

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:

1. Can you trust them to do the right thing?
2. Are they committed to excellence?
3. Do people matter to them?

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.

In a recent post Net Objective’s CEO, Alan Shalloway made the following statement:

“…almost all Scrum teams have several of the same challenges:

• too much time is taken in estimation
• too many stories are open at the end of a sprint
• the daily stand ups don’t seem to add a lot of value
• quality is not being improved
• testers are far behind developers at the end of a sprint”

(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.

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

1. Time-boxes are no longer needed therefore what you see on the board is not the work for the current timebox but will stay on the board for as long as it takes to complete the story
2. Stories are at the minimum marketable feature (MMF) level. There is no value seen in breaking down stories beyond the point of an MMF since, by definition, their completion would not add any marketable value to the product. There is also no longer a need to break down the story into its tasks.
3. The “To-Do” column of the task board is replaced by all the steps in your workflow (aka value stream). A common development flow consists of
   1. Story elaboration
   2. Development
   3. Testing
   4. Deployment

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:

1. What are the work in progress limits for each step of your process flow?
2. Can a work item be considered “DONE” without going through each step of your flow?
3. What are the various work item types in your process?
4. How do you reserve time from shared resources?
5. How does a work item get marked as “URGENT” and trump other items already in the work flow?
6. What should be the cycle time allowed for each class of service?

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:

• Teams and organizations that have been practicing Scrum for 3 years or more will extend to hybrids like ScrumBan, Scrum/XP and even ScrumFall (if they lose executive sponsorship and are forced to backslide towards Waterfall). Kanban will continue to gain in momentum and mindshare.

• More small to medium-sized companies will initiate enterprise-wide transformations, using Agile development principles in concert with Lean business process improvement in an attempt to transform their businesses in today’s harsh economic climate.

• There will be more failures in agile adoption, as organizations attempt to drive the agile practices without fully understanding the agile principles; or simply jump onto the agile bandwagon and continue to practice waterfall (or whatever) while calling it agile.

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.

• Fake Agile Certification(s) - Agile is a change of mindset and values. Already there are several charlatan certifications as people jump on the band wagon. No certification can measure whether a person has truly understood agile and adopted the mindset. Instead of worrying about certification when purchasing training, talk to the trainer and see if they understand agile and teaching. Don’t worry about the certification.

• Agile Business - The leading organizations have mastered agile as a software development process to the point that they produce products faster than sales/marketing can handle. To get the greatest benefit these organizations will need to take an agile/lean approach to the whole business starting with sales/marketing and eventually encompassing legal, HR, etc.

Bart Perkins, a senior consultant, believes:

• The next few years are going to be difficult for IT. Budgets will be flat while demand for IT continues to grow. IT will feel immense pressure to improve internal efficiency in order to make more money available for new services.
• During 2010, IT organizations will place additional emphasis on activities that will save money including:
  • Virtualization. In addition to virtualizing additional servers, organizations will expand virtualized storage and the desktop as well.
  • Supplier management. Organizations will work with key suppliers to lower the supplier’s bill. At a minimum, they will review licenses and remove unused seats, services, or maintenance. (Telecom audits in particular usually save money.) More sophisticated organizations will closely tie each supplier product to a component of the IT Architecture to identify (and remove) redundant products.
  • Open source. Open source will continue to gain market share. While few large organizations will migrate to Open Office, it will be popular with startups and smaller organizations.
• While internal efficiency projects are not glamorous, each one saves money.

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.

• At the end of 2009, I see the same thing happening in the Agile Software Development world. We have a number of approaches in use — Scrum, Kanban, Lean, Extreme Programming, Industrial XP, Feature Driven Development, RUP and DSDM — and there is fragmentation in the market. There is significant competition among the approaches and the vendors that provide tools to support them.
• Composite Methods: There will be an amalgamation of methods/processes/standards being used across all tiers of an organization over the next three years. Separate business management (e.g. SixSigma), governance (e.g. ITIL), project management (e.g. Prince2), software processes (e.g. RUP) and pure agile development (e.g. Scrum) will not exist as separate entities. Why? Organizations are a singular, large, globally spread entities that yearn to benefit by cohesive/unified IT performance. IT and business cannot be considered as two separable entities. We’ll see organizations creating repositories of all their methods/processes/standards and picking elements from these processes to create “composite agile” methods that will enhance business agility.”

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