Agile is a Positioning Exercise
Agility is not a Methodology
Do you have trouble understanding what Agile or agility means in terms of a software project? Do you wonder what constitutes an agile team? If so, I’ve a fresh perspective for you to consider. Consider Agile not so much as a methodology but as a positioning exercise. Agility isn’t about performing heroic acrobatics to hit that tennis ball escaping the court. No, agility is about preparation, fancy footwork, to get to the best possible position - with or away from the ball - so as to maximize your attack or to minimize the risk of being caught off guard or on your heels - forced to resort to heroic acrobatics.
Consider the game of tennis. A tennis player clearly has to have good hitting technique but what is critical before and after hitting that tennis ball? If you don’t know the answer to this, pick up a game of Mario Tennis and after winning a few matches note where you position Mario before hitting the ball, where you position Mario after hitting the ball, and where your opponent is positioned throughout. Does a quarterback want to throw to the right while strafing left? Does a basketball player want to hop off-balance while fading to pull a jumper? No. Ideally, these athletes have both feet firmly planted, bodies angled for the play, and then execute.
Yeah, yeah - but what does this have to do with Agile you ask?
Isn’t agility epitomized by the ability to shoot a basketball while simultaneously dodging defenders and falling down?
That might be tempting to believe but of course not:
Agility or nimbleness is the ability to change the body’s position efficiently, and requires the integration of isolated movement skills using a combination of balance, coordination, speed, reflexes, strength and endurance. –Wikipedia
Ok - so let’s bring this back to Software development. Does the proposed definition apply, as is, to software development? Can you see your own team using this definition as the clarifying North Star? What does it mean to “the ability to change … position efficiently” and more importantly, can it be as simple as that? Really? Well, I think of it like this. Take a look at your team’s practices and consider what you might change in the name of this positioning objective.
Does the quality of your codebase contribute or detract from this objective? If your team had to shift gears, add new functionality or address problems with a dependency, how efficiently could they handle that work, and in how many different situations could they handle this quickly and effectively? What could your team do to improve this situation? What if you had to change some logic - how confident are you that your changes will or won’t affect other sections of code? How efficiently could you prove that? How long does it take to regression test your entire application. How often do you regression test the entire application? Could you automate that? How expensive is it to have confidence in your codebase? Do you have any silos of information on the team? Have you experienced turnover such that problems repeatedly pop up that require deep discovery about the services involved … before a relatively simplistic fix could be applied?
You can’t predict every possible feature request just like you can’t position yourself for every return in tennis but you can play averages, minimize risk and learn from your unpreparedness for next time. If you’re not sure how to get started, begin by centering the team or codebase after building or fixing something. In the land of the unknown, your best bet to keep yourself centered so that you are best prepared to go in any particular direction (like a joystick that pops back to center when you let go). Start by agreeing on a set of general best practices as center and strive to start and stay there. As you get to know the domain, the people and have momentum, you may be able to start cheating a bit. You may be able to hang out in the bottom right hand corner because you know this right-handed player prefers the cross-court forehand. The point here is not what position to maintain (only you can decide that). The point here is to simply recognize that positioning is a crucial and conscious choice and that to best handle whatever comes your way, you should strive to be positioned intentionally and correctly.
Agility is not demonstrated by falling over backward, out of control, hooking the basketball through the hoop behind your back in a desperation throw. Agility is moving the ball to the open position and then, while under complete control, adjusting to the shifting defense to find an open player under the basket, and then 2pts for simple layup. As a software team, you epitomize agility when you constantly work to improve your positioning both before and after every piece of work you deliver - maximizing your own potential for success given the decidedly dynamic nature of the beast.
What do you think? Give me some feedback if you have a chance!