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…
Try adopting and adapting Tom Gilb’s “Competitive Engineering”. See Gilb.com and notice that his approach starts with measurable goals, tight time boxing, and inspection. For easy to read reports from a practitioner, see Niels Malotaux’s pamphlets at Malotaux.nl and note the breadth of the approach which extends rather further than Agile. Or read the very sensible Poppendieck Agile books and apply those ideas diligently.
Loved this sentence: “This is the Human Resources equivalent to the total rewrite of a legacy application, and it has some of the same problems.”
Inattention to technical excellence is one of those problems that often has to be made visible for a while before anyone cares to fix it. That’s why I like continuous integration as a team’s first agile engineering practice.
Thanks, Richard and Richard.
Richard Karpinski, working to measurable goals can be tricky. There is no numerical measure of code quality, so it’s all-too-likely to get the numbers you want without getting the quality. I think that it’s necessary to get people to care about quality, not just to care about producing the numbers that will keep them hired.
Richard Lawrence, I like continuous integration, too. It’s still a little tricky. I’ve seen a bunch of metrics programs bundled into the CI build and no one ever looked at them. You often have to move slowly at first.
Every team is different, and therefore the approaches that work are different.
Josh Kerievsky and Dave Rooney have also weighed in on this topic. And Robin Dymond.
I think Martin and Ron have great points but the observation that teams are creating technical debt and attributing that to Scrum is backwards. Scrum is making visible the technical debt that would be buried in a system for months in the waterfall method. Scrum asks team to use the visibility provided by Scrum to inspect and adapt. That process of continuous improvement, and the knowledge that there must be a better way should lead teams to improve technical practices. XP engineering practices are necessary but not sufficient. In some legacy or COTs environments some practices may be extremely hard and costly to implement. However other practices may be very successful in those envirnoments. See http://www.innovel.net/?page_id=13 for more thoughts on this topic.
Jim Shore has an excellent followup, Kaizen and Kaikaku His advice is well worth reading, and to excerpt from it here would diminish it. Go and read it.