On lean software development: Just-in-time vs. dependency management

One of the basic tenets of lean software development is that you try to delay decisions and commitments. This allows you to stay as flexible as possible because you have the most number of options for as long as possible – that is, before you actually make a decision that narrows down those options.

However, this becomes a cause for concern when planning and running a non-trivial and/or large project with multiple teams working in parallel. A big part of ensuring maximum throughput in such a scenario is making sure that dependencies between teams are not missed and that they are played out in a correct order. This ultimately ensures that blockages are held to a minimum.

Most often, to achieve this, many project managers step up planning. The idea behind this is to analyze a lot of the upcoming work, see what dependencies might lurk in the expected work, and ensure that each team plans to work on them before they block another team. This approach, that of planning as the answer, is definitely useful. It is a tad misleading, though. This is because it gives the illusion of having things under control. The trouble is that software development is extremely susceptible to even small changes. And, as anyone who has ever written software knows, changes happen. Quite often. Plans, as they say, are mildly useful as best. Instead, it is the planning itself that holds the value.

What I’m saying then, is just that in my experience, the amount of effort spent on planning never seems to a) cover everything, and b) things change along the way to make the whole exercise decay in value exponentially. This is not to say that planning is useless, of course – see above.

Instead, I believe, a better approach might be to do a basic amount of planning so that folks know what’s coming up in terms of work. This ought to be followed by teams planning for only about, say, 70% of their total capacity. The remaining 30% can be used for one of two things a) satisfying dependencies that other teams discover, and b) extra work if the former doesn’t take up all remaining time. This way, teams can be more agile, and actually complete work as they delve into it and discover issues. It also lessens the need for deep and detailed analysis, especially around integration nodes – which (again) is inventory with a short half-life.

One other benefit of going this route is that it makes explicit (and OK!) the phenomenon of discovering dependencies as teams work on their stuff, and the idea of fulfilling orders (functionality requests from dependent teams) in a just-in-time manner with analysis as fresh as it possibly can be.

What do you think?

3 thoughts on “On lean software development: Just-in-time vs. dependency management

  1. I think this is all useful, but it is also worth mentioning actions you can take to minimize concrete dependencies between stories at all. This revolves around loosely coupled code. By depending on Interfaces instead of concrete systems I have seen many situations where dependencies which were perceived to block a certain story would disolve when the story code could depend on an interface and let a future story build the system that our story code can plug into via the interface.

    It is my personal hypothesis that any story that cannot be played without a prior story can be rewritten to remove the dependency or can be approached with the question how can we do this instead of why can’t we do this. This approach is more inline with Set based development which you refer to in the opening paragraph.

  2. Taking a more selfish view, the dependencies I care most about are the ones that prevent my team from getting their cards finished. For example, we might need another team to modify one of their services that we use. What happens now is that we will discover this dependency when the pair does their design, which happens in a just-in-time fashion. Or it might be found once they start coding. Then, we need to make a request to the other group to make the change. Since they are not at our beck and call, in the best case they will put us on the backlog for their next sprint. Given our rules of “done-ness”, we will not be able to get our card signed off (and get points toward velocity) until that other group does their change. And so we have hangover.

    So if there is a way to know about this type of dependency earlier on, and I can get on that other team’s sprint backlog earlier, than the effort put into planning is absolutely worth it. Is it truly possible to find all these dependencies prior to doing the development? No.

  3. Getting back to the depending on interfaces, you could communicate with the team who cannot complete the system you depend on and agree on the interface you need implemented. Then you could complete your card before they complete their system and claim your velocity points:) at least sometimes this is possible.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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