This week two Agile Coaches came to visit me here in Rome.
I really respect both of them because they started doing this job in 2000, and since then they’ve had plenty of time to make lots of mistakes and to learn from them!
Despite the fact that one of them comes from Northern Europe and the other from North America, right away we all agreed on our biggest fear as far as agile development: teams who embrace agile methods gain immediate advantages, but after a year or so they experience a crisis. In other words, teams who embrace agile methods gain immediate advantages but what they don't realize is that they're "working the same way they used to work."
But shouldn't agile methods be able to bring the team's defects to light? How can we tell whether or not we've embraced these methods? And what's the real goal of agile methods after all?
Most of the companies that are my customers have decided to transition to agile methods to make a profit thanks to the "maneuverability" these methods offer. If we can maneuver, we can guarantee our customers the ability to ask for and get the changes they need quickly and at the lowest possible cost. Depending on the specific agile method we follow (XP, Scrum or other) we might manifest this ability in the next Iteration or in the next Sprint. But the key point is that the process provides our customers with the chance to swerve when they ask for requirements; in other words, they can maneuver.
To be profitable, the development team has to be able to allow change with the least possible effort. So, an essential aspect of agility lies in maneuverability.
All too often in my workshops and my activity as Coach and Mentor, I hear developers complain that their customers have only given them part of the requirements, or that every so often they need to have a little chat to figure out what requirements they'll ask for in the future… all this runs counter to the concept of maneuverability typical of agile methods. To avoid idealizing this concept of agility, I want to be more concrete and reformulate the last sentence: all this makes profit impossible.
It's always important to clarify a key point with the team: by making customers believe that they can maneuver when the team isn't actually able to guarantee this maneuverability on a continual basis, failure is only a matter of time. As a Coach, when the team finds itself in a situation where they realize they don't have the technical capability to allow any maneuvering, it's a major opportunity for improvement. The first step to take is to find the causes for this dysfunction.
In my experience, it's not always easy for the team to figure out the causes behind this type of problem. Often they're unable to see it. Want a little hint? Is it possible that the problem has something to do with design?
"We're used to responding to change with IFs. What's wrong with that? It works!" This response came from Marco, a developer on a team who is now a supporter of the Anti-IF Campaign. A response like this one is no doubt an obstacle to maneuverability over time, and reveals the concrete problem of developers on these teams who are unable to seriously question they work practices because…they've never seen any other way to do things.
Then there are teams who think they've handled a change because they've designed lovely group choreography on multi-colored white boards in the form of sketches that rebel against geometry, or more disciplined, in the shape of UMLs. Then they end up "not noticing" that the quantity of IFs they"ve injected and the related level of McCabe has turned into a purple color on their favorite Eclipse metric plugin. And the next change will cost more effort than the last one.
And don't even get me started on teams that do refactoring and apply polymorphism (they chat with their objects!) and – incredible but true – they are unable to deliver maneuverability. Will our heroes succeed in questioning their understanding of refactoring? Will objects end up being used in a different way? Maybe these vertical hierarchies of subclasses of subclasses of subclasses don't solve the problem of change, even if they seem ever so object oriented. And maybe they're only big huge "ravioli". Here's the paradox: often it's the conviction that you know how to follow an XP practice (TDD, refactoring, etc.), along with a mix of presumption and indulgence, that makes it hard for you to question the way you apply that practice. "When I can’t deliver a change, is it the emerging design that doesn't work, or is it me? Do I fully understand the basic principles of emerging design yet?"
Here's my advice: Can your team "deliver maneuverability?" If the team answers "yes" in unison, ask your customer the same question and carefully verify the level of your team's self-indulgence. If the answer you get from the team is negative or undecided, be ready to question the process, make the team pinpoint the causes of the dysfunction, have them find new/different ways to take the next step.
