Most everyone has heard about complexity in software development by now. The takeaway many get is that it’s impossible to make predictions. But this is an over-reaction. Complexity means is that you can’t count on your predictions. This means we must always use feedback to see if our expected improvements really occur. When they don’t we should look to see why they didn’t.
Doing this requires answering two questions. First, how do you make reasonably accurate predictions in a complex system and second, how do you learn from failing predictions?
Both of these require that your approach be set up in a way to make local decisions within the full value stream so we can be reasonably sure that it’ll help the overall goal. It also requires that you can see the relationships between the components in the value stream.
If your approach is based on the value stream then both of these can be seen. By focusing on small increments to be worked on by semi-autonomous value increasers with well defined relationships between them we can see if the cost of delay will be increased or not. Again, we see the value of an explicit workflow.
This enables making local changes with some certainty of global improvements.
Note: This post is one of a series in the post Questions to ask about your approach.