Category Archives: lean

Meeting 16 – The Goal

Posted on by
2

We had a couple of new faces at this meeting – Ursula and John. They are both interested in Agile Software Development very much from the perspective of Lean. Ursula found out about us because she had been following the Poppendiecks when they were in the UK earlier this year and saw that they were coming to our meeting. Apart from the newcomers and myself, there was also Tom, Mick, Miquel and Jamie. So no repeat of last year’s August meeting when poor old Miquel turned up and no-one else could make it…

Both John and Ursula also had older copies of “The Goal”. This earlier version seemed to be quite a bit shorter – less chapters and less pages too. Another interesting difference was the fact that the cover trumpeted the value of OPT (Optimized Production Technology), which gets no mention in the current edition. Apparently this was Eli Goldratt’s proprietary system to apply the theory of constraints. John said that you had to feed figures into a mainframe program and it would tell you what to do. It also cost millions of dollars. Mick pointed out that this wasn’t quite like Jonah in the book saying “don’t pay me until the system is a success”.

I thought it was interesting that Goldratt’s system was built upon the scientific method but that he had then created an implementation of it with secret algorithms. This seems to be at odds with one of the pillars of science, which is peer review. Tom agreed and said that the basis of the scientific method is that you try to break the theory.

Looking at the book as a whole, I found it to be slightly contrived in places. But this was forgiveable in order to keep the action going. So Jonah would pop up, dispense a few pearls of wisdom and then disappear. John said he found it “a bit too apple pie” for his liking, whereas Jamie likened it to a Michael Crichton novel. Miquel said that he thought that the main thrust of the book, apart from the theory of constraints, was that you should question conventional wisdom. I mentioned that I kept having visions of the Fry and Laurie sketches with the two business men who say things like “Damn it John!” all the time. This got blank looks all round so I moved swiftly on…. [Here's one on YouTube]

John said that he’d actually implemented these theories when he worked for Lucas. Previous to this the predictive system MRP (Materials Requirement Planning) had been considered the best way to do things. But they implemented the techniques of Kanban and “Permission to Manufacture”. He also mentioned the flood metaphor, where a factory full of inventory is like a river in full flood. You can sail anywhere you like without problem. As the stock levels are reduced, the rocks start appearing, i.e. problems show themselves. So you lower the level, cope with the temporary chaos, adapt to the new situation and repeat.

Tom said he was expecting some revelation at the end of the book about who Jonah was. He was a bit surprised when this didn’t happen. I also had this experience. I guess it leaves the reader wanting to read the next book! Jamie said that he was slightly confused when reading the interview at the back of the book by the sudden introduction of the acronym TOC. It was only on the third or fourth usage that it was explained that this meant ‘Theory of Constraints’.

Ursula’s interest lies in comparing Lean with Agile and seeing if there any practices of the former with no analogue in the latter. She asked what bottlenecks map to in the world of software. Tom said that he thought that incomplete requirements were similar to the idea in the book of the constraint being in the market. Miquel said he thought it was hard to find bottlenecks because you don’t have a physical production line to look at. In fact, in most agile methodologies you tend to avoid having the traditional analyst-architect-developer-tester pipeline. Mick said that there was a danger that people might try to turn software development into a “sausage factory” production line so that they could then apply Goldratt’s theory to make it more productive.

There were lots more interesting discussions, but my notes and my memory run out at this point.

Meeting 12 – Implementing Lean Software Development

Posted on by
4

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.

Oxtremists Table

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.

Oxtremists Discussion

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:

Steven

  1. Having bad customers is worse than no customers at all.
  2. Having bad customers is worse than no customers at all. (again for emphasis!)
  3. Working beyond capacity is always hard.

Jamie

  1. Lean needs management buy-in.
  2. Contracts are often the problem due to the conflicts of interest they produce.

Mick

  1. “Agile” is not new untested and risky – manufacturing has been doing it for decades. It’s proven.
  2. Bad projects and contracts are just that.
  3. Lean doesn’t advise how individuals should behave in a non-Lean organisation.