Response to Lynda Bourne on Agile and the Business message

The following is a comment to Lynda that I was not able to submit to her blog. You can find Lynda's original post here.

@Lynda

Nice post. I'm glad that the conversation is continuing. Both PMI and Agile people need this dialogue.

A couple of comments on your post.

1. I agree that Agile Advocates need to learn to speak to the business people. However,

2. Agile adoption has been fast in many places, not slow.

It is true that many Agile Advocates (AAs as you call them -- like the analogy BTW, and think it fits! :) don't talk "business-ese". That's been a failure of the community, however that is far, very far from being a problem in adoption. Having been involved in two major organization change projects I can vouch for the lack of business-oriented communication, but I can also assure you that speed of adoption has been anything but slow. I know of a company that has several 10's of thousands of employees where Agile is a topic of discussion at all levels, from top management to the team level. This is very encouraging, especially because this company has not been shy in removing some of the building blocks that are in PMBOK (and inadequate to software development) and build new processes at all levels based on the principles of Agile Software Development.

3. Agile software development needs discipline

I agree with this, but the lack of discipline existed in software organizations when PMBOK was the prevailing framework for organizing projects. Lack of discipline is a problem that Agile encoutered when it started, not a problem created by adopting Agile software development methods. Indeed, it is my experience that agile software development builds a much higher level of discipline into the development process than was previously the norm.

4. Agile alignment with business objectives.

This is a topic for a post in itself, but I'll just refer one example of how agile brings focus and alignment with business goals. Check this post by Dean Leffingwell where he explains how requirements management in Agile can be done in a way that directly reflects the strategy of the company.

Let's continue the dialogue. I've learned a lot and hope to continue learning from it! :)

Response to critical article on Kanban

I was reading Chris McMahon's post "Against Kanban" and could not help but think that a response was in order. The post below is a response, in detail to the (flawed) arguments that Chris makes against Kanban.

"were revolutionary, because they were software development processes actually created from scratch by people who were very very good at creating software."

In here, however you forget that Mike Beedle and Ken Schwaber explicitly mention the chemical industry as a source of learning when putting together the explanation for the success of Scrum.
You further forget that Jeff Sutherland (and others) have often referred to Takeuchi's and Nonaka's paper (The New New product development game) that is straight from, you guessed it: manufacturing!

"if your team measures velocity and uses velocity to plan iterations, and if your team always does pair programming, test-driven development, and continuous integration, then you will either release excellent software every iteration; or you will quickly expose and face the reasons why not."

In this phrase you seem to imply that one cannot use the same XP practices with Kanban. Here again you are wrong. All of the practices that make Scrum "work" can be used to make Kanban "work".

"Before we started releasing every iteration, my team had been using a kanban-like process."

This argument is disingenuous. You should have said that you did not have timeboxed iterations. Kanban is much more than not having timeboxed iterations and you fail your readers when you associate a previously used process (not working by your own admission) with something you quite clearly do not fully grasp. A bit like what you blame on your so called "kanban expert".

"Furthermore, it was an enormous headache for the marketing people. Without timeboxes or estimates, it was difficult to know when a particular feature would be available, which made it almost impossible to do effective marketing for the product."

If you had any experience with Kanban or indeed if you knew more about Lean you would know that this phrase does not make any sense in the Lean context. In a (properly working) Lean process you always know when you are going to ship something, that's why Lean is being adopted in the first place. The fact taht you state lack of predictability as a problem inherent to Kanban just means that you don't understand it -- which is fair, but in that case you should not write condemning articles, you should first prove your Hypothesis (BTW: the Hypothsis-Test-Theory cycle, aka PDCA, is at the heart of Lean. Just google for "a3 report problem solving")

"The fundamental difference between software development and manufacturing or engineering is that in software development we do not manipulate physical objects."

This is an obvious truth, but you don't explain the consequences of this phrase. The (other) fact is that manufacturing, like other industries, are very process oriented and processes from all industries have similar theoretical frameworks! Therefore what you learn from processes in the chemical industry (to use Beedle and Schwaber's example) can be used in the software industry!

"I'm sympathetic to those who see estimation and iteration planning as waste, but I think the risk inherent in not having a mechanism to expose our inadequacies is too much risk to take, even for the best of teams."

In this phrase you make an implicit sylogism by which not having estimation and iteration planning leads to not being able to see what is wrong. This is clearly due to your lack of understanding of how a "flow" process can work. In a flow-like process (e.g. Kanba) you don't just retrospect at the end of the iteration (there's none), you retrospect much more frequently, even sometimes a day. This is indeed a much more powerful way to expose "inadequacies" as any tester knows.

"can you deliver running tested features on a consistent schedule? Iteration timeboxing exposes that metric in the most obvious way possible."

I agree that timeboxing exposes the features delivered/iteration metric. Heck, I've been using that metric myself to explain why you don't actually need to estimate (one of the basic problems in Kanban according to you). The point is that the metric you say is impossible to gather with Kanban is the very metric that makes Kanban transparent to the business owners (the cycle time, or how long does it take to deliver 1 feature). You seem to have missed this point also.

"What we find in both literature and anecdote about the application of processes taken from manufacturing and engineering, puzzlingly, is that for every team for which the process is successful and helpful, there are other teams who implement the same process only to meet with failure.

What I suspect is that ANY process or methodology (that is not actively destructive), applied to a skilled, disciplined, high-functioning, motivated team, will succeed, regardless of the process. Likewise, any process applied to a low-functioning team will likely fail."

I agree with these two paragraphs, but the same is true (like you say) for ANY process, even those that did not originate from the manufacturing industry. At this point your post is contradicting itself...

"With an XP/Scrum sort of iterative process, we will know very soon exactly how and why we are failing. This seems to be not true of kanban or of any other software development process taken from the manufacturing arena."

Having read the other comments above you know how false this statement is. The point is that in Kanban restrospectives are part of everyday work (when it is working), therefore you actually find out "how and why we are failing" much faster than in a timeboxed iteration-based process!

Maybe you should also take a look at this post: http://bit.ly/7NhAg in it the author claims (and I can't verify it) that they release software 50 times a day. If you get to that point, what's the reason to have iterations. By your own metric (features released/iteration) this team is already over achieving to the point of making the metric useless...