Agile process and local maximums

Changing your process to make it more efficient is a good thing. Changing it to make it less efficient may still be needed. Imagine your process as a function – you make changes along the x-axis and the y-axis is efficiency.


Imagine you are at the point where the arrow is pointing, looking a little to the left or a little to the right and you seem to be in a great place. Since you are at a temporary peak, any change is immediately  a little bit worse, but way over to the right after a more significant change there is a much, much better place to be. You need to see it and make the leap from the current comfortable local maximum to the other slope.

Think of it like a genetic algorithm. In a genetic algorithm you need to avoid the local minimum, to get to the optimum solution. You attempt to keep a broad stock of algorithms to breed with, to try and get past the local minimum. It is also easier to maintain a stock of algorithms rather than a stock of different processes. In the process world it isn’t quite as simple, since there isn’t just one fitness function to maximize and every team is different to a certain degree. But, you can pull different ideas from outside your organization, or from other teams inside your organization.

The other way to consider things is that you are in a good enough position on the x-axis you can  innovate on the z-axis and continue up the manifold. As an example, say you have a great setup for automated testing, so instead of changing that, instead you try and migrate from continuous integration to continuous deployment.

This can still result in interlocking processes that each depend on one another to succeed. If you have a strong manual testing culture, it works well with a slow release cadence and a rigid change control process. Trying to build a continuous delivery pipeline under those conditions is going to end in pain and failure. Trying to automate testing and relaxing change control could be really valuable even though the immediate impact of trying to automate testing is a slow down in feature creation.

Recognizing the prerequisites to an improvement and tackling these things in a reasonable order makes sense. It also lets you focus on making a particular change rather than blowing everything up at the same time. But you still need to look out from your hilltop and find the next mountain to climb.


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