rob bowley

One of the keynotes at XPDay 2008 was from Dan Jones, the author of the books The Machine That Changed the World and Lean Thinking and one of the team of people who came up with the term “Lean Production”. It was quite humbling to be in the same room as the living person who has probably been more influential than anyone else to modern business processes in every industry and all over the world.

One of the most interesting things he said was that when they were coming up with the name for what they were trying to promote they considered “agile”, but thought it would be too difficult to sell and so decided on Lean instead. Also, he didn’t have much understanding of modern software development, but at a glance saw very little difference between what we called Agile and he called Lean.

So when we talk about Lean Software Development being an Agile methodology we’ve got it the wrong way around. Agile is Lean, Scrum is Lean, XP is Lean. You were already doing Lean Software Development, you just didn’t know it!

In my mind it’s time to drop the titles (which all carry too much stigma) and simply start referring to it as professional software development.

I ran my session on estimation again at XPDay 2008 last week. I’ve come up with a decent title for it now: “Dealing with the Estimation Fallacy”.

It followed the same format as the previous time I ran it so you can go there to find the slides etc.

Here’s the output from the discussion. I’m running this session again at SPA 2009 and after that I will collate the output from all three into something coherent and useful:

How do you keep the context stable?
The problem is managing the context. If the business says you need to do it sooner that changes the context.
What about if the business doesn’t have the full context? What about issues you don’t know about?
Why are we different to any other type of organisation?
It’s too difficult to estimate more than 2 months ahead
Familiar work is easy to estimate, the unknown is not (which is mainly what we do)
If we report back to the business regularly they can’t deny hard facts
Manage the risk by working iteratively
It’s quite common for people to start building skyscrapers before the architects finish designing the top

• but their customer’s not going to ask for another 20 floors and more space halfway through

We need to help the customer understand what they need
People need to know whether it’s a viable business case
Projects are never agile if you have requirements up front (fine if nothing changes though)
You should only commit to work three months ahead
“2 years” for a software project is too long - will not be competitive
Movies spend a long time in development, then they get the budget and the scope gets cut to fit. But, they are more predictable than software.
Too much money (e.g. banks) will never produce good software - scope to big.
Are big estimates/commitments ever believed by anyone? Often they’re only used to make projects viable
IT departments are not pushing back enough - should never suggest you can plan more than 3 months in advance
2 types of estimation:

1. The real business of estimation (e.g. stories, iteration scope, tasks ect)
2. The game of estimating within the business context

Agile projects are rarely ever really agile as they’re operating withing the context of the business/traditional practices.

XPDay 2008 took place last week and I felt it was a great success. The open space format really excelled and there was very little I saw/took part in that wasn’t interesting or generating new ideas. The general mood seemed to be that the understanding of agile practices and principles was quite mature now and most of people’s problems were around where we are coming up against and conflicting with the business context (5 year plan’s, understanding the need for slack and long term benefits against short-termism).

We were also honoured with a keynote from the inventor of Lean, Jon Daniels and his colleague Marc Baker who gave us a frightening insight in to the state of the NHS and how Lean practices are having dramatic effects, but I want to post separately about them.

Other sessions:

Software Craftsmanship

With Jason Gorman’s software craftsmanship conference coming up in the new year, John Daniels wanted to talk about what craftsmanship meant to us. It was a really interesting discussion and the general feeling was that people were uncomfortable with the idea that we could define what it meant to be a software craftsman as there are far to many skills and too much diversity in the types of these skills. This was summed up well by the following: To explain what a craftsman is, Keith Braithwaite used the example of his uncle(?) who has been a farrier for most of his life with people coming to him to learn the skills, yet he only considers himself a journeyman and we explored the similarities/differences between what he did and what we do. In the end someone came up with the excellent point that we don’t make and fit horseshoes, we build cathedrals and there are so many different skills needed (which change all the time) we could never be expected to “master” them. I’m going to Software Craftsmanship 2009 and I look forward to seeing how it pans out.

Why aren’t they typing more?

Douglas Squirrel asked us how we deal with people asking unanswerable questions like “why aren’t they typing more?” and “you need to focus on productivity rather than agility”. There were lots of interesting ideas, but the most revealing one for me was that we need to be able to deal with people rationalising rather than being rational (e.g. the idea that being busy = productivity). Someone mentioned a book called Predicably Irrational which investigates this phenomenon (and I shall add to my reading list). Most of what we do within an agile context flies in the face of conventional wisdom and is very radical compared to the most of the organisations we work with/within. I think this is a problem as a community we need to spend more time looking into.

Recently, whilst building a very complex work flow system for my organisation we joked how it would be much less expensive and more appropriate if we just gave them a few whiteboards and a stack of coloured index cards instead. It was working really well for us so why couldn’t it work for them?

I’ve just finished reading a few articles from my current favourite blog Evolving Excellence on the phenomenon that companies seem obsessed with trying to automate every possible process and are happy to spend gazzillions doing so, when a simple kanban would be far more effective and a darn sight cheaper.

Quote: “‘Excellence through simplicity.’ To me that quote from Lao Tzu has always epitomized one of the fundamental tenets of real lean.  Don’t proceduralize complexity, and don’t make something more complex than it needs to be.”

http://www.evolvingexcellence.com/blog/2006/06/forget_sap_run_.html

http://www.evolvingexcellence.com/blog/2006/04/keep_one_eye_on.html

The workflow system we delivered is barely used by the customer (who asked for it) because it’s too rigid and every possible scenario is not accounted for. They’re very keen to make improvements (which will cost money), so maybe I really will suggest a kanban board instead this time.

Scrum is getting a real bashing at the moment as you can see here and here and I think it could do with some defending.

I was on a team that adopted Scrum and it really empowered us. After a while, pair programming, TDD and refactoring became common-place because we learnt through the iterative process that they helped us write better software. People saw the positivity in the team and the productivity improvements and it lead to a fundamental shift in the department’s culture. Now all our teams are doing some form of iterative development, BDUF has gone out of the window and practices such as TDD and pair programming are actively encouraged by the management! People at all levels can see the difference it’s made to our productivity and the reputation of our department.

So Scrum can be very successful. It would never have got this far if people weren’t doing Scrum and getting positive results, in fact agile would not have become so big if it wasn’t for the success of Scrum so we’ve got a lot to thank it for.

However, here is where I think some of the criticism sticks:

Three people on the team above (including myself) went on the Certified Scrum Master course ran by Mike Cohn who is an excellent teacher, but I’ve since been on a “Scrum Estimating and Planning” course which seemed more geared towards telling people what they wanted to hear rather than any fundamentals of agile and the problems it’s trying to solve. As James Shore suggests in his article, the quality of the teachers on the CSM courses has a huge impact.

As company’s will always prefer to send people on a course rather than create a learning culture within (especially if they’re very small, which is more forgivable) the 2 day Certified Scrum Master course will be with us for a while yet and most significantly, will continue to be the main entry point to the agile world. People will continue to adopt Scrum because they’re failing with whatever they’re currently doing and continue to fail because the Scrum trainer will teach them how to write a story or run a stand up but not address the root problems, partly because you could never go into such detail in such a small amount of time and partly because that’s not the point of the course.

“Certified Scrum Master” suggests that you’re some kind of guru (it certainly sounds a lot more impressive then my BA(h) in Business and Quality Management which took me 4 years to get a mediocre grade in). Perhaps a name change would make it more credible. If organisations were not led to believe this 2 day course is going to solve all their problems then they wouldn’t be in the situation they’re in.

Edit: Since writing this article (a few hours ago) I’ve had a significant change of heart and feel I’ve incorrectly laid blame at the foot of the Scrum Alliance. It’s not their fault that their Certified Scrum Master training (which is designed to teach people how to become Scrum Masters, not solve all their problems) has become so popular. However, it is a bit unfortunate that the name could so easily be misinterpreted to mean more that it is and it’s also unfortunate that organisations hook on to the most simple looking solution to their problems (and no, I haven’t been threatened by Scrum mafiosa or bottled out I’ve just changed my mind).

It’s startling to see how much momentum has been gathering around Lean Software Development and I don’t think it’s a coincidence that at the same time many people seem to be falling out of love with Scrum.

At last year’s XPDay there were no sessions on Lean methodologies, this year there are three (the one I’m doing with Matt Wynne, Karl Scotland’s on Kanban, Flow and Cadence and a keynote from the Lean Enterprise Academy).

There’s something about this that makes me feel slightly uneasy. What’s so wrong with Scrum? Well, I’d be the first to stand up and say that Scrum has it’s failings - they’re the same reasons it’s become so popular. The simplicity, clear definition and business-friendliness of Scrum make it easy to sell (arguably, unlike XP) and waterfall or traditional development dynamics (project manager, use-case, Gantt chart, meeting) can be easily translated into Scrum’s characteristics (scrum master, story, burn down, stand up). Unfortunately all too often this is what happens resulting in what’s become know as Cargo Cult Agile, or WAgile, the underlying concepts and belief systems being mostly ignored. When I did Mike Cohn’s Certified Scum Master Course his principle lesson was “Inspect and Adapt” which he repeated endlessly throughout the course, but when I look on the Wikipedia entry for Scrum this doesn’t even get a mention so it’s easy to see how this happens.

So what’s so different about Lean? Well for a start there aren’t any clearly defined rules, but instead principles such as Eliminate Waste and Build Integrity In. However it strikes me that there’s just as much room for abuse with concepts such as Kanban, Minimally Marketable Features, Cumulative Flow Diagrams and so on. Consider this exert from The Toyota Way (which I’ve shamelessly stolen from James Shore’s article on Kanban Systems - I am actually reading this book as we speak, but haven’t got very far yet):

“…TPS experts get very impatient and even irritated when they hear people rave and focus on kanban as if it is the Toyota Production System. Kanban is a fascinating concept and it is fun to watch… When is the kanban triggered? How are the quantities calculated? What do you do if a kanban gets lost? But that is not the point… The challenge is to develop a learning organization that will find ways to reduce the number of and thereby reduce and finally eliminate the inventory buffer… So kanban is something you strive to get rid of, not to be proud of.”

Many of the reasons people aren’t being as succesful as they’d like with Scrum are exactly the same reasons they won’t be any more successful with any other methodology. People tend to focus on tools because it’s a lot easier than trying to tackle the often very difficult, challenging and more fundamental problems they grew from. Real change is hard and takes time, a very long time in some cases.

If you’re failing with Scrum don’t think lean, kanban, extreme programming or any other colour of agile will save you. Essentially if you’re failing it’s because you’re doing it wrong. However if you’ve found Scrum is working really well for you and has brought enormous benefits maybe you should come to the talk Matt and I are doing at XPDay and see how we evolved to a more lean process.


Update: since writing this James Shore has written a frighteningly similar post on The Decline and Fall of Agile, but I guess great minds think alike huh? ;-P

I was encouraged to put forward some of the presentations I’ve being doing this year to upcoming conferences and lo and behold they’ve only gone and accepted them. I will be running my Retrospective Surgery workshop and “Estimation Fallacy” (working title) session at Software Practice Advancement 2009. It goes without saying I’m a little bowled over by this.

Not only that but I will also be presenting at XPDay in December! The session is called “Using lean to evolve out of Scrum” which was the brainchild of Matt Wynne and based around our experiences working together on a project.

Gobsmacked I am.

Firstly I asked the audience why we estimate?

• Predictability
• To be able to choose between options
• Planning
• So we can manage budgets
• To justify development
• Manage expectations
• Learn more about the problem
• Synchronise with other projects
• Get a cost benefit ratio
• Prioritisation
• Customers like to know when it’ll be ready

I then did a short presentation (slides below) explaining why we’re no good at estimating.

Finally we had a group discussion where we discussed my findings and what we can do. Here’s the output:

People often care more about the deadline as they only use 5% of the features

We need to create a better contract with the customer

When we need to synchronise with other projects what choice do we have?

We rarely measure by what we’ve achieved.

• Should be more like “we need this much business value for this much money”

Trust doesn’t exist - contracts are defense against the risk

That’s life! E.G. 2012 Olympics site build - people need to come together on a deadline

Agile enables us to react and focus on what’s important - is it scope? is it cost? is it deadline?

Also, iterative development means at least we deliver every two weeks to at least have something.

Measurement should be based on what’s been done.

However, estimation is used to measure productivity - we need better forms of measurement.

Estimation is not risk management but it’s what it’s used for.

Should the customer estimate value?

The closer you get to the end of a project the greater the pressure to estimate accurately.

Also is the impact of pressure from customer to estimate more accurately.

When integrating with 3rd parties need to estimate.

Need to recognise risk when estimating.

• Sponsors need to understand risk.

Time/duration of estimate = ^risk.

It’s about how we manage the estimate not the way we estimate where the answer lies.

• Managing risk/quantifying risk

If customers are more aware of risk they’ll make better decisions.

A good model would be to recognise the risk in the contract e.g.

x% risk = x cost

xx% risk = xx cost

Resources

Slides

Click here for ppt >>

Click here for pdf >>

Links

The Black Swan: The Impact of the Highly Improbable

Oliver Burkeman on why everything takes longer than you think

Planning Fallacy

Overcoming Bias: Planning Fallacy

Optimism Bias

Dept. of Helth Guidelines for Optimism Bias

Cone of Uncertainty Controversy

Predicting Velocity When Team Membership Or Size Changes Frequently | Mike Cohn’s Blog

Use Risk Management to Make Solid Commitments

There’s a lot more on my delicious bookmarks tagged for estimation

About a month ago my Mephisto powered blog conked out.  Thankfully as it cached the content it was all still available, but I could no longer log in. It transpired my hosting company (Dreamhost) updated the version of Rails to 2.1.1 and Mephisto only works on 2.0.2. They say they told me (I don’t have any record), but I could “freeze” the version my site runs on retrospectively. After a week or so of dispairing evenings battling to get something running again (incuding reinstalling Mephisto completely) I admitted defeat and have finished my experiment with Rails (although I’m still using Ruby along with Cucumber and RSpec at work). I feel that whilst Rails may be an exciting new framework for delivering web apps it’s a bit flakey. Whilst looking for help online it seems this versioning thing is a common problem

Anyway, now I’m on WordPress (damn it was so easy).  I’ve not moved any comments over and some links may not work until I get a chance to sort them out.

The good news is the erratic splurge of posts coming through to Google Reader users should no longer be an issue but please update your feed to the following:

http://feeds.feedburner.com/robbowley