The Agile Executive

Making Agile Work

Archive for the ‘Kanban’ Category

Predicting the Year Ahead

leave a comment »

Cutter Consortium has published predictions for 2010 by about a dozen of its experts. My own prediction, which examines the crash of 1929, the burst of the “dot-com bubble” in 2000 and the financial collapse in 2008, is actually quite bullish:

I expect 2010 to be the first year of a prolonged golden age. Serious as the various problems we all are wrestling with after the 2008-2009 macro-economic crisis are, they should be viewed as systemic to the way a new generation of revolutionary infrastructure gets assimilated in economy and society.

In addition to the techno-economic view expressed in the Cutter prediction, here are my Agile themes for 2010:

  • Agile moves “downstream” into Release Management.
  • Agile breaks out of Development into IT (and beyond) in the form of Agile Infrastructure and Agile Business Service Management.
  • SOA and Agile start to be linked in enterprise architecture and software/hardware/SaaS organizations.
  • Kanban starts an early adoption cycle similar to Scrum in 2006.

Acknowledgements: I am thankful to my colleagues Walter Bodwell, Sebastian HassingerErik Huddleston, Michael Cote and Annie Shum who influenced my thinking during 2009 and contributed either directly and indirectly to the themes listed above.

Connecting the Dots: Operational Excellence, Strategic Freedom and the Pursuit of Passion

leave a comment »

My recent post The Headlong Pursuit of Growth, and Its Aftermath applied insights from Toyota Motor Corporation to Agile methods. Among various lessons to be learned, the post highlighted the relationship between mechanism and policy: 

Just like the Toyota Production System, your software method is a “vehicle” which is subject to policy decisions from above. It cannot, however, compensate for policy failures.

In other words, operational excellence in Agile methods is not a substitute for strategy/policy. It does not confer strategic freedom.

In another recent post – I Found My Voice; I did not Find My Tribe – the vicious cycle that leads to loss of passionate Agile talent was described as follows:

This “1.5” phenomenon is at the root of a vicious cycle that dilutes companies, particularly these days:

  1. A round of layoffs is implemented.
  2. Just about everyone takes notice and tries to exhibit the “proper behavior/values.”
  3. Folks in the “private tribe” don’t dare come out of the closet.
  4. The passionate person who found his/her voice in Agile is like a fish out of the water. Sooner or later he/she looks for a tribe elsewhere.
  5. The company becomes more diluted on folks who are willing to try new things and have the drive to make them happen.
  6. The products and the supporting processes continue to be mediocre.
  7. Goto step 1.

Reading the article Getting Toyota Out of Reverse, published in the December 18 issue of BusinessWeek, I found a fascinating linkage between the two posts:

“They say that young people are moving away from cars,” Toyoda said. “But surely it is us—the automakers—who have abandoned our passion for cars.”

One had better take notice when the president of Toyota speaks of the effects of loss of passion using phrases like “irrelevance or death” and “grasping for salvation”.

You need go no further than John Hagel‘s recent post Pursuing Passion for a resounding second opinion on the subject.

The Headlong Pursuit of Growth, and Its Aftermath

with 4 comments

The December 12-18, 2009 issues of The Economist features a couple of fascinating articles on Toyota Motor Corporation. According to The Economist, Toyota’s President  reached the following dire conclusion on the situation Toyota is facing:

Mr Toyoda’s alarm call last month appears partly to have been prompted by reading “How the Mighty Fall”, a book by Jim Collins, an American management writer, which identifies five stages of corporate decline. Mr Toyoda reckons that Toyota may already be at the fourth stage. Companies at this point, says Mr Collins, frequently still have their destinies in their own hands, but often flit from one supposed “silver bullet” strategy to another, thus accelerating towards the fate they are trying to avoid.

In the litany of things that went wrong, an interesting point is made about the Toyota Production System:

… the recalls continued and Toyota started slipping in consumer-quality surveys. A year later Consumer Reports, an influential magazine, dropped three Toyota models from its recommended list. The magazine added that it would “no longer recommend any new or redesigned Toyota-built models without reliability data on a specific design”. People within the company believe these quality problems were caused by the strain put on the fabled Toyota Production System by the headlong pursuit of growth.

Whatever Agile method you practice – Scrum, Lean, Kanban, Crystal, etc. – you need to be cognizant of three touch points with the Toyota experience reported above:

  • Just like the Toyota Production System, your software method is a “vehicle” which is subject to policy decisions from above. It cannot, however, compensate for policy failures.
  • If your company relentlessly pursues growth, the quality/technical debt liability it is likely to incur coud easily outweigh the benefits of growth. Consider the upside potential of growth vis-a-vis the downside of the resultant technical debt. When appropriate, monetize technical debt using the technique described in Technical Debt on Your Balance Sheet.
  • In addition to monetizing the technical debt, evaluate the various kinds of risks indicated in The View From The Executive Suite. A sense of how devastating those might be is given by Toyota’s own experience:

Just as Cadillac used to be synonymous with luxury and BMW with sportiness, Toyota was a byword for quality and reliability… The danger in all of this for Toyota is that its loyal (and mostly satisfied) customers in America have long believed that the firm was different from others and thus hold it to a higher standard. The moment that Toyota is seen as just another big carmaker, a vital part of the mystique that has surrounded the brand will have been rubbed away.

Please remember – unless you work for Toyota Motor Corporation, chances are your company would not be able to take the kind of risk Toyota can.

Socializing Kanban with Your Executives

leave a comment »

The topic Socializing Agile with Your Executives has been a major thread in this blog. A convenient to browse compilation of posts on the subject can be found in the Starting Agile category. In particular, two recent posts – The Business Value of Agile Software Methods and It Won’t Work Here – are quite specific on the data to use and the line of reasoning to follow in such discussions.

When it comes to socializing Kanban with your executives, you might choose to start the conversation by looking at the defect tracking system your company is using. Chances are your executive will “discover” the all important aspect of flow simply by examining the system with respect to some natural questions such as:

  • Have more defects been closed than opened over the past month?
  • What is the average time to close a reported defect?
  • How many defects have been open (in one stage or another) in the system for more than a year?
  • When a defect moves from one stage in the system to another, how does it get aligned with the various activities that need to take place in the release management system?
  • If development and QA were to stop everything they do and just work exclusively on closing defects that have already been captured, could they clean slate in six months?

The power of this straightforward approach lies in the ease of making the mental jump from defect to Kanban in the context of the tracking system. The breaking down of an epic or a story to granular components that can be pushed to members of the Agile team is not always an easy concept to grasp (and often times a technique teams struggle with in the initial phases of an Agile roll-out). In contrast, one can simply visualize defects entered into the tracking system as inputs to a de-facto Kanban system. Obviously, the defect/Kanban maintains its identity as it “flows” through the system all the way from being reported by a customer to communication of its resolution to the customer. 

If your defect tracking system does not easily lend itself to answering the questions listed above, you might try one of the public domain data sets from Mining Software Archives. The specific data, of course is not likely to be applicable to your company. The criticality of flow, however, could probably be demonstrated by making a few fairly straightforward assumptions on the operating environment behind the data.

Written by israelgat

December 8, 2009 at 5:35 am

Continuous Improvement is Always the Glue

leave a comment »

Corey Ladas makes an interesting observation in Scrumban, pp. 73:

Continuous improvement is always the glue that binds the social contract of the lean organization. Everybody is expected to improve, at all times.

Corey’s observation is quite relevant to the commitment proposed in the posts A Social Contract for Agile and Addition to the Social Contract:

Commit to invest in Agile training ; apply the training to employees who  might be affected by forthcoming layoffs just as you apply it to those likely to be kept with the company. 

The commitment discussed in these posts is an ingredient of the glue Corey writes about.

Written by israelgat

July 1, 2009 at 9:39 pm

It is Not What It is that Really Matters

with 2 comments

Rob Bowley wrote a thoughtful post entitled Kanban it just a tool, so why is it being treated like a methodology? To quote Rob:

The thing that’s making me itchy is how Kanban has somehow been elevated into a methodology unto itself… I’m sure proponents of Kanban will say no one is suggesting Kanban is a methodology and I would agree I’ve not seen anyone say it is. The problem is interpretation. People have a habit of focusing on rules and methodologies because they’re a lot more easy to tackle than the problems they we’re created to solve… Kanban is a small part of something much, much bigger, see the whole.

While I agree with just about everything Rob writes, I would like to point out two aspects of Kanban that are of great importance in the context discussed above:

  1. Kanban seems to have an effect on individuals, teams and organizations. The case studies in the LK2009 conference proceedings document some very interesting dynamics.
  2. From a marketing standpoint, Kanban is a fantastic sound bite. I am hard pressed to recall when I last heard such a catchy sound bite.

I have no doubt that additional case studies on the effects of Kanban will be very beneficial. I also know that sound bites can lose popularity faster than you can say “Kanban.” Finally, I wholeheartedly agree with Rob on the importance of setting realistic expectations around  the tool.

Having said that, I would refer the reader to Dean Leffingwell’s post on the LK2009 conference in which he gives the overall lay of the land from multiple perspective. The picture might, of course, change. However, Dean provides a summary that integrates all important aspects of Kanban as we experience and know them now.

Written by israelgat

May 20, 2009 at 8:48 am

Posted in Kanban, Lean

Tagged with ,

More on Kanban from John Heintz

leave a comment »

Colleague John Heintz posted today on the Kanban board he and one of his customers implemented in a few days. John describes the economy of so doing in the following words:

Some of the tools that we use include sticky post-it notes and Stikky Clips. (Note: We found the Stikky Clips at a teacher supply store, not a big office supply store.)

I am impressed: John seems to hit the ground running immediately after the LK2009 conference.

Written by israelgat

May 19, 2009 at 12:18 pm

Posted in Kanban, Lean, The Agile Leader

Tagged with ,

John Heintz on the Lean & Kanban 2009 Conference

with 23 comments

Colleague John Heintz has kindly compiled the summary below for the benefit of readers of The Agile Executive. John is well known to Agile Austin folks as well as to out-of-town/state companies to which he consults through his company. You can get a glimpse of his Agile/Lean thinking by reading his blog.

Here is John’s summary of the conference:

The Lean Kanban conference last week in Miami was astounding. David Anderson did a fantastic job, and everyone who contributed had great presentations.

I am humbled and emboldened at the same time. I’ve been involved in Agile since 1999 and Lean since 2004, so I thought this was going to be familiar to me, old hat.

Here’s my confession: I’ve pretty much ignored Kanban, writing it off as just slightly different than what good XP or Scrum teams practice anyway.

Wow, those small differences make a huge impact. I am very glad I decided to go to the conference, some internal hunch finally winning.

Here’s what I thought Kanban was before last week:

  • A Big Visible Board
  • A Prioritized Backlog
  • Close communication, minimizing hand-offs
  • Rules about cards on the wall

No Iteration/Sprint boundaries (I’m thinking more efficient but maybe losing something important…)

That’s all well and good and true enough. Easy to justify writing it all off with “I already know enough to help teams make a big difference”. In fact, Kanban can be boiled down to one single rule:

  • Limit the number of things in work to a fixed number.

But, if that’s all there is too it, why then did I hear things like these:

  • Kanban is easier to introduce to teams than Agile/Scrum/XP
  • “People who never say anything were offering ideas” (I’m pretty sure I heard this three time the first day…)
  • The team felt comfortable dropping estimates/retrospectives/standup questions/…

Wait, you say, this was the first conference and obviously full early adopters! Of course people are going to succeed because they self-selected for success. Good point, but that’s not everything that’s here. For example, Chris Shinkle’s presentation was a case study of rolling out Kanban to many teams who hadn’t asked for Kanban.

So between furiously scratching down notes[1], listening and tweeting[2], I started to think to myself:

  • Why does this make such a difference?
  • Easier to create thinking and reflective teams! Isn’t that cultural change?

I had the pleasure of wrestling this “why” question out with several people, especially Alan Shalloway.

The first answers people gave me were entirely unsatisfying:

  • David Anderson’s reply tweet: “Kanban is easier than Scrum because you don’t change any roles or workflow and you don’t teach new practices.”
  • Alan Shalloway first response: “Kanban cuts out the noise and reduces thrashing.”

Sure, sure, but none of those (good) things seem likely to create: cultural change, engaged teams, or reflective individuals. Those answers are technical, details, and generally not the “emotionally” important things needed for change. Mind you, I’m not really well versed in cultural or emotional change, but being the stubborn person I am, I kept digging.

Here’s where Alan and I got, please add any insights[3]:

  • My hypothesis: Kanban has concrete reflective tools: like “should WIP be 4 or 5?”. Very reflective, but not very abstract or hand-wavy. People can’t often use abstract reflective tools like Retrospectives.
  • Paraphrasing Alan Shalloway: Kanban reduces the fear of committing to a per story estimate – a significant risk in some teams. Less fear can lead to cultural change.
  • (not sure who): Kanban changes the focus away from blaming an individual to examining why stuff is stuck on the board. (I hear Deming…)

—-
On to the actual trip report. Here is an abbreviated transcription of the proceedings of the conference. (Very abbreviated!)

  1. Alan Shalloway started the conference off with no small announcement: the formation of the Lean Software and Systems Consortium. He also mentions that this consortium will be creating a body of knowledge and promoting a distributed certification process. Certifications will be a very interesting topic, my initial reaction was negative. Now I’m just skeptical 😉 I’ve got a hunch that TWI, a hidden influence of Lean, may hold some of the secrets for a successful certification method. We’ll see how this plays out.
  2. Dean Leffingwell gave a keynote on a Lean and Scalable Requirements Model for Agile Enterprises. Very clear from executives down to team activity: maps from Themes to Epics to Features to Stories. This immediately cleared up some questions I and a client were having.  My favorite quote: “If you don’t know hot to get the story out of the iteration – don’t let it in” referring to acceptance tests.
  3. Peter Middleton presented material from “Lean Software Strategies“, co-authored by James Sutton who presented next. Peter is a professor at Queen’s University in Belfast and was the first person to really talk about the people issues. Much of what Peter related was how various practices caused people problems: recruiting and training goals (10 per week) would require recruiters and trainers to push even unqualified people into the company. That led to poor service, high-turnover, and greater costs.
  4. James Sutton has a small personal goal: to save the middle class. His presentation did a good job ranging over various Lean and Systems thinking topics, connecting the dots to Agile. Key quote comparing Lean and Agile: “Getting Prepared” vs “Getting Started.
  5. Sterling Mortensen presented a case study of introducing Lean into the Hewlett Packard printer development division. He said HP was already the “best of breed” and still became much more efficient and effective. My favorite quote: “Stop Starting, Start Finishing“. Sterling also said the “One” metric was continuous Flow. I’m not sure I understand that all the way; I’d been working under the assumption the One metric was customer to customer cycle time (from concept to cash.)
  6. Amit Rathore gave a personal case study of Lean in a start-up, http://runa.com. Amit showed many examples and talked really honestly about his experience. My favorite quote: “not released equals not done”.
  7. Corey Ladas presented on his book Scrumban and his experience at Corbis (with David Anderson) and other projects. I bought a copy of his book out of his backpack and made him sign it.
  8. Jean Tabaka presented a thoughtful presentation on Lean, learning, ignorance, and people. Her narrative helped me further realize how Lean, and Kanban, play into the personal issues of learning and reflecting.
  9. Alina Hsu presented a case study of using Lean to organize the work of procuring a COTS (commercial off-the-shelf) software solution, not development. She had some great things to say about how delays cause major cost overruns. One thing that reduced the delays she mentioned was to change how agreement was reached. The team defined consensus as “I can live with it”, with the rules 1) I won’t go into the hall and try to subvert it, and 2) I won’t lose any sleep. These definitions help teams make decisions faster and reduced waste.
  10. Alan Shalloway presented on a model for understanding Lean and moving it beyond Toyota. He organized all the various concepts down into Lean Science, Lean Management, and Lean Education. Connecting this back to the Lean SSC announcement in the morning he said the consortium working to create value in those three areas.

And that was just the first day. Did anybody mention the conference day started before 8am and lasted till after 6pm? Oh, and everyone was glued into the room.

  1. David Anderson presented a keynote on the principles and evolution of Kanban. So much information! You’ll have to read his presentation and see the video on InfoQ, but just to provide a fragment from each I wrote down:
    • Principled recipe for success (including Balance Demand Against Throughput)
    • Metrics (like WIP is a leading indicator)
    • Agile Decision Filter questions
    • Lean Decision Filter questions
    • Kanban decouples input cadence, cycle time, release cadence
  2. Karl Scotland continued the detailed treatment of Kanban. Karl spoke about the Lean concept of Flow as expressed with Kanban – and even rename typical process steps to avoid any baggage with waterfall terminology. If you want to know more about how work actually gets done in a Kanban system, watch his presentation. His interesting names for for process steps are: Incubate, Illustrate, Instantiate, Demonstrate, Liquidate.
  3. Rob Hathaway presented a case study of his work building a game portal for a publishing business. He believed very strongly that teaching from principles (Value, Prioritization, WIP limits, Quality) led to success.
  4. Alisson Vale presented a tool… that enchanted everyone in the room. David Anderson himself said that Vale “has the highest maturity software team on the planet”. Now, tool support often isn’t the answer, and many teams get real value with a physical board – a tool isn’t a Silver Bullet. If a tool makes sense for you – this tool absolutely blew us away. I asked Alisson about buying or helping with the tool and he said they were considering open sourcing it! I offered my coding skills in extending it for my own clients to help reach that goal.
  5. Linda Cook presented a case study of using Kanban at the Motley Fool. Her presentation does a good job of showing how little is necessary to get a lot of value out of Kanban.
  6. Eric Landes gave a great case study about using Kanban in an IT development shop. His team went from struggling to turn requests around (41 days) to a rapid 9 day turn around. Again, his discussion of the team dynamics and reflection were interesting to how a tiny bit of Kanban can have a huge impact.
  7. Eric Willeke’s presentation was visually beautiful, but you’ll have to watch the InfoQ video to get the value out of it. It contained only two words in a quote bubble (from memory “Momma! Pirates!”) and was the backdrop for the story that he told. His story highlighted to me, again, that Agile doesn’t always stick but Kanban seems to.
  8. Chris Shinkle presented a multi-case study on rolling Kanban into a large software consultancy. Very interestingly, and contrary to much discussion before, Chris presented a practices first, principles later message. This again resonated strongly to me that Kanban practices are somehow special in encouraging people to reflect and reach for the principles.
  9. David Laribee presented an opinionated view on leadership and change using Lean. This quote stuck with me: “people support a world they help create”. His style of leading is to drive from “Values -> Practices -> Tools” and his presentation wove a story of Agile/Lean process change. Also, I really enjoyed his injecting reference to hardcore technologies: REST, Git and OSGi were fantastic to see in a Lean/Kanban presentation.

That was day two. I’d said we were all glued to the room before, now as I type this I realize our brains were coming a bit unglued at this point. Every presentation was top-notch, barely time for questions, breaks were cut short, and we came back for more as fast as we could. Oh, and apparently we collectively drank 2.5 times as much coffee as the hotel usually allocates for a group our size.

I’m not going to summarize the Open Space. Too many topics and changes in direction. You just had to be there 🙂

Cheers,
John Heintz

[1] I used the first 25 pages of a brand new notebook… for a 2.5 day conference… Every session had an overwhelming amount of information, and I’m glad InfoQ recorded video.
[2] My twitter account is http://twitter.com/jheintz, and you can follow everyone’s conference coverage at http://twitter.com/#search?q=%23lk2009.
[3] I’m going to keep following up on this topic in my personal blog: http://johnheintz.blogspot.com

Dean Leffingwell on the Lean & Kanban 2009 Conference

with 4 comments

As the recent podcast with Dean was held prior to the Lean & Kanban 2009 conference in Miami, I enquired through email about his major takeaways from the conference. Here is Dean’s answer:

I obviously think Lean Software will be big. It will be to the enterprise what Scrum is to teams.

I believe that Kanban (a subset of lean, being used as an agile team method now), will be more readily adopted in 3-5 years than Scrum.

Reasons:

  • Easier to adopt at the team level.
  • Far less overhead for planning and estimating, and fewer ceremonies (approaching zero in the edge case and with appropriate context).
  • Based on both solid science and people aspects: theory of constraints, continuous flow and pull. Kaizen mind.
  • Much easier to sell to PMO and VP level folks where agile=Dilbert=bad, and Lean=Toyota=good. Plus you can lean a PMO with value stream analysis and other tools. What do you do in a PMO with Scrum?
  • Support from industry stalwarts such as Lockheed Martin, who are applying proven lean manufacturing practices to software development for projects like the Joint Strike Fighter. i.e industries on the other side of the agile chasm are adopting Lean now and will provide creature comfort for enterprises considering the leap.
  • Plus agile already has a bad rap (perhaps undeserved) in many of those places; lean does not.
  • Lean and Lean SSC’s focus on the role of management in continuous improvement and problem solving, as opposed to agile, where management is either a “chicken” (you can attend our meetings, but you have no role in our process…)  or an “impediment” (If you attend an agile conference,  manager’s, CEOs etc are routinely denigrated; that does not help our industry).
  • Lean provides richer tools for improvement for the manager and practitioners – Kaizen meetings, five whys, root cause analysis, theory of constraints, flow and pull science and metrics,  cumulative flow diagrams, etc. rather than just  the single “retrospective.”
  • Question: does agile scale? In my opinion, yes, but it is arguable in the industry. Question: Does Lean scale – Yes, not remotely arguable. Lean started at scale.
  • Lean optimizes the whole enterprise and gives you tools to reason about the enterprise, from order to shipment, rather than just the team optimization. 
  • Potential for leadership from the Lean SSC as an open, science and knowledge-based consortium with an academic and industry approved certification process for managers and practitioners.
     
    I could go on and on, this is just the short list.

In addition to Dean’s insightful points, a guest post on the conference will soon be published in this blog by colleague John Heintz. If you look for stroke-by-stroke coverage of the conference, Mike Cottmeyer‘s posts on the subject in Leading Agile are very informative.

Written by israelgat

May 9, 2009 at 4:34 pm

A Note on the Kanban & Retrospectives Post by David Andreson

with 3 comments

David Anderson wrote an interesting post on Kanban & Retrospectives. David observes that some seasoned Kanban teams ceased doing “official” retrospectives. To quote David:

Some mature Kanban teams did drop the use of retrospectives. No one told them to do it. They just did. Retrospectives were not adding value in their lives and hence were seen as a wasteful activity that could be eliminated.

David carefully examines retrospectives in the Kanban context. His concluding recommendation is as follows:

Kanban can enable a team to reach a level of maturity where they may choose to eliminate retrospectives (or not.) It’s a choice! Every situation will be unique. The important thing is not to see elimination of retrospectives as wrong or bad or “not agile.” Equally, don’t rush in and eliminate retrospectives. Don’t proscribe retrospectives. Let the team make its own decision when it is ready and embrace the evolution of process that comes with continuous improvement.

I certainly understand where David is coming from and the sound logic of his reasoning. However, the question on my mind is whether core Scrum practices could be reduced without jeopardizing the method. The following excerpt from a recent Cutter Consortium post entitled Breaking the Facade of Truth: An Introspective View into and a Case Study About the “Apparent Truths” of Agile by David Spann nicely summarizes how minimalistic Scrum is:

Scrum, as a management methodology, is elegant in its design, requiring only three roles (i.e., product owner, ScrumMaster, and self-organized team), three ceremonies (sprint/iteration planning, daily Scrum/debrief, and sprint review meetings), and three artifacts (product and sprint backlogs and the burndown chart) — just-enough practical advice so agile teams do not overcomplicate the development lifecycle with too much ceremony and documentation

Can one meaningfully drop a core practice of a just-enough method?

Opinions please!

Written by israelgat

March 21, 2009 at 2:07 pm