The Agile Architect

Making Agile Compromises

The Agile Manifesto describes the values of agile. Agile methodologies tell you how to achieve those values. But what happens when that isn't enough? Is Agile open to compromise?

• By Mark J. Balbes, Ph.D.
• July 14, 2014

Here's the scenario: You are working the perfect agile project. Your team is pair programming. You're adamant about test-driven development (TDD). You have stories defined far enough ahead that the team keeps chugging forward. Everything is going great except for one small thing -- your metrics tell you that you are going to miss your deadline.

And not by a little, but by a lot. In common, over-optimistic developer fashion, the team simply underestimated the amount of work required to get the project done. Based on those estimates, deadlines were set, obligations were made and now real cash money depends on getting the job done on time. This is the real world.

You are called into your boss's office. He's a nice guy, very on board with agile but he's asking you a very direct question: How are you going to get the job done in time?

And you are forced to ask yourself, "What compromises am I willing to make to meet the deadline?"

The Seductive Options & Standard Agile Responses
Of course, there are some very compelling options that seem like they could be a good idea:

• Don't pair program.
• Don't worry so much about automated testing and test-driven development.
• Work longer hours.
• Add more people to the team.
• Cut scope.

There are, of course, good reasons for not invoking these seductive options.

Without pair programming, the team starts to have individuals who are knowledge silos where only they know how something works. If that person isn't around when needed, the team is slowed or stopped in their progress. Poor designs leak into the system making it harder to change and extend. And the date slips a little more.

Without TDD, software is created that is not easily testable by automated methods. Proper abstractions aren't created and software designs are subpar, making the system harder and harder to extend. And the date slips a little more.

Without automated testing of any kind, the product features begin to regress. Adding new features breaks existing ones and no one catches them. You may have the illusion of rapid progress with development because you aren't spending time writing tests, but you'll more than lose that acceleration when you manually test the system and discover all the bugs that must be fixed. And the date slips a little more.

Working longer hours doesn't necessarily produce more results. Programmers have only a certain amount of value they can produce each day. We can sprint longer for short periods of time but it is not sustainable. Studies have shown that longer hours do not equate to more productivity. Make everyone work longer hours and the date slips a little more.

Everyone knows that adding more people to a team to meet a tight deadline doesn't work. Even if they are excellent developers, they don't know the context of what they are programming or how the system is designed. Even if they are excellent testers, they don't know what to test for or have the benefits of the many previous discussions about system features and performance. Adding people to the team steals time away from the existing members who must train their new teammates. And the date slips a little more.

Cutting scope is, of course, a perfectly reasonable thing to do from the technical team's perspective. Unfortunately, you may not have a viable product to sell and/or you may be in violation of your contract if you don't deliver all of the features in the current scope of work. This is a great option if it is available to you. But what if its not?

Is There Room To Compromise?
Of course not! Don't be ridiculous! This is a column about agile.

Really?
This is where you have to understand the context of your own situation and use one of my rules I like to quote to my team when they are making decisions,"Don't be stupid." By which I mean understand the reasons for making a decision and don't misapply rigid rules as a substitute for thinking.

In this case, we need to understand why we use our practices, what they buy us in terms of adherence to the principles of the agile manifesto, and what we give up when we don't use them. The answers to these questions are completely contextual to your situation. I can't answer them for you but I can tell you what I've done in the past.

Compromising on Pair Programming
Pair programming is important. I don't abandon it with a looming deadline. However, I do look judiciously at the work to be done and ask if a solitary individual can just as effectively complete the task. Work that is routine and well known by the team (e.g. adding a small capability or minor adjustment to an existing feature) doesn't benefit nearly as much from pairing as new feature development. Spikes are generally best done by individuals so they can follow their train of thought. (Although I will sometimes put multiple developers on a spike, each working individually and sharing their results.)

My general rule of thumb for pairing is that all production code must be written by pairs, but I am willing to look the other way when we have an odd number of developers or if someone wants to work on something in their off-hours. We have enough eyes on our code to know that things won't go too far before someone else takes a look at what is being done.

With a deadline looming, I will often look at stories and tasks to see if any are reasonable candidates to be worked on by a single developer. These stories are typically small, targeted and limited in how much of the code base they touch. UI-polish stories typically fall in this category.

Compromising on TDD and Automated Testing
For myself, when I am programming, I would never compromise on TDD. It's how I think and I would just slow myself down to not do it.

However, there are others for which TDD is not natural and they struggle with it. I might be reluctantly willing, in exceptional times, to relax the rule on TDD as long as the code met our team standards and was backed up with a complete automated test suite. I watch this carefully, though, to ensure that good software design isn't being compromised.

Compromising on Work Hours
If people are excited about their work, they can work longer hours and still be energized. It's about finding the things that excite your people and letting them work on them during non-core hours (including weekends and evenings). Don't make it feel like its part of the workday. Let them choose the work so it doesn't feel like a death march. Treat your team members as individuals, with their own interests, desires and outside obligations. Keep an eye on the team and make sure they are being effective. Measure velocity and cycle time to see if increased hours really are increasing output.

Compromising on Adding People
If you are going to add more people to your team, make sure they are the right people and that they can solve some of your problems semi-autonomously. Carefully match the work to the people. You aren't trying to incorporate them into your whole-team approach. You are trying to use them tactically to meet a deadline.

On one of my current teams that is well behind in meeting their deadline, I've created a satellite team of five developers. I call them our SWAT team. They have their own war room and their own team lead. I let them cherry pick the stories they will work on, set their own scope based on their own estimates, and operate with their own processes. They operate in a limited part of the code base so they don't have to understand the entire system. The only thing they inherit from the core team is the configuration management strategy. Ultimately, all the code must work together. There is still some drag on the original team due to questions by the SWAT team but it is much less than if everyone were operating as one large team.

Compromising on Limiting Scope
This could be the hardest compromise of all to pull off. Assuming that wholesale cutting of scope isn't an option, we are left with very carefully defining our stories, limiting the acceptance criteria as much as possible, and keeping scope minimized at the microscopic rather than macroscopic level. In addition, it becomes incredibly important to make sure that not only are acceptance criteria clear, but that the team has the conversation with the product owner before starting development on a story. Too many times I have seen a seemingly small and innocent little story turn into a multi-day epic because the developers over-interpret poorly written or ambiguous acceptance criteria.

Final Thoughts...
Compromise is an ever-present part of our professional environment. We need to remember that our goal on an agile team is to deliver high quality, working software that meets the needs of our users. Everything else we do is subordinate to that goal. While many of the agile practices are crucial to a successful project, there are many ways to intelligently apply them.

During a deadline crisis, understanding why we are doing things the way we are allows us to critically choose when we can compromise without further endangering the deadline or crippling our ability to create future enhancements.