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.

5 thoughts on “TOC and YAGNI

  1. 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.

  2. 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…

  3. Pingback: why YAGNI acts to EXPLOIT the bottleneck « silk and spinach

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s