I influence software delivery. Software delivery is abstract and complex. It is abstract because most people don’t really understand what happens behind the bit curtain. It is complex because it requires the translation across many layers of abstraction and back and sometimes the value is lost in translation.
I say that I influence it, because my job is to increase the probability of success. To make projects more effective. I do not manage the team. I do not decide the deliverables. I do not even run the process. I do not write the code, very often.
What I do, mostly, is give delivery teams ideas and concepts that can help them increase their probability of success. What I do, secondly, is to convince their customers that those ideas are important, and that their (the customer’s) role is as or more important in the success of the delivery than the technicians who are writing the code.
What is my number one idea? Sequence!
What sequence is that? The sequence of delivery of value. Here are the Top 5 reasons why sequence is important as a concept:
1) Sequence allows me to stop on the way to completion, and still deliver some value.
Software projects have risks. There are inherent and external risks that may require us to stop (even temporarily) without completing the delivery of required value. If we work in parallel on several paths, it is possible that we have little or no value that is complete (deliverable) when something bad happens (like funding evaporates, or other business crises distract resources, or half my dev team leaves the company). Working in sequence, gives me the best chance of having at least some value to show for my early investment.
2) Sequence is clearer than priority.
Priority is “banded”. High, medium, low. Maybe there are three bands, maybe there are 5, maybe there are 10. It doesn’t matter, Stone’s law states that a disproportionate number of deliverables will end up in the highest priority band(s), such that a typical percentage distribution would be 60% high, 30% medium, 10% low. In that case, how does the delivery team decide which High priority item to start with? Or how many? Guess? Darned right we do, and probably different than the way the customer would want.
3) Sequence is easier to understand than dependencies.
Project managers are very fond of dependencies as a way of deciding what sequence things should be done in. This is because they are trying to “optimize” the project against cost and or schedule constraints. Truth is that this optimization actually tends to hurt the most when the crap hits the fan and we have to reduce scope to make a deadline, or when funding is cut, or when the team is damaged. This optimization tends to increase working on predecessor tasks in parallel rather than delivering a whole capability end to end. If we optimize for earliest delivery of value, we end up with a simple sequence.
Here is the other thing, most delivery teams don’t keep their project plans that current or detailed, and Gantt charts tend to confuse the hell out of both technicians and customers. Sequence is much cheaper to maintain and much easier to understand. All you need is the ability to count. And really, is our software delivery plan ever really that optimized anyway, heck no because there are always surprises and unknowns that change everything.
What does this have to do with priority? When we don’t know the value rank of deliverables, we try to optimize for constraints like cost and schedule. Since this creates parallel effort against predecessors to top priority deliverables, we end up with more complex plans and more sunk cost with less value to show for a longer period of time.
4) Sequence can be changed along the way without significant impact the the schedule.
One of the amazing properties of a sequence is that it can be changed. In fact, if you change the sequence of deliverables that have not been started yet, there is very little impact to schedule or cost, because why? Duh – no time, effort, or cost has been expended toward those deliverables yet. Of course, if you choose to resequence deliverables that are in process, there will be some knock on impact, but it will still likely be limited to context switching.
5) Sequence brings greater focus than priority.
My personal favorite. Focus is the most important predictor of success. If you are focused on a single deliverable, the chances of success rise dramatically, 2 deliverables still good. 3 and above not so good, more than 5 – minimal chance of success. In the context of software development, finishing one thing, then another means that we can have a whole stack of already working, tested software capabilities, each one adding to the pile. Working in parallel means that we can have a pile of half finished, completely untested, not really working nothing, for a very long time before any value can be realized from our effort. It also means it takes longer to reach a point where we can elicit feedback from our customer. If we finish one thing and get feedback and it is bad, we haven’t started the next 10 things so we can adjust. If I have already finished 10 things and get negative feedback, I have to redo 10 things.
When you have 10 High priority items, it is hard to select which one to focus on. When I rank deliverables in a value sequence, the team knows exactly what to focus on in what order.
Focus is an enabler of accountability. If I am working on multiple priorities, I have a built in excuse when I deliver nothing. When I work in sequence, there is no escape, no wiggle room.
Any questions?
No Comments