At this year’s EuroPLoP conference I presented two more business patterns for workshop review. There are:
I have now updated the paper with the workshop comments and the patterns can now be downloaded from my website. The other patterns in the Business Patterns series can also be downloaded.
These are the final two patterns for my forthcoming book Business Patterns for Software Developers. The text of the book is just about finished and it will be going to the publisher soon. It should be available early in the new year.
Wednesday, August 31, 2011
Wednesday, August 17, 2011
Is "Faster Better Cheaper" axiomatic in Agile?
“Faster Better Cheaper” - a cry heard often from management types!
Or at least engineers think thats the sort of thing managers say. Personally I don’t think I’ve ever actually heard a manager say it but I have heard engineers say managers want it “Faster Better Cheaper” with scorn in their voice.
The idea that you could have it (whatever it is) “Faster Better Cheaper” seems to have gained popularity when Daniel Goldin was the head of NASA. As many engineers, including myself, are quick to point out the original quote was “Faster Better Cheaper, choose two”. I say “original quote” but I have no idea who said it first, WikiQuote doesn’t help, and Google doesn’t shed much clear light. (Anyone out there know?)
Whatever, last week, I heard another engineer-type say that he believed management wanted “Agile” because it was “Faster Better Cheaper” and, not for the first time, it got me thinking. Is Agile Faster Better Cheaper?
My knee-jerk reaction is “No!” but the more I think about it the more I think it might actually be so.
Firstly, Faster than What? Better than What? and Cheaper than What?
Presumably “Faster than traditional Waterfall development”. Or at least, what-ever-it-is-you-are-doing-now, which is probably to some degree based on waterfall.
In the short run, when a team are first changing the way they work thy are quite likely to go slower than they would do otherwise simply because they are learning something new and not using a set of practiced reflexes.
Agile most definitely promises to deliver something sooner - if you want it, plenty of business folk seem unhappy with getting things too soon or too often. But Agile will NOT deliver the whole thing Faster, it can only promise to deliver a part sooner.
The logic of Agile recognises “You will change your mind when you get something”, meaning, if the business/customer sees part of the final thing they will add, remove and change the thing they originally asked for. In some cases, and I have seen this happen, they remove work. Lots of work.
Thus, the whole might come faster, but the whole is smaller than the thing you thought it was.
So, Faster - in the short run no, in the medium run you should get something sooner, and in the long run, Yes, it will look like Faster.
What about Better? - how are we to define better: better quality (fewer bugs), better suited to need, more fully filling the initial request.
Yes: Agile promises better quality (fewer bugs). Indeed if you don’t improve quality and remove bugs you are going to have problems doing Agile. If you do improve quality - fewer bugs - then the evidence suggests you will have shorter schedules, i.e. you will go faster.
Better suited to need: again, Yes. If those who made the requests are seeing something sooner, and having their views on functionality taken into consideration then one would expect the final product to be better suited to need.
More fully filling initial request: No, complying with “better suited to need” means we are not aiming to build the thing we first thought of but rather build the thing we need to satisfy the need.
So, if your criteria for success, for better, means complying with a requirements document that was frozen at some arbitrary point in time then No, Agile falls at this hurdle.
Cheaper: again there is a short run and a long run dimension here.
In the short run the development team need training, coaching and time to practice. Of course you could skip the training and coaching (plenty of teams do) but that means they will need more time to practice (make more mistakes, go down a few dead ends, etc.) Practice time costs.
In the short run I don’t think Agile is cheaper. Indeed, in the short run, if you are doing it properly you will see expenses rise as you have the likes of me come to train and coach your teams. (If you are not doing it properly you probably won’t see your costs rise but they will all the same as teams (slowly) learn by themselves.)
In the longer run, when you’ve finished the training, coaching and when the team are proficient then those extra costs will be gone and you should be cost neutral as least. But if you are not writing, finding and fixing so many bugs, and if parts of the requirements are being left undone - while satisfying your business customer - then costs should fall because you are expending less effort and doing less work.
Even if you are not doing less work costs should fall because on a software project costs are dominated by the number of people you have multiplied by the time you have them. If you are going faster then time is reduced and costs come down.
Therefore the project will be cheaper.
Summary: Better (fewer bugs) provides for Faster (delivery) which results in Cheaper (software).
Agile is “Faster Better Cheaper”, QED.
When you put it like that “Faster Better Cheaper” looks axiomatic over the long run.
The engineer in me hates this conclusion, I’m not prepared to accept it but if I follow the logic it is true. (The engineer in me would love someone to find a flaw in my logic so please go for it! Shoot me down!)
Note the three assumptions in this logic:
Well, if this is true then its not so much that Agile is “Faster Better Cheaper” but that the model we are comparing it with - the traditional (“waterfall”) model - is so utterly broken.
Waterfall breaks Faster Better Cheaper everywhere:
In which case the, returning to the original question: “Is Agile Faster Better Cheaper?” the answer is really “Depends on what you are comparing it to.”
Or at least engineers think thats the sort of thing managers say. Personally I don’t think I’ve ever actually heard a manager say it but I have heard engineers say managers want it “Faster Better Cheaper” with scorn in their voice.
The idea that you could have it (whatever it is) “Faster Better Cheaper” seems to have gained popularity when Daniel Goldin was the head of NASA. As many engineers, including myself, are quick to point out the original quote was “Faster Better Cheaper, choose two”. I say “original quote” but I have no idea who said it first, WikiQuote doesn’t help, and Google doesn’t shed much clear light. (Anyone out there know?)
Whatever, last week, I heard another engineer-type say that he believed management wanted “Agile” because it was “Faster Better Cheaper” and, not for the first time, it got me thinking. Is Agile Faster Better Cheaper?
My knee-jerk reaction is “No!” but the more I think about it the more I think it might actually be so.
Firstly, Faster than What? Better than What? and Cheaper than What?
Presumably “Faster than traditional Waterfall development”. Or at least, what-ever-it-is-you-are-doing-now, which is probably to some degree based on waterfall.
In the short run, when a team are first changing the way they work thy are quite likely to go slower than they would do otherwise simply because they are learning something new and not using a set of practiced reflexes.
Agile most definitely promises to deliver something sooner - if you want it, plenty of business folk seem unhappy with getting things too soon or too often. But Agile will NOT deliver the whole thing Faster, it can only promise to deliver a part sooner.
The logic of Agile recognises “You will change your mind when you get something”, meaning, if the business/customer sees part of the final thing they will add, remove and change the thing they originally asked for. In some cases, and I have seen this happen, they remove work. Lots of work.
Thus, the whole might come faster, but the whole is smaller than the thing you thought it was.
So, Faster - in the short run no, in the medium run you should get something sooner, and in the long run, Yes, it will look like Faster.
What about Better? - how are we to define better: better quality (fewer bugs), better suited to need, more fully filling the initial request.
Yes: Agile promises better quality (fewer bugs). Indeed if you don’t improve quality and remove bugs you are going to have problems doing Agile. If you do improve quality - fewer bugs - then the evidence suggests you will have shorter schedules, i.e. you will go faster.
Better suited to need: again, Yes. If those who made the requests are seeing something sooner, and having their views on functionality taken into consideration then one would expect the final product to be better suited to need.
More fully filling initial request: No, complying with “better suited to need” means we are not aiming to build the thing we first thought of but rather build the thing we need to satisfy the need.
So, if your criteria for success, for better, means complying with a requirements document that was frozen at some arbitrary point in time then No, Agile falls at this hurdle.
Cheaper: again there is a short run and a long run dimension here.
In the short run the development team need training, coaching and time to practice. Of course you could skip the training and coaching (plenty of teams do) but that means they will need more time to practice (make more mistakes, go down a few dead ends, etc.) Practice time costs.
In the short run I don’t think Agile is cheaper. Indeed, in the short run, if you are doing it properly you will see expenses rise as you have the likes of me come to train and coach your teams. (If you are not doing it properly you probably won’t see your costs rise but they will all the same as teams (slowly) learn by themselves.)
In the longer run, when you’ve finished the training, coaching and when the team are proficient then those extra costs will be gone and you should be cost neutral as least. But if you are not writing, finding and fixing so many bugs, and if parts of the requirements are being left undone - while satisfying your business customer - then costs should fall because you are expending less effort and doing less work.
Even if you are not doing less work costs should fall because on a software project costs are dominated by the number of people you have multiplied by the time you have them. If you are going faster then time is reduced and costs come down.
Therefore the project will be cheaper.
Summary: Better (fewer bugs) provides for Faster (delivery) which results in Cheaper (software).
Agile is “Faster Better Cheaper”, QED.
When you put it like that “Faster Better Cheaper” looks axiomatic over the long run.
The engineer in me hates this conclusion, I’m not prepared to accept it but if I follow the logic it is true. (The engineer in me would love someone to find a flaw in my logic so please go for it! Shoot me down!)
Note the three assumptions in this logic:
- The reference point is the “Waterfall” model of development
- Your definition of better considers a low-bug count important and emphasis fitness for purpose over conformance with initial requirements
- Your are prepared to spend in the short run for quality (defect prevention) to save in the long run
Well, if this is true then its not so much that Agile is “Faster Better Cheaper” but that the model we are comparing it with - the traditional (“waterfall”) model - is so utterly broken.
Waterfall breaks Faster Better Cheaper everywhere:
- Waterfall leads to large batch sizes and economies of scale thinking: in software development there are dis-economies of scale so large batch sizes makes everything slower
- Waterfall project managers believe quality (bugs) can be traded off against time but actually the opposite is true. Reducing quality reduces “better” and slows a work down. The same project managers are trained to resist requirements change so almost guaranteeing business customers will be dissatisfied with what is delivered and consider it “worse.”
- Slowing software development down makes it more expensive, remember: Cost = People x Time
In which case the, returning to the original question: “Is Agile Faster Better Cheaper?” the answer is really “Depends on what you are comparing it to.”
Monday, August 15, 2011
Dialogue sheet observations
Regular readers will know I’ve been pushing Dialogue Sheets as a new retrospective technique. I have observed a number of dialogue sheet sessions - both the retrospective sheets I’ve made public plus some other sheets I’m still testing. Someone from Motorola Mobility recently asked for my observations on using dialogue sheets and I thought it would be a good opportunity to make my observations public.
As a facilitator I find there is very little for me to do, the sheets are designed to be used without a facilitator. As an observer I have been asked to intervene occasionally. Usually I try to say nothing, if the group is willing they can usually work out what to do themselves. When people in the group are either suspicious (something new) or unsure about the retrospective they usually need a few words of explanation.
The most common sticking point is Kerth's Prime Directive. Some people seem unwilling to accept it for the duration of the retrospective. They start making comments about how they don't think people did not do their best.
I don't like stepping in when this happens because I think the group needs to come to an understanding themselves. This eventually happens even if it is something like "well we kind of ignore that" but it can take a while.
The second thing I have noticed is time: It is not how many questions there are on the sheet that determine how long the retrospective will take but the number of people involved. When there are 4 people it is quite fast, when it is 8 it takes longer. So far I haven't found a good rule of thumb for determining just how long the sheet will take.
Sometimes I intervene to just remind people of the time and move them along.
The other bit which can be difficult is the end questions. They are intended to bring the group to set of conclusions which they can act on. Still sometimes the items are "Better communication" which while right isn't very specific or actionable.
There have been plenty of dialogue sheets downloads now and I occasionally e-mail downloaders for feedback. Of those those who have used the sheets “energized” is the most common comment.
I’m planning to revamp the three existing sheets and add one for project start-up. I’ve also had a request to translate them into other languages - specifically German. Once the revamp is complete I’ll start on some translations. I’m also thinking of creating a mailing list for discussion dialogue sheets.
If you haven’t looked at the dialogue sheets they are free for download, and you can buy pre-printed dialogue sheets.
As a facilitator I find there is very little for me to do, the sheets are designed to be used without a facilitator. As an observer I have been asked to intervene occasionally. Usually I try to say nothing, if the group is willing they can usually work out what to do themselves. When people in the group are either suspicious (something new) or unsure about the retrospective they usually need a few words of explanation.
The most common sticking point is Kerth's Prime Directive. Some people seem unwilling to accept it for the duration of the retrospective. They start making comments about how they don't think people did not do their best.
I don't like stepping in when this happens because I think the group needs to come to an understanding themselves. This eventually happens even if it is something like "well we kind of ignore that" but it can take a while.
The second thing I have noticed is time: It is not how many questions there are on the sheet that determine how long the retrospective will take but the number of people involved. When there are 4 people it is quite fast, when it is 8 it takes longer. So far I haven't found a good rule of thumb for determining just how long the sheet will take.
Sometimes I intervene to just remind people of the time and move them along.
The other bit which can be difficult is the end questions. They are intended to bring the group to set of conclusions which they can act on. Still sometimes the items are "Better communication" which while right isn't very specific or actionable.
There have been plenty of dialogue sheets downloads now and I occasionally e-mail downloaders for feedback. Of those those who have used the sheets “energized” is the most common comment.
I’m planning to revamp the three existing sheets and add one for project start-up. I’ve also had a request to translate them into other languages - specifically German. Once the revamp is complete I’ll start on some translations. I’m also thinking of creating a mailing list for discussion dialogue sheets.
If you haven’t looked at the dialogue sheets they are free for download, and you can buy pre-printed dialogue sheets.
Wednesday, August 10, 2011
Skills Matter talk postponed
Apologies to anyone who was planning on attending my “Objective Agility: What does it take to be an Agile company?” talk at Skills Matter tonight. The presentation has been postponed until 1 September.
Paul from Skills Matter and myself agonised this morning about postponing the talk. We both wanted to go ahead but with recent events in London we thought it best to postponed until things were a little quieter.
Quite a few people were booked for the event, I hope you can all make it for September, and those of you who couldn’t make it, we’ll you can come too!
Paul from Skills Matter and myself agonised this morning about postponing the talk. We both wanted to go ahead but with recent events in London we thought it best to postponed until things were a little quieter.
Quite a few people were booked for the event, I hope you can all make it for September, and those of you who couldn’t make it, we’ll you can come too!
Thursday, July 21, 2011
Xanpan
For a little while now I’ve been quietly talking about my new Agile method. The clue is in the name: Xanpan - pronounced “Zanpan”. Most obviously Kanban and XP (Extreme Programming), its a fusion.
Its not so much than Xanpan has any new radical ideas in it, its more than it is a synthesis of ideas from several Agile methods plus my own. It contains a fair chunk of what I would call “product management ideas”.
Xanpan is a little more than that, in takes from Scrum as well as XP, and from Lean as well as Kanban, plus there are other ideas in too.
I’ll write more about Xanpan in future but for now here are the essential features, and where it steals them from. A little rough and ready but I wanted to share this and get some feedback.
From Extreme Programming: The technical practices
From Lean: Culture of improvement, Kaizen and Learning
Xanpan broadly follows the 10 Step Requirements Model but recognises this model is not broad enough to cope with all scenarios. No model ever will be.
On requirements Xanpan believes:
Its not so much than Xanpan has any new radical ideas in it, its more than it is a synthesis of ideas from several Agile methods plus my own. It contains a fair chunk of what I would call “product management ideas”.
Xanpan is a little more than that, in takes from Scrum as well as XP, and from Lean as well as Kanban, plus there are other ideas in too.
I’ll write more about Xanpan in future but for now here are the essential features, and where it steals them from. A little rough and ready but I wanted to share this and get some feedback.
From Extreme Programming: The technical practices
- Test Driven Development plus Automated Test Driven Development. If you want to adopt BDD then go right ahead
- Lightweight, near time code review, better still pair programming if developers are happy with it
- Continuous integration: with tests and static analysis tools as part of the build system
- Rough up front design: no up front design is wrong, but so too is design that takes weeks or months. If you need a design session it is probably part of the planning meeting with all the developers around the whiteboard for an hour or maybe two
- Refactoring to keep the code soft - its software, emphasis the soft
- Shared code ownership
- Minimise documentation, accept tacit knowledge as part of the development process.
- Velocity measurement and “yesterday’s weather” approach to deciding what to put in the next iteration
- Have a visual board to track progress
- Divide the board into columns which represent you process - probably more than just: Todo, In Progress and Done. Columns are usually come in pairs: a queue then a action which draws from the queue. Work to improve the flow and change the columns as you go
- Work in progress limits - usually on action queues, occasionally queues may be limited too
- Improvement comes from improving flow
- Minimise the time spent estimating, if possible abolish estimates and use statistically derived approximations, i.e. averages
- Cumulative flow charts
- Use iterations to establish a regular rhythm to the team
- Iterations start with closing the previous one: review work done, update statistics, conduct a retrospective. This is followed by a planning meeting: work is presented, estimated (if need be) and scheduled
- Stand-up meetings where appropriate
- Burn-down/up charts where appropriate
- User Stories are the default requirements capture tool although Use Cases, Planguage and more informal approaches are acceptable too. If using User Stories then do not use more than three levels of division
From Lean: Culture of improvement, Kaizen and Learning
- Retrospectives are not enough: Leaders should undertake personal reflection
- Rehearsal: Teams should undertake formal and informal training together; deliberate practice as Kevlin Henney and Jon Jagger like to say
- Team Coach: Each team should have a coach, different coaches may focus on different things so there may be more than one coach. Except in large teams (over 12 people) and in the early days of adoption the coach is usually not full time on a team. The team is there to help the team adopt practices, learn and reflect.
- Individuals have multiple skills and should all muck in, but there are specialists in some areas.
- Kanban’s stop the line quality control: sometimes it is appropriate, sometimes it isn’t. Keep regular retrospectives, part of your rhythm
- Scrum Master: teams will have a Manager or Project Managers, or may be lead by an non-commissioned manager, e.g. Team Leader, Technical Lead, or similar
- Anti-manager ethos: Management is part of the solution, not the problem. Unfortunately the quality of IT and development managers is general is poor; good management can be really powerful
- Matrix management
- Distributed teams, particularly teams in different timezones
Xanpan broadly follows the 10 Step Requirements Model but recognises this model is not broad enough to cope with all scenarios. No model ever will be.
On requirements Xanpan believes:
- There should be a dedicated requirements role staffed by a trained/experienced Product Manager or Business Analyst; both is probably overkill
- There should be a clear business case setting out why a team or project exists. The business case is not a shopping list of features, nor is it a large document but it should allow someone to decide the work is finished
- Customers are not the only stakeholders. Each stakeholder will make their own judgement about the success or failure of work therefore each stakeholder needs to be considered
- Evaluating the benefits of completed work is as important as deciding what work should be undertaken next. There is no point to developing more software if the software that has been delivered so far is not valuable.
- If the team has an architect they should also code; the architects role is to help create a shared understanding of the architecture and educate less experienced team members.
- Teams should be kept together and not broken up when work finishes or changes; bring the work to the team, not the team to the work
- Block and impediments should be tracked to see which ones occur repeatedly. If a team cannot resolve an impediment themselves then the leader or manager steps in, in effect it is the start of an escalation
- There are three version of Xanpan: Evolutionary, Incremental and Iterative - these build on the ideas in my Agile Spectrum article. Iterative is the most compatible with existing corporate culture and project management methods - salami slice requirements; Evolutionary is the extreme - goal directed working
- Xanpan adopts the three planning layers described in my Three Plans for Agile article and encourages Goal Driven Projects.
- Xanpan believe management has an important role to play in the development process (but a lot of development managers are not up to the job)
- Whenever possible put bug-fixing in a separate stream of work; but staff it with the same people, rotate people
- Keep teams together: bring the work to the team, rather than the team to the work
- Quality is free: automate as much testing as you can, although you probably can’t automate 100%
- Prioritisation is vital and omnipresent: there is no such thing as too little time, just mis-understood priorities
- People are key to good software development but there aren’t enough good people to go around, so we need to improve the people we have and help them work more effectively. And we need to grow more good people
- Agile is not about what you do but what you achieve; measure outputs not inputs
- You can always improve
- Customer/End user involvement is key to building a successful system.
- Xanpan is a pick-n-mix of bits of various development methods and adopters are encouraged to continue the approach
- No process or Methodology can cope with all situations, and if it could it would be too big to write down or learn, there adaptation is always required and people need to think
- The process should be changing, if you are doing Xanpan the same in six months as you do today you aren’t doing Xanpan
Monday, July 18, 2011
Cornwall nominated fror Agile awards
I’ve tweeted and blogged about the Cornwall Agile Programme before - something I like to call the ‘Cornish Software Mines’. So it is with great pride that I’m please to announce that the programme has been nominated for an award.
The Agile awards are presented as part of the Agile Business Conference and ‘Agile Cornwall’ has been nominated under the ‘Best use of Agile in the Public Sector’ - officially the programme is part of the ‘Convergence Programme for Cornwall & Isles of Scilly’ so the nomination is under this name.
This autumn I’ll be delivering a couple of case studies of the programme and the companies which have benefitted. The first of these will be, fittingly, at the Agile on the Beach conference in Falmouth. This isn’t a coincidence, the conference is a spin-off from the programme. This will be the most comprehensive case study as it will include presentations from several of the companies who have benefitted from the programme.
A few weeks later a cut down version of the case study will be appearing at the Agile Business Conference. If you miss it there I’m sure it will have another outing before long.
In the meantime, I’ve posted a case study of the work I’ve done with Sullivan Cuff Software on the Software Strategy website.
The Agile awards are presented as part of the Agile Business Conference and ‘Agile Cornwall’ has been nominated under the ‘Best use of Agile in the Public Sector’ - officially the programme is part of the ‘Convergence Programme for Cornwall & Isles of Scilly’ so the nomination is under this name.
This autumn I’ll be delivering a couple of case studies of the programme and the companies which have benefitted. The first of these will be, fittingly, at the Agile on the Beach conference in Falmouth. This isn’t a coincidence, the conference is a spin-off from the programme. This will be the most comprehensive case study as it will include presentations from several of the companies who have benefitted from the programme.
A few weeks later a cut down version of the case study will be appearing at the Agile Business Conference. If you miss it there I’m sure it will have another outing before long.
In the meantime, I’ve posted a case study of the work I’ve done with Sullivan Cuff Software on the Software Strategy website.
Tuesday, July 12, 2011
Retrospectives - common or not, a small survey
I’m still experimenting with Dialogue Sheets for Retrospectives (the download page, and my earlier blog entry) and so are other people. Of the feedback I’ve had so far it has been overwhelmingly positive. Perhaps people who aren’t positive don’t bother trying them.
The sheets are free to download but I do request people register. My objective here is to obtain more feedback. Periodically, like today, I get the e-mail addresses of those who have downloaded and I send a polite note saying “Any feedback?”.
In registering I ask a couple of other questions. One of these questions is: “How often do you hold a retrospective?”. I thought it would be interesting to share the results of this data so far:
How often do you do a retrospective?
This is good to see, about 54% of people are holding retrospectives with the frequency you would expect from a Scrum, XP or other type of Agile team. But sadly the second biggest group is never holding retrospectives, 21% of people. And 10% are holding them rarely or very occasionally.
Now think again, this data is not representative. 15% of people are not retrospective facilitators (e.g. Scrum Masters, Agile Coach, etc.). The people who download these sheets have an interest in retrospectives, this group is self-selecting.
The implications of this are that an awful lot less than 54% of people are doing retrospectives with anything near the frequency one should expect from an Agile team. Given that retrospectives are the primary means of learning in an Agile team I suspect that means that an awful lot of teams are are not really practicing Agile as described in the books.
I have long suspected that retrospectives are actually one of the more advanced Agile techniques and are far from common. I think this data supports that argument, but at the same time I think they are more common than I tended to think, maybe thats the progress of 3 years.
The sheets are free to download but I do request people register. My objective here is to obtain more feedback. Periodically, like today, I get the e-mail addresses of those who have downloaded and I send a polite note saying “Any feedback?”.
In registering I ask a couple of other questions. One of these questions is: “How often do you hold a retrospective?”. I thought it would be interesting to share the results of this data so far:
How often do you do a retrospective?
| 38% | Every two weeks or more often |
| 21% | Never |
| 16% | At least once a month |
| 15% | I am a retrospective facilitator and so hold many |
| 6% | Rarely |
| 3% | At least once a quarter |
| 1% | About every six months |
This is good to see, about 54% of people are holding retrospectives with the frequency you would expect from a Scrum, XP or other type of Agile team. But sadly the second biggest group is never holding retrospectives, 21% of people. And 10% are holding them rarely or very occasionally.
Now think again, this data is not representative. 15% of people are not retrospective facilitators (e.g. Scrum Masters, Agile Coach, etc.). The people who download these sheets have an interest in retrospectives, this group is self-selecting.
The implications of this are that an awful lot less than 54% of people are doing retrospectives with anything near the frequency one should expect from an Agile team. Given that retrospectives are the primary means of learning in an Agile team I suspect that means that an awful lot of teams are are not really practicing Agile as described in the books.
I have long suspected that retrospectives are actually one of the more advanced Agile techniques and are far from common. I think this data supports that argument, but at the same time I think they are more common than I tended to think, maybe thats the progress of 3 years.
Tuesday, July 05, 2011
Abandon Hope all ye who enter Agile
Earlier this week I had a conversation with Benjamin Mitchell about an entrepreneur he’d done some work with. Benjamin had been suggesting a lean start-up approach to the business in which the entrepreneur worked to validate his business idea early and gradually build the product one validated step at a time.
Things didn’t go well, the understanding I came to from Benjamin’s story - although his might be different - was that the entrepreneur was very attached his business idea. It was pretty well formed and he could imagine it working. In popular culture entrepreneurs are often seen as iconoclasts who battle doubters, naysayers and banks to bring their ideas to life against the odds. Benjamin was just another doubter.
Now I tend to agree with Benjamin’s approach because it is very difficult to tell if a new business idea, indeed any project, will work until you try to build it. But building it is expensive so I advocate a “Try, fail fast, fail cheap, move on to the next thing” approach - I don’t think this is that different to lean start-up thinking but as I’ve not read the lean start-up book I don’t really know.
I don’t just advocate this approach for new businesses, I advise it for established businesses embarking on a project. My logic is: you can’t be sure a product will work in the market till you try it, nor can you plan a project until you know how fast (velocity) the team will work. In fact, until the team trys to work together and build something you don’t have any data on which to project plans. Making estimates without data is little better than guessing.
Thus, I advise a Mao like approach to corporate projects, “let a thousand flowers bloom” - start multiple small projects, small teams and use portfolio review to remove those that don’t seem promising and reallocate resources to those which do seem promising - or launch more experiments.
Unfortunately, like the entrepreneur, people get very attached to the idea of a project so it gets momentum. Big corporations respond by only starting projects in which they have a high degree of confidence. That means they do a lot of pre-project work - planning, designing, etc., this in turn makes it difficult and expensive to start projects, which in turn means that any project that does get started already has momentum. And it means that once underway the project finds it difficult to cope with change.
It seems to me that successful projects in corporations are often the result of one person who wants the project to happen and does what is necessary, not unlike entrepreneurs. In both cases a strong willed, capable, person makes something happen. That person needs to be motivated, they need hope, they need ambition and hope. Such people are going to kind who ignore naysayers and doubters.
The Agile approach - try, gather data, evaluate, or my “fail fast, fail cheap, retry” approach are not going to go down well with the kind of pig-headed, obstinate, passionate, do-anything-it-takes, approach which has made many successful projects a success. Quite the opposite.
Interestingly Benjamin had another example of a company which does take the “fail fast, fail cheap, try again” approach and was staffed by passionate, hopeful, people. From what he told me these people were passionate about the process as much as they were passionate about the products they tried. They could accept regular failure of good ideas because they saw the process working, and perhaps more importantly, could transfer their hope to the next idea. There was always a next idea.
What I am saying is: Don’t rely on hope to get your projects done, use data - be empirical not emptional.
Finally, I should say, that while I talked much of this over with Benjamin he would be the first to point out unvalidated steps in my thinking, and ungrounded assumptions I’ve made. So maybe this entire entry is really a hypotheses. The hypothesis is:
“The trial and error approach of Agile is unlikely to please those who get passionate about an idea and want to move heaven and earth to make it happen.”
I’ll let you, dear reader, decide for yourself on that hypotheses. If you have any evidence - to support or disprove - my hypothesis please add a comment below.
Things didn’t go well, the understanding I came to from Benjamin’s story - although his might be different - was that the entrepreneur was very attached his business idea. It was pretty well formed and he could imagine it working. In popular culture entrepreneurs are often seen as iconoclasts who battle doubters, naysayers and banks to bring their ideas to life against the odds. Benjamin was just another doubter.
Now I tend to agree with Benjamin’s approach because it is very difficult to tell if a new business idea, indeed any project, will work until you try to build it. But building it is expensive so I advocate a “Try, fail fast, fail cheap, move on to the next thing” approach - I don’t think this is that different to lean start-up thinking but as I’ve not read the lean start-up book I don’t really know.
I don’t just advocate this approach for new businesses, I advise it for established businesses embarking on a project. My logic is: you can’t be sure a product will work in the market till you try it, nor can you plan a project until you know how fast (velocity) the team will work. In fact, until the team trys to work together and build something you don’t have any data on which to project plans. Making estimates without data is little better than guessing.
Thus, I advise a Mao like approach to corporate projects, “let a thousand flowers bloom” - start multiple small projects, small teams and use portfolio review to remove those that don’t seem promising and reallocate resources to those which do seem promising - or launch more experiments.
Unfortunately, like the entrepreneur, people get very attached to the idea of a project so it gets momentum. Big corporations respond by only starting projects in which they have a high degree of confidence. That means they do a lot of pre-project work - planning, designing, etc., this in turn makes it difficult and expensive to start projects, which in turn means that any project that does get started already has momentum. And it means that once underway the project finds it difficult to cope with change.
It seems to me that successful projects in corporations are often the result of one person who wants the project to happen and does what is necessary, not unlike entrepreneurs. In both cases a strong willed, capable, person makes something happen. That person needs to be motivated, they need hope, they need ambition and hope. Such people are going to kind who ignore naysayers and doubters.
The Agile approach - try, gather data, evaluate, or my “fail fast, fail cheap, retry” approach are not going to go down well with the kind of pig-headed, obstinate, passionate, do-anything-it-takes, approach which has made many successful projects a success. Quite the opposite.
Interestingly Benjamin had another example of a company which does take the “fail fast, fail cheap, try again” approach and was staffed by passionate, hopeful, people. From what he told me these people were passionate about the process as much as they were passionate about the products they tried. They could accept regular failure of good ideas because they saw the process working, and perhaps more importantly, could transfer their hope to the next idea. There was always a next idea.
What I am saying is: Don’t rely on hope to get your projects done, use data - be empirical not emptional.
Finally, I should say, that while I talked much of this over with Benjamin he would be the first to point out unvalidated steps in my thinking, and ungrounded assumptions I’ve made. So maybe this entire entry is really a hypotheses. The hypothesis is:
“The trial and error approach of Agile is unlikely to please those who get passionate about an idea and want to move heaven and earth to make it happen.”
I’ll let you, dear reader, decide for yourself on that hypotheses. If you have any evidence - to support or disprove - my hypothesis please add a comment below.
Wednesday, June 22, 2011
When did Scrum start loving project managers?
One of the things I’ve always found paradoxical about Scrum (specifically ScrumTM) is its position on management. On the one hand, Scrum is very management friendly - see my Scrum has Three Advantages over XP post. Basically Scrum has done a very good job of marketing itself to managers.
But Scrum is a little like a Monty Python Spring Surprise - “that's our speciality - covered with darkest creamy chocolate. When you pop it in your mouth steel bolts spring out and plunge straight through-both cheeks.”
Hidden inside the tasty Scrum case is a sometimes evangelical dislike of managers, and in particular project managers. Take these excerpts from the Scrum Primer (Deemer and Benefield, some versions have Larman as a co-author too):
Take another example, Bas Vodde’s Nokia Test, the final question asks “are project managers (or anyone else) disrupting the work of the team?” Every time I show that question to a project manager we have to discuss it, project managers don’t generally believe they disrupt the team unreasonably. It certainly looks like Bas doesn’t like Project Managers.
A few years ago when Jeff Sutherland spoke in London I recall him saying there was little future for project manager. Many needed to revert to programming (which they had done before project management), a few would become Scrum Masters, a few Product Owners and a very few could continue being project managers on the largest projects.
Sutherland’s own Scrum Handbook seems pretty clear: “there is no team manager or project manager in Scrum.” (Actually, if you read what else the handbook says about project manager it looks like the text is taken directly from the Scrum Primer, Sutherland seems to feel the same way as Deemer, Benefield and Larman.)
Given all the anti-manager, specifically anti-project manager project manager noise from some in the Scrum camp I found it surprising a couple of months ago when I noticed that Scrum Master Certificate now come with the implicit endorsement of the Project Management Institute.
For example, take Martine Devos’ London Scrum Master Course, it is worth 14 PMI Professional Development units. Jeff Sutherland’s own Scrum Master course boast 16 PDUs (one assume these are PMI units although he doesn’t state so explicitly.)
So, if the PMI are now crediting Scrum Master Courses, and the Scrum folks are making their courses compliant with PMI rules then one assumes that the two are reconciled. Why would a project manager who is intent on being a Scrum Master, and therefore no longer being a project manager, want credits?
Maybe Turkey’s are voting for Christmas. It looks odd for me.
Actually, to be fair to Scrum, the situation is a little more complex than I’ve laid out here. Looking a little bit further into Scrum history we find the following.
Schwaber and Beedle in Agile Software Development with Scrum say “The Scrum Master is a new management role introduced by Scrum” and a little later “The team leader, project leader or project manager often assume the Scrum Master role.” This final statement describes what I have seen happen most often in practices.
In Agile Project Management withScrum Schwaber says “The Scrum Master fills the position normally occupied by the project manager. I’ve taken the liberty of redefining the role.”
One explanation might be that the view of the Project Manager has changed over time. Initially the Scrum originators saw project managers as candidates for filling the Scrum Master role - or at least not the source of problems. As Schwaber almost says: it is the same role filled in a different way.
Later Project Managers, and maybe all managers, came to be seen as a problem, and, most recently as it becomes clear that Project Managers can be Scrum Masters and can be a force for good on a project the position has returned to the original view.
Alternatively it might be there are multiple opinions on how Scrum and the Scrum Master relates to the traditional Project Manager role. It benefits some people, at some times, to claim the Scrum Master is not a Project Manager. And it benefits some people at other times to reconcile the two roles.
One of the advantages of Scrum, specifically ScrumTM, is that is defines what is it, and is not, much more clearly than “Agile”. However with time this picture is becoming muddied.
Finally, this entry is a bit critical of Scrum, I won’t pretend it isn’t, but really, I’d like to understand what is going on here. If anyone can shed some light on the thinking, whether it changed or not, please add a comment.
But Scrum is a little like a Monty Python Spring Surprise - “that's our speciality - covered with darkest creamy chocolate. When you pop it in your mouth steel bolts spring out and plunge straight through-both cheeks.”
Hidden inside the tasty Scrum case is a sometimes evangelical dislike of managers, and in particular project managers. Take these excerpts from the Scrum Primer (Deemer and Benefield, some versions have Larman as a co-author too):
- “The ScrumMaster is not the manager of the team or a project manager; instead, the ScrumMaster serves the team, protects them from outside interference, and educates and guides the Product Owner and the team in the skilful use of Scrum.”
- “unlike a project manager, the ScrumMaster does not tell people what to do or assign tasks – they facilitate the process, supporting the team as it organizes and manages itself. If the ScrumMaster was previously in a position managing the team, they will need to significantly change their mindset and style of interaction for the team to be successful with Scrum. In the case that an ex-manager transitions to the role of ScrumMaster, it is best to serve a team other than the one that previously reported to the manager, otherwise the social or power dynamics are in potential conflict.”
- “Note there is no role of project manager in Scrum. Sometimes an (ex-)project manager can step into the role of ScrumMaster, but this has a mixed record of success – there is a
- fundamental difference between the two roles, both in day-to-day responsibilities and in the mindset required to be successful. ”
Take another example, Bas Vodde’s Nokia Test, the final question asks “are project managers (or anyone else) disrupting the work of the team?” Every time I show that question to a project manager we have to discuss it, project managers don’t generally believe they disrupt the team unreasonably. It certainly looks like Bas doesn’t like Project Managers.
A few years ago when Jeff Sutherland spoke in London I recall him saying there was little future for project manager. Many needed to revert to programming (which they had done before project management), a few would become Scrum Masters, a few Product Owners and a very few could continue being project managers on the largest projects.
Sutherland’s own Scrum Handbook seems pretty clear: “there is no team manager or project manager in Scrum.” (Actually, if you read what else the handbook says about project manager it looks like the text is taken directly from the Scrum Primer, Sutherland seems to feel the same way as Deemer, Benefield and Larman.)
Given all the anti-manager, specifically anti-project manager project manager noise from some in the Scrum camp I found it surprising a couple of months ago when I noticed that Scrum Master Certificate now come with the implicit endorsement of the Project Management Institute.
For example, take Martine Devos’ London Scrum Master Course, it is worth 14 PMI Professional Development units. Jeff Sutherland’s own Scrum Master course boast 16 PDUs (one assume these are PMI units although he doesn’t state so explicitly.)
So, if the PMI are now crediting Scrum Master Courses, and the Scrum folks are making their courses compliant with PMI rules then one assumes that the two are reconciled. Why would a project manager who is intent on being a Scrum Master, and therefore no longer being a project manager, want credits?
Maybe Turkey’s are voting for Christmas. It looks odd for me.
Actually, to be fair to Scrum, the situation is a little more complex than I’ve laid out here. Looking a little bit further into Scrum history we find the following.
Schwaber and Beedle in Agile Software Development with Scrum say “The Scrum Master is a new management role introduced by Scrum” and a little later “The team leader, project leader or project manager often assume the Scrum Master role.” This final statement describes what I have seen happen most often in practices.
In Agile Project Management withScrum Schwaber says “The Scrum Master fills the position normally occupied by the project manager. I’ve taken the liberty of redefining the role.”
One explanation might be that the view of the Project Manager has changed over time. Initially the Scrum originators saw project managers as candidates for filling the Scrum Master role - or at least not the source of problems. As Schwaber almost says: it is the same role filled in a different way.
Later Project Managers, and maybe all managers, came to be seen as a problem, and, most recently as it becomes clear that Project Managers can be Scrum Masters and can be a force for good on a project the position has returned to the original view.
Alternatively it might be there are multiple opinions on how Scrum and the Scrum Master relates to the traditional Project Manager role. It benefits some people, at some times, to claim the Scrum Master is not a Project Manager. And it benefits some people at other times to reconcile the two roles.
One of the advantages of Scrum, specifically ScrumTM, is that is defines what is it, and is not, much more clearly than “Agile”. However with time this picture is becoming muddied.
Finally, this entry is a bit critical of Scrum, I won’t pretend it isn’t, but really, I’d like to understand what is going on here. If anyone can shed some light on the thinking, whether it changed or not, please add a comment.
Thursday, June 02, 2011
Agile on the Beach: Falmouth, September 15-16, 2011
I’ve mentioned some of the work I’ve been doing in Cornwall over the last eight or nine months in this blog a few times, and anyone who follows me on Twitter will have seen my Tweets about the “Cornish Software Mines.” Well, one of the spin off of this work is a Cornish Agile Conference - Agile on the Beach.
Agile on the Beach is happening in Falmouth on Thursday 15 and 16 September 2011. Speakers include: Kevlin Henney, Tom and Mary Poppendieck, Rachel Davies, Steve Freeman, Jon Jagger, Jason Gorman and quite a few more - see here. Some more speakers will be announced nearer to the conference.
Tickets went on sale today, early bird price is £230 - if you are quick you might get one of the limited number of £195 tickets available.
The organisers (and yes, I’m one) hope that people attending the conference will take the opportunity to extend their visit to Cornwall into a long weekend. After all, Cornwall is much better know as a holiday destination than a software development centre.
All the details on the Agile on the Beach website. In addition, if you plan to attend sign on to the LinkedIn group and you can see who else will be there. More details are being announced all the time so to stay up with the latest announcements follow the Twitter hash tag #AgileOTB and Twitter User @Agileonthebeach.
Agile on the Beach is happening in Falmouth on Thursday 15 and 16 September 2011. Speakers include: Kevlin Henney, Tom and Mary Poppendieck, Rachel Davies, Steve Freeman, Jon Jagger, Jason Gorman and quite a few more - see here. Some more speakers will be announced nearer to the conference.
Tickets went on sale today, early bird price is £230 - if you are quick you might get one of the limited number of £195 tickets available.
The organisers (and yes, I’m one) hope that people attending the conference will take the opportunity to extend their visit to Cornwall into a long weekend. After all, Cornwall is much better know as a holiday destination than a software development centre.
All the details on the Agile on the Beach website. In addition, if you plan to attend sign on to the LinkedIn group and you can see who else will be there. More details are being announced all the time so to stay up with the latest announcements follow the Twitter hash tag #AgileOTB and Twitter User @Agileonthebeach.
Subscribe to:
Posts (Atom)