Archive for May 2009
We have Come a Long Way
I am involved these days in a bid to develop a suite of applications for a few inter-related data centers. There is nothing extraordinary about this bid. I have no doubt quite a few readers of his blog are routinely involved in similar undertakings.
Two stipulations, however, impressed me in the RFP:
- Explicitly stated preference for choosing a vendor who uses Agile methods.
- Requirement to have working code drops every week.
Both vendor preference and the working code requirement have been documented in writing as well as stated verbally in face-to-face meetings. Moreover, best I can tell most other stipulations in the RFP (other than the functional requirements and a clause about location of the team) are about characteristics of the operating environment in these data centers, not about how the “sausage” should be made.
I have been doing Agile since 2003. I do not recall seeing such Agile stipulation at the heart of routine RFPs.
It is a Team, not a Clinic
We have by now held three sessions of the Agile Austin “Ask an Expert” service. The thing that impressed me most in these three meetings is the effectiveness of the the team discussion modus. Rather than make the clinic a series of 1-1 consultations, we followed Scott Killen‘s good suggestion to conduct it in the manner articulated in the statement of purpose:
Team discussions with any Agilists attending the program will be encouraged to maximize the sharing of experience and draw out the wisdom of crowds.
It is starting to become evident we enriched the experience and made it more gratifying by moving away from the {professor –> student} modus. The sessions are kind of everyone singing, everyone dancing. Rather than a plain answer for a plain question, we get much richer threads. Moreover, it is obvious the experience one clinic “patient” shares with another is as valuable as the expert advice.
We are starting to see repeat “patients.” It is really becoming a team more than a clinic.
A Note on the Standish CHAOS Reports
In his recent seminar Advanced Agile Project Management Workshop, Jim Highsmith made the following comment on the interpretation of the Standish CHAOS Reports:
The Standish data are NOT a good indicator of poor software development performance. However, they ARE an indicator of systemic failure of our planning and measurement processes.
Jim is referring to the standard definition of project “success”:
One time, on budget, all specified features
Jim elaborates on this key point in the forthcoming second edition of Agile Project Management: Creating Innovative Products. Stay tuned…
It is Not What It is that Really Matters
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:
-
Kanban seems to have an effect on individuals, teams and organizations. The case studies in the LK2009 conference proceedings document some very interesting dynamics.
-
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.
Recipe for Success in 2009
Colleague Annie Shum sent me the following excerpt from Slate’s Daniel Gross article on P.F. Chang’s spectacular performance in 2009:
The reason: mainstream mall appeal, affordable offerings, and especially good management – based heavily on the principles of “kaizen” or continuous improvement pioneered by Toyota and other Japanese manufacturers. P.F. Chang’s made it to $1 billion in sales by taking cues from successful Asian businesses. Now by focusing on process improvement rather than helter-skelter growth, it seems to be doing so again. Continuous improvement, the philosophy pioneered by Japanese companies such as Toyota in which managers and workers relentlessly seek out small modifications that add up to big profits, seems to be the recipe for success in 2009.
I don’t really know that the excerpt above has any relevance to software engineering. Gross, however, proposes a potential linkage at the end the article:
Low-end standardized service jobs make up more than 40 percent of all U.S. employment. Imagine if more restaurants and service companies started to act like P.F. Chang’s. Innovation and rising productivity are the underpinnings of higher wages, and happy and engaged employees the key to more continuous improvement.
More on Kanban from John Heintz
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.
Questions from “Ask an Expert”
I had the pleasure of participating in the May 7 and May 14 sessions of the Agile Austin “Ask an Expert” Service. You can read the questions/topics brought up in these sessions by clicking here. Following are two observations from the questions cited so far:
- Enterprise readiness issues are rarely understood, let alone addressed in advance of an Agile roll-out. The focus on the “hows” of the process seems to consume the energy of the Agile practitioners. Precious little is left for the “whys.”
- Many questions (and the discussions that follow) are actually about the software engineering fabric, not about Agile per se.
The two are actually related. It is too easy to try to boil the ocean if you do not think of Agile as a single “layer” in the overall software engineering fabric, pretty much along the lines one thinks of a layer such as Transport in the OSI Model. Needless to say, trying to boil the ocean can consume you to the point nothing is left for the deeper understanding of the “whys” of Agile.
The reader is encouraged to take a look at the post entitled The House Jim Built. The two views of Agile given in this post by Cutter consultants Jim Highsmith and David Spann capture the essence of Agile in a lucid manner. You can start with either of the two views, using the one you prefer as a guide to placing Agile in the bigger picture.
(Please note Anne Mullaney‘s kind offer in the thread accompanying the post to send the full copy of Jim’s E-Mail Advisor to readers of the blog. David’s Research Report is in the public domain).
Yours leanly…
Appropriately enough for a post written a few days after the LK2009 conference, colleague Clarke Ching concludes his announcement of the May 21 session of the Agile Scotland clinics with the words “Yours leanly…”
I can’t help wondering whether the next Agile Scotland clinic will be announced using the phrase “Yours kanbanly….”
John Heintz on the Lean & Kanban 2009 Conference
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!)
- 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.
- 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.
- 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.
- 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.“
- 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.)
- 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”.
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
Q2 Agile Success Tour
Various posts in this blog (click, for example, here, here, and here) brought up noteworthy threads from the Rally Agile Success Tour events in Denver, Los Angeles and New York. The Rally team and I are gearing up now for the following events:
- June 4, 2009 in Santa Clara, CA
- June 25, 2009 in Atlanta, GA
- July 23, 2009 in Washington, DC
I have started teleconferencing with the panelists in these three cities. It is clear even at this stage of the preparations we will have an eclectic mix of panelists and various intriguing topics that might not have been fully addressed during Q1. For example, Agile Support for Customer Support is a topic that will be discussed in the Washington, DC event.
A I did during Q1, I will report here highlights from the events. Stay tuned…
The Agile Executive 