In their keynote at XP Day last December Dan Jones and Marc Baker talked a little about the attempts to bring Lean to the National Health Service. One of the issues they mentioned was that while everyone “could talk the language”, many people had been on courses and many people agreed it was good very few people wanted to make the change.
I recognise the scenario and its one that is on the increase - and not just in the health service.
When a company asks me to help them “get Agile” I start by talking to people. At first I avoid mentioning Agile, we talk about their team, their company, the problems and opportunities they face, the frustration and the changes they want to me help make. I increasingly find that these people say something like “I’ve worked Agile before”, “I went on a course”, “We are quite Agile ... we get pulled in many different directions” or “We’re trying to be Agile... we do stand up meetings”.
There is a debate going on - its been going on for a while but its louder at the moment - about just what “being Agile” means. Lean is being talked about more, either because people want another buzzword or because the true roots of Agile are now clearer.
Few people want to stand up and say “We’re not Agile” - its like saying “I don’t like Apple Pie” or admitting to an embarrassing medical condition. While is hardly surprising it is also a defence mechanism, and it can be a resistance to change.
Increasingly I don’t want to use the word Agile. The word brings a lot of baggage - pair programming, Scrum Master certification and all the rest. Once you use the word people start to have assumptions about what you are going to do.
Sure, many of those assumptions are reasonable: I probably am going to suggets they do visual planning and tracking, I probably am going to send the developers on TDD courses, and I am probably going to organise morning “stand up” or “Scrum” meetings.
But I’m not going to force pair programming on anyone, I’m not going to dogmatically demand 30-day sprints and I’m not going to force testers to write Java.
What I’m more interesting in is creating and instilling an improvement culture grounded in learning. My aim is to improve the way people develop software and run the company today.
So what word do I use for this?
I don’t think there is one. I’m starting to talk about Operational Excellence in Software Development. While that might sound like a bunch of management speak I think it is a better description of what I am trying to achieve.
But this term too has problems.
First it is management speak and a lot of people hear the word “excellence” and think “how can we run before we can walk?” - they see their organization as such a mess that excellence has little or nothing to do with the fire-fighting they do everyday. So any manager which talks about “excellence” is clearly disconnected from the real world.
Second the keyword problem: we live in a keyword driven society, you search Google for a keyword, you SMS a single word to a service, you Twitter half a dozen words, your CV/resume is scanned by software looking for keywords. “Operational excellence in software development” is five words, and includes two expressions which will trigger a million Google hits by themselves.
(Before you ask OESD doesn’t work as a keyword, Old English Sheep Dogs for starters.)
Still, the thing I like about Operational Excellence in Software Development is describes what you want to achieve - what you want to build - not how you are going to build it. “Agile” could have done that once but it was never given the change, look at the Agile manifesto, its about how, not what. It was good at the time but the world’s moved on.
Monday, March 09, 2009
Tuesday, March 03, 2009
Making sense of Kanban (and some doubts)
As regular readers will know I’m a fan of the Kanban software development process championed by David Anderson. However it has to be said that the jury is still out on Kanban.
I’ve come to the conclusion that one of the dangers with Kanban is actually one of the reasons I like it. To properly implement Kanban you need to create a learning culture, there really needs to be a drive towards learning, change and improvement. Kanban raises the importance of understanding and creating a learning organization. Let me explain...
Depending on your point of view, Kanban might be:
a. The first second generation Agile development method
b. A collection of common heuristics
c. Dangerously unAgile
d. None of the above (a-c)
e. All of above (a-c)
f. Just another marketing term
Over at the Peripatetic Axiom blog Keith Braithwaite was voicing some doubts last week.
I had lunch with a Scrum trainer recently who commented “There’s nothing really new there, its stuff people have been recommending for a while”. I’ve said some similar myself - I find Kanban as described fits better with the way I’ve been coaching and running Agile teams for five years.
But then, isn’t that where Agile itself started? - people collecting heuristics and making sence out of them?
The Kanban community is not ignorant of some of the issues, Karl Scotland has a recent blog post about not mistaking Kanban for waterfall.
I have to say, some parts of Kanban worry me. For example, I’ve been telling teams for a while to think management by routine, the drum beats you have a planning meeting, a drum beats again and you do a demo, and so on, it all happens in a predictable fashion. So dropping iterations gives me the willies.
Keith’s point about batch size is well taken. Its all very well to talk about Minimally Marketable Features (MMF) but sometimes what the business thinks of as a MMF is a pretty large project in its own right. I remember one customer who’s idea of an MMF was “Works on Mac” which was a pretty major piece of work before we started to even consider the design limitations imposed, and the ones the engineers dreamt up.
Perhaps one of the reasons so many Kanban success stories involve maintenance teams (I have one too, I promise to publish it soon) is because bug fixes make nice MMFs.
However I don’t think this problem is confined to Kanban. All the Agile process suffer with a version of it. Scrum encourages teams to focus sprints on some meaningful goal, basically an MMF at the sprint level. The work breakdown, from business feature to developer tasks is a central plank of Blue-White-Red Agile.
I’m not doubting that teams can come up with small, non-bug fix, MMFs, I just think its difficult. Some technologies make it easier than others, e.g. its easy to come up with an MMF if you are coding a Ruby on Rails website and much harder if you are coding a C++ shrink-wrap legacy app.
Its also a sign of team maturity - both the development team and business team. The more experience the development team is the more likely they are to come up with a work breakdown were each item makes a meaningful contribution to the overall goal and delivers value to the business. It helps if the teams management is good at getting the team to look at options before deciding on what to do.
The business also needs to be experienced in both identifying small deliverable elements and they need to trust the development team. Rather than ask for the World (because they expect to be delivered Luxembourg) they need to be prepared to ask for Holland (and expect to get Holland).
There is something about Kanban that has troubled me for a while and I’ve not been able to put my finger on. Oddly its related to the fact that I’ve found teams pick it up more easily than Scrum based processes. And it goes back to Karl’s point about a superficial resemblance to waterfall.
I’ve finally worked it out: Kanban needs a culture of learning and improvement. Without a relentless drive to improve teams can fall back to glorified waterfall.
With Scrum, or XP, you know you are doing it because there is a lot of information on how to do it. If you start breaking a Scrum practice (without agreeing it in a retrospective) sooner or later someone will pull you up on it. Kanban removes that safety net.
At the moment the safety net doesn’t exist for Kanban. In five years it might be different because there will be more published on it. But in a way I hope not because the need to learn and improve is what I value in Kanban and its why it maps better to my model of development. A safety net might limit the learning and improvement.
The learning culture you need for Kanban is, perhaps, the result of it drawing more directly on Lean than some other Agile methods. In the absence of a safety net teams must think through problems and find their own solutions.
I think Kanban is here, it is here to stay and it will be found useful. But like other methods it won’t work in some places. With any Agile or Lean method there is an riding consideration:
There is no reason why one method is universally applicable.
Some times one method is more appropriate and sometimes another works better - horses for courses. Scrum is best in some work, XP elsewhere and Kanban in others. And all methods need to tailoring, sometimes you need to roll your own method.
I’ve come to the conclusion that one of the dangers with Kanban is actually one of the reasons I like it. To properly implement Kanban you need to create a learning culture, there really needs to be a drive towards learning, change and improvement. Kanban raises the importance of understanding and creating a learning organization. Let me explain...
Depending on your point of view, Kanban might be:
a. The first second generation Agile development method
b. A collection of common heuristics
c. Dangerously unAgile
d. None of the above (a-c)
e. All of above (a-c)
f. Just another marketing term
Over at the Peripatetic Axiom blog Keith Braithwaite was voicing some doubts last week.
I had lunch with a Scrum trainer recently who commented “There’s nothing really new there, its stuff people have been recommending for a while”. I’ve said some similar myself - I find Kanban as described fits better with the way I’ve been coaching and running Agile teams for five years.
But then, isn’t that where Agile itself started? - people collecting heuristics and making sence out of them?
The Kanban community is not ignorant of some of the issues, Karl Scotland has a recent blog post about not mistaking Kanban for waterfall.
I have to say, some parts of Kanban worry me. For example, I’ve been telling teams for a while to think management by routine, the drum beats you have a planning meeting, a drum beats again and you do a demo, and so on, it all happens in a predictable fashion. So dropping iterations gives me the willies.
Keith’s point about batch size is well taken. Its all very well to talk about Minimally Marketable Features (MMF) but sometimes what the business thinks of as a MMF is a pretty large project in its own right. I remember one customer who’s idea of an MMF was “Works on Mac” which was a pretty major piece of work before we started to even consider the design limitations imposed, and the ones the engineers dreamt up.
Perhaps one of the reasons so many Kanban success stories involve maintenance teams (I have one too, I promise to publish it soon) is because bug fixes make nice MMFs.
However I don’t think this problem is confined to Kanban. All the Agile process suffer with a version of it. Scrum encourages teams to focus sprints on some meaningful goal, basically an MMF at the sprint level. The work breakdown, from business feature to developer tasks is a central plank of Blue-White-Red Agile.
I’m not doubting that teams can come up with small, non-bug fix, MMFs, I just think its difficult. Some technologies make it easier than others, e.g. its easy to come up with an MMF if you are coding a Ruby on Rails website and much harder if you are coding a C++ shrink-wrap legacy app.
Its also a sign of team maturity - both the development team and business team. The more experience the development team is the more likely they are to come up with a work breakdown were each item makes a meaningful contribution to the overall goal and delivers value to the business. It helps if the teams management is good at getting the team to look at options before deciding on what to do.
The business also needs to be experienced in both identifying small deliverable elements and they need to trust the development team. Rather than ask for the World (because they expect to be delivered Luxembourg) they need to be prepared to ask for Holland (and expect to get Holland).
There is something about Kanban that has troubled me for a while and I’ve not been able to put my finger on. Oddly its related to the fact that I’ve found teams pick it up more easily than Scrum based processes. And it goes back to Karl’s point about a superficial resemblance to waterfall.
I’ve finally worked it out: Kanban needs a culture of learning and improvement. Without a relentless drive to improve teams can fall back to glorified waterfall.
With Scrum, or XP, you know you are doing it because there is a lot of information on how to do it. If you start breaking a Scrum practice (without agreeing it in a retrospective) sooner or later someone will pull you up on it. Kanban removes that safety net.
At the moment the safety net doesn’t exist for Kanban. In five years it might be different because there will be more published on it. But in a way I hope not because the need to learn and improve is what I value in Kanban and its why it maps better to my model of development. A safety net might limit the learning and improvement.
The learning culture you need for Kanban is, perhaps, the result of it drawing more directly on Lean than some other Agile methods. In the absence of a safety net teams must think through problems and find their own solutions.
I think Kanban is here, it is here to stay and it will be found useful. But like other methods it won’t work in some places. With any Agile or Lean method there is an riding consideration:
There is no reason why one method is universally applicable.
Some times one method is more appropriate and sometimes another works better - horses for courses. Scrum is best in some work, XP elsewhere and Kanban in others. And all methods need to tailoring, sometimes you need to roll your own method.
Monday, March 02, 2009
Japanese translations
As if having Changing Software Development translated to Japanese isn’t enough one keen reader has translated some of my blog entries to Japanese.
Mark Nakamura has translated three of my Agile failure modes pieces
• Failures in Agile process? (original Failures in Agile process)
• More Agile failure modes (original More Agile failure modes)
• Agile failure modes - again (original Agile failure modes - again)
Mark Nakamura has translated three of my Agile failure modes pieces
• Failures in Agile process? (original Failures in Agile process)
• More Agile failure modes (original More Agile failure modes)
• Agile failure modes - again (original Agile failure modes - again)
Friday, February 27, 2009
Requirements not functionality
A footnote to the recent discussion of requirements....
In Competitive Engineering Tom Gilb argues that development groups spend a lot of time focusing on functional requirements but they should actually focus on performance and quality requirements:
“ From the point of view of understanding ‘competitiveness’, ‘levels of achievement’ and ‘associated risk’, the performance requirements are by far the most interesting requirements. Yet, traditionally, too much attention has been given to specification of functional requirements and resource requirements.” Tom Gilb, 2005
Put that in the context of an imaginary payroll software company: understanding what payroll software needs do do is fairly straight forward, most products on the market will do the same thing. But what makes the product competitive is how well it does it.
It relatively easy to list the things your software should do but listing how the software will be more competitive than the opposition, or delivery real business value - rather than a shopping list of features - is more difficult.
In Competitive Engineering Tom Gilb argues that development groups spend a lot of time focusing on functional requirements but they should actually focus on performance and quality requirements:
“ From the point of view of understanding ‘competitiveness’, ‘levels of achievement’ and ‘associated risk’, the performance requirements are by far the most interesting requirements. Yet, traditionally, too much attention has been given to specification of functional requirements and resource requirements.” Tom Gilb, 2005
Put that in the context of an imaginary payroll software company: understanding what payroll software needs do do is fairly straight forward, most products on the market will do the same thing. But what makes the product competitive is how well it does it.
It relatively easy to list the things your software should do but listing how the software will be more competitive than the opposition, or delivery real business value - rather than a shopping list of features - is more difficult.
Monday, February 23, 2009
Requirements: The next challenge for Agile
Continuing my follow up to my latest tell of the Alignment Trap in the Agile Journal and on InfoQ.
Lets get one thing straight: I’m not saying requirements don’t matter.
What I’m saying it: when the context is a broken development organization the most important thing is fixing the delivery process.
In which case, you can, and should, take liberties with the requirements process. Then, when delivery shapes up you should come back and fix the requirements issues. Because requirements is where the long term gain is.
Anyone who thinks I don’t value requirements should look at all the postings on this blog about the importance of Product Managers. The requirements is also where the long term future of Agile is.
Look again at those 4 quadrants:
• Maintenance zone: this segment explains why so many of my friends work at dysfunctional IT shops.
• Alignment trap zone: this explains the traditional approach has failed so badly; companies tie themselves in knots trying to do the right thing when they can’t actually do very much.
• Well oiled IT: this is where Agile takes you. But it leaves you there.
• IT Enabled growth: where we all want to be.
Most companies are currently stuck in the maintenance zone. There are three types of company here:
• those who are happy in the mud; i.e. those who lack the will to do something about it, those who believe IT is always like this, those who earn so much money elsewhere it doesn’t matter.
• those who are trying to move to the Alignment Trap; many will still be drinking “do the right thing” cool aid and are making it worse for themselves
• those who are trying to get to the Well Oiled IT, probably via Agile development
The downturn will finish off many of the companies in the first two groups. Those in Well Oiled will probably be OK, and those who can move quickly will hopefully survive. Still, too many companies will survive despite being stuck in the Maintenance Zone.
There is a whole Agile industry (including me!) helping companies make this shift. To be honest, I’ve come to the conclusion that this is the easy bit. (Don’t believe me? Call me.)
But, what do you do once you get to Well Oiled?
The problem is that while Agile as we know it will get you there it won’t take you any further. It runs out of ideas.
Companies could happily stay in Well Oiled, its a (relatively) nice place to be. And you will probably out compete your competitors. But some of the companies that make it - and those who are already there - will look to go further.
This is where Chris Matt’s point on the Agile Journal site are relevant. Agile as we know it, has largely ignored the Business Analyst and Product Manager roles.
The onsite-customer in XP lacks any kind of strategic view. It worked for the C3 team but they were just replacing an existing system, not inventing a new product or doing great innovation. Even so, the original customer nearly had a breakdown.
Scrum is slightly better, it has a full Product Owner role, but it says nothing about how this role is undertaken. It only speaks about the Product Owner in the Scrum process.
And Chris is right about “user stories.” They are a simple tool for communication with developers. They are not sufficient. To make matters worse most teams use them isolation, they do no adopt scenarios, actors or personas.
How do we fix the problem?
Here are three steps to get started:
1. Recognise the importance of the Product Owner role and staff it properly. You need 1 Product Owner for every 3 to 7 Developers. The newer and more innovative your product the more you need. If you have an older less innovative product you might have 7 developers to 1 Product Owner.
2. Stop looking to Project Managers to fill the Product Owner role. They are not Product Owners and their training is very different.
3. Decide whether Product Owners in your company are Business Analysts or Product Managers. If you develop software for your own internal use (or one client) then they are BAs. If you sell your software (shrink wrap or online) they are Product Managers.
If we are to move beyond Agile software development and build Agile companies it is essential we respect requirements. So far our success has all been based on shifting out the maintenance zone, the next challenge is to move on up.
Lets get one thing straight: I’m not saying requirements don’t matter.
What I’m saying it: when the context is a broken development organization the most important thing is fixing the delivery process.
In which case, you can, and should, take liberties with the requirements process. Then, when delivery shapes up you should come back and fix the requirements issues. Because requirements is where the long term gain is.
Anyone who thinks I don’t value requirements should look at all the postings on this blog about the importance of Product Managers. The requirements is also where the long term future of Agile is.
Look again at those 4 quadrants:
• Maintenance zone: this segment explains why so many of my friends work at dysfunctional IT shops.
• Alignment trap zone: this explains the traditional approach has failed so badly; companies tie themselves in knots trying to do the right thing when they can’t actually do very much.
• Well oiled IT: this is where Agile takes you. But it leaves you there.
• IT Enabled growth: where we all want to be.
Most companies are currently stuck in the maintenance zone. There are three types of company here:
• those who are happy in the mud; i.e. those who lack the will to do something about it, those who believe IT is always like this, those who earn so much money elsewhere it doesn’t matter.
• those who are trying to move to the Alignment Trap; many will still be drinking “do the right thing” cool aid and are making it worse for themselves
• those who are trying to get to the Well Oiled IT, probably via Agile development
The downturn will finish off many of the companies in the first two groups. Those in Well Oiled will probably be OK, and those who can move quickly will hopefully survive. Still, too many companies will survive despite being stuck in the Maintenance Zone.
There is a whole Agile industry (including me!) helping companies make this shift. To be honest, I’ve come to the conclusion that this is the easy bit. (Don’t believe me? Call me.)
But, what do you do once you get to Well Oiled?
The problem is that while Agile as we know it will get you there it won’t take you any further. It runs out of ideas.
Companies could happily stay in Well Oiled, its a (relatively) nice place to be. And you will probably out compete your competitors. But some of the companies that make it - and those who are already there - will look to go further.
This is where Chris Matt’s point on the Agile Journal site are relevant. Agile as we know it, has largely ignored the Business Analyst and Product Manager roles.
The onsite-customer in XP lacks any kind of strategic view. It worked for the C3 team but they were just replacing an existing system, not inventing a new product or doing great innovation. Even so, the original customer nearly had a breakdown.
Scrum is slightly better, it has a full Product Owner role, but it says nothing about how this role is undertaken. It only speaks about the Product Owner in the Scrum process.
And Chris is right about “user stories.” They are a simple tool for communication with developers. They are not sufficient. To make matters worse most teams use them isolation, they do no adopt scenarios, actors or personas.
How do we fix the problem?
Here are three steps to get started:
1. Recognise the importance of the Product Owner role and staff it properly. You need 1 Product Owner for every 3 to 7 Developers. The newer and more innovative your product the more you need. If you have an older less innovative product you might have 7 developers to 1 Product Owner.
2. Stop looking to Project Managers to fill the Product Owner role. They are not Product Owners and their training is very different.
3. Decide whether Product Owners in your company are Business Analysts or Product Managers. If you develop software for your own internal use (or one client) then they are BAs. If you sell your software (shrink wrap or online) they are Product Managers.
If we are to move beyond Agile software development and build Agile companies it is essential we respect requirements. So far our success has all been based on shifting out the maintenance zone, the next challenge is to move on up.
Requirements: better off being generally right than precisely wrong
I’m used to getting a reaction from people when I outline the Alignment Trap, and my article in the Agile Journal - and the subsequent report on InfoQ - certainly stirred up some reaction.
Immo Huneke mailed to point out that the Sloan piece doesn’t discuss how you measure alignment. I’m not sure how I would go about measuring alignment myself, after all what is alignment? Can it be measured objectively?
There is a point here, and I myself am a guilty of making a jump from alignment to requirements. I’ve also used the phrases “doing the right thing” and “doing things right” quite loosely.
The other point which we could argue about is “IT”. The Sloan piece talks about IT. There is no information on whether this relates to hardware, software, IT support or software development.
Despite these caveats I think the central message still holds: getting effective is more beneficial than getting.
Still, I want to make it clear I think knowing what you are doing is essential. And in the long term requirements aligned to the business are very important - see the blog entry that comes after this one.
Its all a question of context.
If you want to fix a broken IT organization I claim, and I believe the Alignment Trap supports this claim, it is best to start by making the organization effective then determining what needs doing.
This context implies that there is an organization, and it is doing “stuff”. It knows some of what needs doing. You might be able to remove some “stuff” (or add more) but basically it is not short of work to do.
I believe that in this situation discussions over what to do (alignment, requirements) are not effective because the history of failed deliveries means there is no trust and it means the business side tries to game the system by asking for more than they need because they believe It will always under deliver.
This context also implies that the IT group is, in general, supporting the business. If your company sells Payroll software and your developers are currently writing a competitor to Grand Theft Auto then I think you would be right in question requirements on day one. But in general, if you sell Payroll software it is likely that your development group are working on Payroll software.
In other words: you are better off being generally right than precisely wrong.
Before you can tackle the requirements problem (and alignment) you need to build a delivery machine that can tackle it.
The Machine that Changed the World contains an example I think illustrates the point here.
Producing the body of a car requires a “stamp” to shape the metal for the car body. These stamps are large and take many months to create. In the 1980’s at General Motors a new car would be designed and when the design was finished work on a “stamp” would start. This created a delay of a year or more in producing the new car.
At Toyota the general size parameters of a new car would be agreed early on in the process. The stamp team would start work on the new stamp before the design was finished. Only as the design neared completion would the stamp team complete the stamp. As a result Toyota did not have the same delay.
The Toyota guys started off being generally right and narrowed in on the exact dimensions over time. At GM the desire to be always right held work back.
Immo Huneke mailed to point out that the Sloan piece doesn’t discuss how you measure alignment. I’m not sure how I would go about measuring alignment myself, after all what is alignment? Can it be measured objectively?
There is a point here, and I myself am a guilty of making a jump from alignment to requirements. I’ve also used the phrases “doing the right thing” and “doing things right” quite loosely.
The other point which we could argue about is “IT”. The Sloan piece talks about IT. There is no information on whether this relates to hardware, software, IT support or software development.
Despite these caveats I think the central message still holds: getting effective is more beneficial than getting.
Still, I want to make it clear I think knowing what you are doing is essential. And in the long term requirements aligned to the business are very important - see the blog entry that comes after this one.
Its all a question of context.
If you want to fix a broken IT organization I claim, and I believe the Alignment Trap supports this claim, it is best to start by making the organization effective then determining what needs doing.
This context implies that there is an organization, and it is doing “stuff”. It knows some of what needs doing. You might be able to remove some “stuff” (or add more) but basically it is not short of work to do.
I believe that in this situation discussions over what to do (alignment, requirements) are not effective because the history of failed deliveries means there is no trust and it means the business side tries to game the system by asking for more than they need because they believe It will always under deliver.
This context also implies that the IT group is, in general, supporting the business. If your company sells Payroll software and your developers are currently writing a competitor to Grand Theft Auto then I think you would be right in question requirements on day one. But in general, if you sell Payroll software it is likely that your development group are working on Payroll software.
In other words: you are better off being generally right than precisely wrong.
Before you can tackle the requirements problem (and alignment) you need to build a delivery machine that can tackle it.
The Machine that Changed the World contains an example I think illustrates the point here.
Producing the body of a car requires a “stamp” to shape the metal for the car body. These stamps are large and take many months to create. In the 1980’s at General Motors a new car would be designed and when the design was finished work on a “stamp” would start. This created a delay of a year or more in producing the new car.
At Toyota the general size parameters of a new car would be agreed early on in the process. The stamp team would start work on the new stamp before the design was finished. Only as the design neared completion would the stamp team complete the stamp. As a result Toyota did not have the same delay.
The Toyota guys started off being generally right and narrowed in on the exact dimensions over time. At GM the desire to be always right held work back.
Thursday, February 19, 2009
Requirements come second
A provocative piece from me in this month’s Agile Journal - Requirements Come Second.
If you’ve not checked out the Agile Journal recently you might want to have a look, they’ve given the site a make-over and have added blogs, forums and all that community stuff.
If you’ve not checked out the Agile Journal recently you might want to have a look, they’ve given the site a make-over and have added blogs, forums and all that community stuff.
Thursday, February 12, 2009
Agile and Lean - the same but different
At the end of last year I was lucky enough to hear Dan Jones give a keynote talk at XP Day 2008. Dan is one of the authors of The Machine that Changed the World and as such is one of the fathers of Lean. Or at least father of the term Lean, I’m sure Dan would point out that he (and his co-authors) didn’t so much invent Lean as reveal it to the world.
Dan opened his talk by addressing the difference between Agile and Lean directly. And in his view there is no difference. Perhaps someone else who was in the room can help me with the exact quotes but this is how I remember him putting it:
• When Dan, Jim Womack and Daniel Roos wrote did the research that resulted in The Machine that Changed the World they had to think of a term to describe what they found. Toyota Production System was too Toyota specific. They eventually came up with Lean. In the process they considered the name Agile but rejected it - “because it wouldn’t sell” he quibbed.
• Later (someone who’s name he gave but I don’t remember) decided there should be an “American version of Lean” and decided to use the term Agile. As far as Dan can tell it is this source that the original Agile software people (those who wrote the Agile manifesto I guess) picked up on.
• As far as Dan is concerned he doesn’t care which term we use, its all the same.
• (And he’s glad to see IT folk taking an interest because traditionally the Lean manufacturing movement has found IT a block to Lean adoption.)
I’m glad to hear Dan say this, certainly my flavour of Agile has long been influenced by Lean - even before the Poppendieck’s excellent Lean Software Development. I now feel more able than ever to talk about them as one.
That said I think there is a subtle distinction, its actually a distinction that can be helpful on some context. Its also a distinction which helps explain why Agile is not XP even though XP is Agile and why there is more to Agile than Scrum.
It helps to look at this diagram - if you’ve seen it before you’ll notice I’ve extended it recently:
At the top there are specific Agile methods like XP, Scrum, Crystal, etc. These are quite prescriptive in their ways - some more than others. Each is an Agile method but none are Agile.
Agile is a toolbox, these methods have chosen elements from the toolbox. Agile is more general, Agile is more of a value system, a philosophy.
Agile itself is Lean but it is more prescriptive than Lean. Few Agile teams would not do Test Driven Development for example. So while Agile is more general than XP or Scrum it is less general than Lean.
Lean itself is more philosophical still and contains fewer specific practices. You have to apply Lean thinking in your own context. Lean is a journey.
Still further down we find Organizational Learning. All these methods are based on continual learning - systems thinking should probably be included in here. But organizational learning is almost entirely values, philosophy and academic research, it is almost devoid of specific practices. (I could get into the Knowledge Management debate here but not today.)
Recently I’ve added RUP and Kanban to this diagram.
RUP shares a lot in common with Agile methods but it comes from a very different place. It comes from traditional software engineering, it comes from the unification of object orientation and it comes from the commercial world. RUP can (I am told) be made to look and feel like Agile but this doesn’t change where it comes from.
Then there is Kanban. Kanban is the new kid on the Agile block but it is derived more direct from Lean thinking. So for me it doesn’t inhabit that top apex of the pyramid, it draws on Agile and Lean. And this is where Dan Jones point is very appropriate: it doesn’t matter, at this level Agile and Lean are merging. So if you want to argue that it should be up there with XP and Scrum I don’t mind.
Dan opened his talk by addressing the difference between Agile and Lean directly. And in his view there is no difference. Perhaps someone else who was in the room can help me with the exact quotes but this is how I remember him putting it:
• When Dan, Jim Womack and Daniel Roos wrote did the research that resulted in The Machine that Changed the World they had to think of a term to describe what they found. Toyota Production System was too Toyota specific. They eventually came up with Lean. In the process they considered the name Agile but rejected it - “because it wouldn’t sell” he quibbed.
• Later (someone who’s name he gave but I don’t remember) decided there should be an “American version of Lean” and decided to use the term Agile. As far as Dan can tell it is this source that the original Agile software people (those who wrote the Agile manifesto I guess) picked up on.
• As far as Dan is concerned he doesn’t care which term we use, its all the same.
• (And he’s glad to see IT folk taking an interest because traditionally the Lean manufacturing movement has found IT a block to Lean adoption.)
I’m glad to hear Dan say this, certainly my flavour of Agile has long been influenced by Lean - even before the Poppendieck’s excellent Lean Software Development. I now feel more able than ever to talk about them as one.
That said I think there is a subtle distinction, its actually a distinction that can be helpful on some context. Its also a distinction which helps explain why Agile is not XP even though XP is Agile and why there is more to Agile than Scrum.
It helps to look at this diagram - if you’ve seen it before you’ll notice I’ve extended it recently:
At the top there are specific Agile methods like XP, Scrum, Crystal, etc. These are quite prescriptive in their ways - some more than others. Each is an Agile method but none are Agile.
Agile is a toolbox, these methods have chosen elements from the toolbox. Agile is more general, Agile is more of a value system, a philosophy.
Agile itself is Lean but it is more prescriptive than Lean. Few Agile teams would not do Test Driven Development for example. So while Agile is more general than XP or Scrum it is less general than Lean.
Lean itself is more philosophical still and contains fewer specific practices. You have to apply Lean thinking in your own context. Lean is a journey.
Still further down we find Organizational Learning. All these methods are based on continual learning - systems thinking should probably be included in here. But organizational learning is almost entirely values, philosophy and academic research, it is almost devoid of specific practices. (I could get into the Knowledge Management debate here but not today.)
Recently I’ve added RUP and Kanban to this diagram.
RUP shares a lot in common with Agile methods but it comes from a very different place. It comes from traditional software engineering, it comes from the unification of object orientation and it comes from the commercial world. RUP can (I am told) be made to look and feel like Agile but this doesn’t change where it comes from.
Then there is Kanban. Kanban is the new kid on the Agile block but it is derived more direct from Lean thinking. So for me it doesn’t inhabit that top apex of the pyramid, it draws on Agile and Lean. And this is where Dan Jones point is very appropriate: it doesn’t matter, at this level Agile and Lean are merging. So if you want to argue that it should be up there with XP and Scrum I don’t mind.
Wednesday, February 04, 2009
BCS Bristol Spring school
Bristol BCS are holding a series of sessions entitled “Spring School - An Introduction to Agile Development”. I will be presenting the fourth and final session (23 March) on the “Future of Agile”.
I’ve not written it yet but it will probably include plenty about Lean and Kanban, the Change Problem and the importance of Business Analysts and Product Managers.
Fellow ACCU member Giovanni Asproni is doing the session on 16 March on Agile testing and TDD.
If your in the Bristol and Bath area I’m sure it will be worth the £30-£50 charge.
I’ve not written it yet but it will probably include plenty about Lean and Kanban, the Change Problem and the importance of Business Analysts and Product Managers.
Fellow ACCU member Giovanni Asproni is doing the session on 16 March on Agile testing and TDD.
If your in the Bristol and Bath area I’m sure it will be worth the £30-£50 charge.
Taking Japan by storm (and not taking Kingston)
After slogging my way into London’s through the worst snow in 18 years on Monday and Tuesday this week to deliver a Agile Project Management course, I was a little relieved when Kingston & Croydon BCS cancelled last nights presentation - because of the weather. Still I was a sorry to miss the evening.
If you were one of those who planned to come along all I can say is Sorry, I believe it will be rescheduled for a later date.
But, when I opened my e-mail I had a very nice surprise...
My book, Changing Software Development: Learning to become Agile is going to be translated into Japanese. I can’t wait to see it. This was quite unexpected and I think goes to show how well the book has been received.
Now if any Japanese readers would like me to do a talk in Japan I’m more than happy to oblige, although I will have to ask for expenses.
If you were one of those who planned to come along all I can say is Sorry, I believe it will be rescheduled for a later date.
But, when I opened my e-mail I had a very nice surprise...
My book, Changing Software Development: Learning to become Agile is going to be translated into Japanese. I can’t wait to see it. This was quite unexpected and I think goes to show how well the book has been received.
Now if any Japanese readers would like me to do a talk in Japan I’m more than happy to oblige, although I will have to ask for expenses.
Subscribe to:
Posts (Atom)