Fixing the Agile Engineering Problem
A lot of people are talking, recently, about the fact that organizations that adopt Agile practices don’t always achieve the results they desire. See Martin Fowler’s Flaccid Scrum, Ron Jeffries’ Context, My Foot!, and Jim Shore’s The Decline and Fall of Agile for examples.
In my experience, most organizations have much room to improve both their project management and their technical engineering practice. Those that start with Scrum seem to improve their project management practice enough that the deficiencies in their technical engineering practice become more painfully obvious.
The answer is simple and obvious–improve the technical engineering practice. The way to do that is not so easy, however.
For example, Tim Walker suggests “Attention to technical excellence and hiring motivated people are required for it to be successful.” As true as this is, it’s no way for an organization to get from where it is to a desired state of being able to reliably create desired functionality in their software.
People cannot suddenly be attentive to technical excellence. They must slowly acquire the awareness and deeper understanding that they lack, or they would already be attentive. Hiring motivated people suggests that those doing the hiring will suddenly be able to understand what sort of motivation is required, how to discern it in candidates, and follow through with this criteria in preference to the criteria they’ve been using.
And what would you do with the people you have now? Those that are presumably not motivated toward technical excellence? Fire them all and replace them? This is the Human Resources equivalent to the total rewrite of a legacy application, and it has some of the same problems. There is a lot of domain knowledge hidden in there–knowledge that would be difficult to find written down anywhere. The new must achieve the competency of the old before it can begin to surpass it–until then, no benefit is seen. The new will be starting in the same context as the old, and therefore is likely to produce something with a similar organization (or lack thereof).
The bottom line is that the developers have to learn to recognize what is “better,” they have to learn how to do it, and the cultural context in which they work has to change such that it really is important enough to have happen. Depending on where you start, that’s a lot to change all at once. It can take a lot of time and energy. And leadership. And an understanding of people. And technical knowledge. And…