Our next scheduled meeting will be on 9 May 2007 at 8pm to discuss Agile Software Development (2nd edition) by Alistair Cockburn. Since our move to the Lamb and Flag seemed to be a success, we’ll be going there once again. Let’s see if we can get the back room once again….
As per usual, we need to decide on the book for the meeting after next. So add your comments below listing your 3 choices in order…
[UPDATED: I declare the Winner to be Agile Estimating and Planning by Mike Cohn since that was the only one mentioned more than once in the voting]
As mentioned in the previous post, this meeting was different from usual in several ways. The most obvious one was that we had the authors (Mary and Tom Poppendieck) along to discuss the book, Implementing Lean Software Development. We also had a change of venue and met at the Lamb and Flag on St Giles. This proved to be quite a good choice as we managed to claim the small back room.
Along with the Poppendiecks and myself, Al, Jamie, Miquel, Steven, Tom and Mick were there. Al kicked off the discussion by saying that he’d read the whole thing during one overnight flight from the US. Apparently it made good in-flight entertainment.
I said that it seemed to me that the concept of Lean would be tricky to apply at Nominet, where we are a non-profit organisation without any real competitors (unless you count other top-level domains). Mary answered this with a set of questions of her own: “How do you know you’ve done a good job?”, “Someone is paying you – do you accomplish things?”, “What’s the business case behind what you are doing? Are you fulfilling it?”. She said that she’d given a tutorial to people who worked on the BBC’s childrens website. They know if they are giving a good return on investment if they managed to get the right percentage of the target audience.
Mick asked how he should go about convincing the business people in his organisation that cycle time (i.e. the time from customer request to fulfillment) is the thing to optimize. Mary responded by saying that you need to find out what your manager and your manager’s manager worry about. If you can show them that reducing cycle time will ease those worries then you have a way in.
Mick then wondered what his motivation was to do this. Why should he care about what his manager worries about? Tom P said that it is all about having pride in your work. If you want to get satisfaction from your professional achievements then you need to have that feeling of having done a good job. Al pointed out that these ideas need to have buy-in from people at the top of an organisation. Mary agreed and said that often people in a developer role get frustrated in her tutorials because they feel that they will be powerless to put these changes into operation.
I suggested that the phrase ‘Do it right the first time’ should be banned. Whenever it is mentioned in the Poppendiecks’ books it is followed by a description of how it is misinterpreted. I suggested that it should be replaced by ‘All the tests should pass all the time’. Tom P said that they use the phrase ‘Mistake-proofing’. Mary explained that the reason they mention it is that this phrase is used and misinterpreted by many people.
Miquel asked about how the advice to simplify and not automate complexity work when you can’t simplify any further. Mary referred to a presentation from the conference they are attending (ACCU 2007) which listed simplicity and leadership as the top two aspects of successful projects. She agreed that you have to automate once you’ve simplified as far as possible.
I asked about the idea that it is possible to write down the knowledge that comes out of the development process. How do we convince people that this knowledge is tacit and not easily transferred to a document. Mary responded by saying that she thinks this is wishful thinking and that people believe this has to work because they see no other way to transfer knowledge.
I mentioned that I thought the sections on Performance Reviews were very interesting – not something you generally find in an agile book. I asked how 360 degree reviews fit into this view of the world or whether they are seen as something potentially divisive. Mary said that she doesn’t think appraisals work, so she is suspicious of 360 degree reviews as they are trying to improve something that she doesn’t believe in. She mentioned the book Hard Facts, Dangerous Half-Truths, and Total Nonsense which talks about these things. She also said that study after study has shown that grading people’s performance doesn’t motivate them.
Miquel asked about the problem whereby when you are bidding for a contract there is always another guy offering to do the work in an impossible timeframe and budget. So to compete you need to lie about what you can do or lose the contract. Mary responded to this by saying that if a customer is only looking for the lowest bid then they are a bad customer and you’re better off without them. The situation is made difficult in the public sector by laws requiring these sorts of contracts.
This led onto discussion about limiting work to capacity, so that the queue of work to be done is always kept small. In the fixed-price contract situation, you end up with a huge list of things to do by definition. Mary said that the contracts are at fault and that this huge queue of work acts as a buffer between you and your customer. Tom P said that this separation is like separating the design from the implementation, which is a well know anti-pattern in software. He also recommended the book Release It! which discusses how to design your applications for the rigours of the production environment.
The take home points that people came up with were:
- Having bad customers is worse than no customers at all.
- Having bad customers is worse than no customers at all. (again for emphasis!)
- Working beyond capacity is always hard.
- Lean needs management buy-in.
- Contracts are often the problem due to the conflicts of interest they produce.
- “Agile” is not new untested and risky – manufacturing has been doing it for decades. It’s proven.
- Bad projects and contracts are just that.
- Lean doesn’t advise how individuals should behave in a non-Lean organisation.