I've just tried to order a copy of Mike Cohn's excellent new book User Stories Applied: For Agile Software Development but it's not quite available yet (actually www.amazon.co.uk recommends I order it used ... hmmmm). The draft has been online for the last few months but a few free sample chapters are all that's left, I'm afraid. Never mind - buy the book instead.
Mike uses a lot of Goldratt's Critical Chain thinking in his book. Take a look at this ScrumDevelopment yahoo-group message (hint: start from the bottom and read up) where he describes how he uses Critical Chain within a Scrum environment (which, coincidently, was kicked off by this quote from me on Hal Macombers excellent blog):
"In Clarke's message on Hal's blog he notes that he doesn't think anyone is combining Scrum together with Critical Chain ... I've been combining the two since 1999 and agree that they are quite synergistic."
Honestly, there's nothing so theuraputic as reading about yourself :)
Here are a couple of TOC papers that I've not seen before:
I'm thinking out loud, metaphorically, here. Bear with me (I think that's the wrong type of bear but it's late at night and being a Kiwi I pronounce all bear words the same, anyway).
In Extreme Programming Explained Kent Beck claims that XP practices make the cost of change curve shallow and that's why XP works.
However, Scrum doesn't (necessarily) do most of the XP practices. But it still works.
I have 3 theories:
In the more recent studies the changes were broken down further and it turned out the 80/20 rule was at work: that roughly 20% of the changes caused 80% of the work.
In other words, 80% of the changes on the big projects had a far shallower change curve ratio that 100:1.
AND 20% of them had a much steeper change curve.
So, in an agile environment, if we had a way of idenfifying those 20% - estimating how long they'll take, perhaps - and if they were important to the customer then we could tackled them first and FAIL EARLY before all the money has been spent.
And the less important ones? Perhaps the customer would relegated them to the bottom of the product backlog.
"Who should be the next CEO? I am the chairman of Future-Design Inc. Our $150M company is only 10 years old and moving ahead very fast. We sell innovative designs of lamps – for both homes and offices. Our products are truly unique. They are very functional – meaning the user gets the exact amount of light at the exact area he/she wishes. Then, our lamps are truly state of the art design. They catch the attention of any visitor by their elegant shape and give status to the office or home. Certainly we sell them with very high price tag. You can safely assume that at least 75% of our selling price is throughput".
Here's another real life example of a TOC Current Reality Tree that I produced it for an MBA assignment along with a mock memo (in word format) I wrote (as part of the assignment) that explains the tree.
If you study both side-by-side you'll see how they compliment each other when trying communicating the problem. It took me probably 3-4 hours, over 2-3 weeks, of subtle questioning within my team, to get the facts together and link the cause and effect. [IRS in the diagram = FLOP in the memo.]
The root cause - the aggressive schedule - should be a lesson learned for future projects but the current constraint is (a) the lack of credability with the business which is preventing new work and (b) a knowledge bottleneck (all the knowledge is held in the designers head) that makes it very slow to produce any new work.
This cloud shows the conflict faced by projects - do we allow changes and keep the customers happy OR do we not allow changes and keep the date and budget? Now I want to talk about how the most common way of producing software - the Waterfall Software Development Lifecycle - try's, but fails, to break the conflict. The essence of the waterfall approach is to "prevent change": thus preventing rework, thus only doing the bare minimum, thus being the most efficient way of producing software. It does this by spending the proper time upfront to get the customer's requirements fully, unambiguously, documented and signed off before starting the design. With change (theoretically) prevented the designers can do the very best design, without interuption, and then hand it over to the programmers, who can too work without interuption. The developers eventually hand over their code to be user acceptance tested by the future users who check that everything they signed-off on all those months ago is complete. Then the software is implemented in one BIG-BANG and everyone lives happily ever after. Unfortunately, there are some unpleasant sideffects - as I've tried to show in page 1 of the "Current Reality Tree" (CRT) below. This CRT is a Theory of Constraints thinking tool that shows the cause and effect at play within my "current reality" - the project I currently work on. It's not, perhaps, the prettiest CRT on earth and I've broken a few of the rules, but it's GOOD ENOUGH for my purposes. Read the tree from the bottom up. The boxes at the tail of an arrow cause the boxes at the head of the arrow. Follow your nose and you'll get the idea. In short, there are some pretty icky side-effects of this approach - late integration failure, bloated software being two. But it gets worse. The rationale for the waterfall is that you can prevent change, but you can't, as shown in page 2 of the CRT below. Try as you might you can't prevent change. In fact, because the software takes so long to specify and build - and don't forget it's probably about 40% bigger than it needs to be, there's ample time for things to change. So your setup "change control" procedures to eithor approve or reject the change. Since you're working on virtually everything, all at the same time, you can't easily swap functions in the changed function and swap out something else to maintain the same finish date. Instead you slip your promised date, enforce overtime or miraculously absorb the change into your plan. At some stage this "scope creep" results in too much slippage and the product is descoped (triaged is the politically correct term) to bring the dates in. At the end of the day your customers aren't happy with the final product because you've produced bloated software that doesn't suit their needs AND you've probably slipped your schedule a couple of times or more.
[BTW: The seminal waterfall article was written by Winston Royce in this 1970 article. Poor chap Royce since he preferred the iterative/incremental approach, now favoured by the "agile" community, but is labelled as the inventor of the much disliked waterfall].
Damn, Damn, Damn!
w.bloggar a nice looking windows bloggin software just lost my last entry ... moments before I published it . Gone. It's gone. gone. gone. Sob.
[updated 12 Feb 06 - removed broken link]
In my previous post I described how projects are stuck in a conflict. We can't both allow change and not allow change. We can't have our cake and eat it too. So what do we do?
In the next post I'll look at how the waterfall lifecycle approach try's - but fails - to resolve this conflict. But first a bit of background about TOC's approach to conflict resolution - the evaporating cloud.
The evaporating cloud has 5 parts as shown below:
Although in text environments such as email it's often written like this:
....D' a prerequisite that conflicts with D'
..B - requirement
A - common objective
..C - requirement
....D' a prerequisite that conflicts with D
Read this: "In order to A we must B" and "In order to A we must C" and "In order to B we must D" and "In order to C we must D'" but "D and D' are in conflict with each other".
Also, be wary that D' is sometimes called E and I'm afraid I constantly mix the two.
The cloud's inventor Dr. Eliyahu Goldratt believes that all conflicts can be expressed as a cloud, then resolved by surfacing and challenging the assumptions underling each arrow (i.e. AB, BD, AC, CE and DE) in the cloud.
Dr Goldratt, a physicist, says that conflicts simply don't exist in reality unless we humans make them. He gives the analogy of two scientists both measuring a tree's height. If one says 10 feet tall but the other says 20, they won't compromise on 15 feet. Rather, they would examine their assumptions, calibrate their tools and resolve the conflict scientifically. Goldratt suggests we should do the same with all conflicts. When the conflict is solved the cloud is said to have "evaporated" - hence the name "evaporating cloud".
Evaporating clouds results in win-win solutions. Compromising results in win-lose, lose-win or lose-lose solutions.
Here's an example of technical conflict from a prior post.