My apologies if this has been said or written a thousand times before: YAGNI is XP’s way of exploiting the constraint.
Which means that XP, and hence most agile methods, are set up on the assumption that the development team is – or soon will be – the bottleneck. And having identified that bottleneck, our first task is to EXPLOIT it – that is, we make sure that the bottleneck resource only works on stuff that contributes to overall throughput. YAGNI and test-driven development do that. Oh, and a relentless pursuit of quality, so that the bottleneck doesn’t have to spend time on rework. And effective communication, so we get to spend more time developing and less time writing documents and attending meetings. And tight feedback loops, so that we can identify which stuff is valuable and which isn’t.
Next we must SUBORDINATE the whole flow to the pace of the bottleneck. Fixed-length iterations help us to measure that pace, and the various forms of planning game and iteration commitment help to prevent work arriving too fast.
And only when all of that is working well is it safe to ELEVATE the constraint, perhaps by expanding the size of the team. I’m fairly sure I’ve never seen a real-life case in which this step was required. For most of my engagements, successfully exploiting the bottleneck caused the constraint to move elsewhere; and in the rest, the SUBORDINATE step revealed a deeper constraint elsewhere in the organisation.
Adrian Howard
September 11, 2007
It’s a point chromatic and James Shore made in there Art of Agile book – see Ch 13 when it hits the streets (at least that where it was in the last review edition I saw :-)
Kevin Rutherford
September 11, 2007
Ah good, I didn’t make it up! They’ve taken down the review chapters now, so I’ll have to wait for the actual book to arrive…
Thanks for the reference!
Henrik Mårtensson
October 1, 2007
That assumption bothers me a bit.
First of all, the most common constraint for a company is the market. (About 70% according to G. Kendall in “Viable Vision”.) In that case, unless an agile methodology is used to exploit or elevate the market constraint, it will not deliver any real business value. (Yes, I know agile methodologies are good at doing that, if used correctly. Still, that is one part of agile that often gets left out.)
Second, if an agile methodology succeeds in moving the bottleneck from the development stage, then what? Unless management has adopted a management philosophy with a process of ongoing improvement, the company will stop improving. Soon after that, it is likely to backslide.
More and more, I have come to see agile as part of a solution, rather than a complete solution by itself.
Kevin Rutherford
October 2, 2007
Henrik, Yes, I see agile as that part of a TOC/lean transformation that’s specific to the software development department (and it’s immediate environment). I’ve seen several companies who thought that agile s/w dev would solve their problems, but in fact all it did was to highlight the real issues elsewhere in the organisation. Which is no bad thing, as long as going agile doesn’t create a local maximum, and as long as the business is ready to change throughout…