Don’t push requirements – pull information

I always struggled to see how what Lean teaches us about pull systems can be applied to software development processes. That was until I had an “Aha!” moment a little while ago helping a client apply lean and agile principles to their delivery process.

The big fat lie

I understand how queuing theory can help identify and reduce bottlenecks in processes and have used finger-charts and kanban-boards to do this for a while, but I still find calling this a “pull system” to be slightly disingenuous. All that’s happening is that more “stuff” is being pushed based on a trigger when certain buckets get too low. This reminds me of my annoyance with early technologies on the web that were touted as being “push” but were really just “repetitive-pull” (but not in a good way). I’ve never seen a software organization where the developers have said to the business or product people “we’ve got nothing to do, can you think up some new projects or features for us please?”.

My objection was always that even though looking at a software delivery process as a pull system was vaguely useful for debugging some process bottlenecks, it was a fundamentally incorrect way of characterizing what was really going on. It’s just not true that features or stories are pulled down through the analyze-develop-test-build-deploy-not-necessarily-in-that-order pipeline by the customer or even by a release manager; they are pushed down that pipe by a product or project manager and the pushing often requires a healthy dose of lubricant.

Pushing string

My moment of realization came in a discussion about process over-runs in the definition or analysis phase of a project. The team recognized that requirements weren’t being communicated clearly to the developers and were planning to spend longer on the analysis and definition phase to make the requirement documents longer and clearer. Their diagnosis was correct but their prescription for how to fix the problem would just exacerbate the pain. If people aren’t finding a document useful the answer isn’t to make the document longer!

This situation reminded me of the idea of pushing string. Attempting to push a single-page document is hard (it bends and wobbles), so adding more pages should increase the weight, or “thud-factor“, of the document making it easier to push … surely there’s nothing wrong with this logic!

Empowered to pull

The solution I suggested is to invert the process, empower the developers, and get them to pull the information they need. This fits with the general concept of “people-centered processes” that attracts me to lean and agile approaches (remember a bad process will beat a good person every time). If you allow your development teams to take responsibility for the product and features they’re building they will then pull the information they need at the times they need.

So it may still be a push system for features, but the flow of information is now driven by a pull system. This flip in direction allows all the benefits of just-in-time production and saves the problems associated with maintaining a large inventory. If you write all the details of a feature too far in advance it is certain highly likely that much of that work will be wasted since the details will change or the context will shift. Documents have a shelf-life just like any other organic product and that shelf-life is much shorter than you’d like to think.