The hidden costs in Agile: Frenetic Pacing breaks the team mentality.

Introduction

Agile Methodology for project management is a bi-gone conclusion these days. The question is not "if" you are doing Agile, but which flavor or what tweaks have you made. The desire to get software out the door faster and faster has a huge marketing appeal. You can get a fully featured product by the end of a few Sprints. All for the low cost of 19.95. There are costs though associated with that. Even if the teams are aligned perfectly going into a project, and everyone is perfectly aware of Agile and how to sprint, there are things that come up. Ghost's in the system. There is a cost to speed, the question is can your team handle it.

Speed costs balance

Balance is something that every tech organization should strive to maintain. To help understand this, I am going to use the analogy of a football team's offensive schemes. A good balance of running the ball, passing the ball, and trick play's can throw off the defense's attempts to get after the quarterback and make a big play. Conversely, too much speed can also cost the effectiveness of the team. There is a saying in every sport that involves catching a ball "Catch it, THEN make the play." This speaks to the tendency all humans have to rush and think too many steps ahead. But if one plans out well enough, makes the play simple enough, and can find the right method to pass to, the play is so highly effective that your offense becomes very hard to beat. There is a play style called "Hurry up offense" in the football. The idea behind it is to make your offensive players line up as quickly as possible before the defense can get mentally set, read you line ups, and catch what you are doing. It can be effective for a couple of plays until the Defense figures out that you are sticking to some much simpler plays.
With Agile development, there is balance too. Finding the right blend of process, people, and flexibility ultimately gains a much quicker push to market. Some flavors of Agile boast a 300% increase in efficiency and time to market. However, all that speed comes with a cost too. The lack of balance means that something will always lose. A healthy team should be allowing patches, technical debt, and new features in each release. However, when the team is too fast, something suffers. Depending on where the IT team sits, or who screams the loudest, you may have new features being developed, but left un-supported; you may have support for old products that are beyond their shelf-life, or you may have too much debt to fix without any new features to whet the whistles of your supporters. In any case, the point here is that too much speed costs you your ability to balance your releases.

Speed costs communication

As eluded to in the previous section, speed also has a negative impact on communication. When scrum teams are constantly changing, constantly pushing into new features, for example, the communication suffers. Going back to football, the nifty arm bands that many quarterbacks wear are not a fashion statement. It is a list of some quick plays they could use in the event the defense has spied out their plan. Doing an Audible mid-snap count can cost quite a bit, but occasionally it pays off. However, when priorities are constantly changing, the communication both to the customers and to the internal teams must be perfect. Not great, not good, perfect. The reason for this is if one hints that the teams are not going to be focusing on a specific set of work, but communicate it in the wrong way it can cause frustration, consternation, and in some cases loss of political support. Think of it like this: The ball is snapped, but the defense has your play scouted. No one is open, they are running up into your face, you scramble back and forth and finally see a glimmer. You have only a gesture to point out that you notice the opening. Is the receiver looking? Is a linebacker or a safety looking? You make the decision to point in the direction you are going to throw, throw the ball and for what seems like an eternity you wait. When out of the corner of your eye you see the defense come across the field far faster than you anticipated, you know it's going to be intercepted, but you can't do anything. What do you do?
This is the same sort of complexity that happens in communication with teams that is a byproduct of too much speed. When dealing with this, face to face is always preferable to email or instant message simply because it is much harder to convey tone in email or instant message.

Speed costs quality

Finally, Speed costs quality. The poignant example I have is my own personal experience. As teams rush to complete, their focus is more about finishing as much as possible, not finishing well. That does not speak to their personal scruples as much as it does the environment that is around them. They start spinning plates for each thing, then imagine all the additional regulations, requirements, and conversations that come up during the course of a week around those things. It's like spinning additional plates ON TOP OF the original plates and expecting something not to fall. Most often, the speed to delivery means a loss in overall quality with campaign promises and lobbying for getting them done "later."
If we are honest, the campaign promises are almost hollow coming out of the mouths of the ones uttering them. It is not the developers that become the problem, no, not the developers, or the QA team, or even the P.M. crew that pushes the pace. It is the customer and the leadership. My personal belief is that leadership should embrace the philosophy of "You can't kick my dog, but I can." Leaders should be able to lead their staff and defend them against all the environmental pressure that causes the "speed up everything" mentality. However, when there is a break in that defense, or worse, the leadership is pushing equally hard, speed becomes a threat that must be put down like a rabid animal.

Conclusion

So how do we quell this fundamental problem? Does it not seem like the unstoppable force meets the immoveable object? There is a beautiful moment, if we are honest with our teams, where as work comes to a grinding halt a level of truthfulness and transparency develops. A level that screams equally across the aisle and allows for a crucial decision to be made. Obviously, you get where I am trying to point you, the decision should be to try to maintain healthy speed. But I have seen all too many times a push to keep the reckless speed going as if to stand in the face of an adversary and spit fully in defiance. The problem is the adversary is us, the team that enabled the behavior, the team that supported the initiative to speed up, the team that is now as fragile as a bubble. What can be learned? Ultimately, when dealing with speed, use caution, put your seat belts on, and watch out for other drivers. That is to say: Be Careful, put into place some guidelines that can protect your teams and bring the much needed balance back to the lime-light, and do not be so myopic that you cannot anticipate cross fire from other divisions of your organization. If you can do those three things, you can wrangle speed for a little while. But always, ALWAYS seek balance.