Arenal Volcano, from manueb on flickr http://www.flickr.com/photos/manueb/7159742363/sizes/z/in/photostream/Not every project is going to run smoothly, even in the best of teams. We have a great team here at AgilityFeat, and we’re very selective when choosing our customers, so our projects tend to be very successful.

But every team is going to hit bumps in the road sometimes, and we’re not immune to it. Recently we’ve had two projects with very important deadlines and ambitious agendas. One in particular also has a tight budget. As if that wasn’t enough, these important deadlines on separate projects ended up being right next to each other.

Sound like a recipe for disaster? It was definitely fraught with danger, and I’m not boasting when I say that many lesser teams would have failed in spectacular fashion. At this point, we’ve navigated the dangers and both projects are doing well.

No matter how good your team, process, or customers are, you’ll hit turbulence too. Here are seven tips we have learned:

1. Keep communication clear and open

When things start to turn ugly, development teams have a tendency to clam up. They invite the product owner over to their desk less often, the mood at standups gets more sarcastic or somber, and the whole team is ignoring the elephant in the room: “We’re going to be late, and we all know it. I just don’t want to talk about it yet.”

Team leads should be in constant communication with stakeholders, and you can’t spare them the bad news. You don’t have to rush to them in a panicked tone every time something goes wrong, but you also need to remember that bad news does not get better with time.

Keep the communication open amongst your team and with your stakeholders. Keep the tone unemotional, rational, and make sure everyone is well informed. At least everyone will see the bad news coming, which allows stakeholders to quietly plan for it.

2. Align team incentives

What are the constraints on your project? Is it features, a budget, or a timeline? Whatever it is, make sure the whole team understands the constraints and align their incentives with that.

I recently had a developer tell me that “Oh, I didn’t realize this project was fixed price. I would have handled that differently.” He didn’t realize the project was fixed price because he is paid hourly. It’s not that he is wasting time or anything, but his incentive is to build the best software he can, regardless of how long it takes. But our client was judging us against a fixed budget, and the team was not aligned to that.

Ideally the team gets compensated when and how the business gets compensated, be that fixed price or hourly or whatever. That’s not always feasible though, but I have learned that the full team still needs to understand what will make this project successful and profitable for the business as a whole.

3. Reassess priorities and constraints regularly

At the beginning of every project, I ask clients what is their most important constraint. Budget, schedule, or features? They only get to give one answer, and we plan around that. I also ask what their most important priorities are for the project – what features or goals will make this successful?

It’s important to remember that all of those are subject to change. As the original deadline nears, don’t assume that everything is still the same as when you started this project months ago.

Because you’re keeping open lines of communication with the customer, and sharing the good as well as the bad news, your customer may change their priorities. Continually revisit priorities with them, and ask questions like “So our top goals for the deadline next month are still X,Y, and Z, in that order, right?”

At the risk of being annoying, you should confirm those priorities regularly, and then make sure you actually complete those features in priority order before moving to the next one. Don’t work on X, Y and Z all at once. If you’re late and none of them are done, then you are guaranteed to have an upset customer.

But if you can at least get X and Y done, and you are only late on Z, the customer is much more likely to be forgiving. They might even ease one of the project constraints, like budget.

4. Communicate impact, but stay flexible

If you’re working in an agile fashion, then you have a process that encourages the customer to constantly add new work to the backlog and suggest revisions and improvements. That’s great, and you should encourage that because it makes for happy customers and better software.

But those frequent changes can be stressful when you are nearing the all important deadline or budget cap. As it approaches, you will need to communicate the impact of those changes with the customer and constantly ask for feedback on priorities.

A good customer won’t mind a discussion like this: “I realize that you would like to add more stuff to feature X, and I’m fine with that, but is it okay if we make that a lower priority? Since X works as it is now, we can finish up Y and maybe Z first, and then we’ll come back and make the additional improvements to X.”
By communicating the impact clearly to your customer, providing them with options, and empowering them with a choice, you are setting up a collaborative tone where you can negotiate as the deadline draws near.

5. Deal with contracts diplomatically

If your stakeholders are internal to your company, then this might not apply to you. But if you’re a service provider like AgilityFeat, then contracts are a necessary evil and will guide the relationship with your customer.

Take a moment and think about how your contract model is affecting the dynamics of your relationship with the customer.

A fixed price and fixed scope contract seems to favor the customer on the surface by removing perceived risk of budget creep. But it also creates a confrontational dynamic where both sides have an incentive to jockey for power over the other.

A Time & Materials contract seems to favor the service provider on the surface because they get paid fairly no matter how long the project takes. But it also creates fear and doubt in the customer’s mind. Can they trust you to get it done on time, or is this going to cost me a lot more than you estimated?

Regardless of the contract model you are using, remember that it will have a big impact on how you and the customer deal with each other during the most stressful phases of a project. Be diplomatic when dealing with the topic, and don’t rush to say things like “But that’s scope creep and not in the requirements!”

Be open about your concerns, but try to deal with them in a flexible manner that creates a win-win for everyone. The customer gets most of what they want and you don’t go broke doing it.

6. Assume best intentions

Contracts are a good lead in to this next bit of advice. No matter how tough the going gets, do your best to maintain a level composure with the team and the client. Getting angry is a valuable communication tool, but it can only be used sparingly.

Assume that everyone has the best intentions, even if you disagree with decisions they’ve made.

Even if you don’t actually believe it to be true, pretend everyone wants this project to succeed. They almost certainly do, and you’ll remember that too if you take a deep breath. In stressful times, we may not all behave exactly the way we want, but try to look past that and recognize that everyone is doing the best they can to be successful in a difficult situation.

That bad decision someone made is probably not because they are trying to deep-six the project. They probably just don’t understand the big picture, and as a leader you can communicate with them better to make sure they know what is expected of them and when.

7. Agile teams need leadership too

Self-organization is one of the key principles of agile. Good agile teams are made up of people you can trust to do professional work and to make good decisions. If someone is only comfortable when being told exactly what to do, they are not a good fit for an agile team.

When you build a team of highly skilled commandos, like we have at AgilityFeat, then it’s easy to forget that they still need leadership. Agile teams still need a visionary leader who can set the tone and the goals for the project. Sometimes they also still need the strong leader who can redirect them when they go astray, or even give them a loving kick in the butt when standards are not being met.

When the going gets less tough…

If you keep these 7 tips in mind when things are rough, then eventually you’re going to make it to the other shore and things will improve. At this point, don’t forget to take a moment to breathe and lick your wounds.

Last week after getting through a tough phase on multiple projects, we bought massages for everyone on the team. It was a small gesture to show our commandos how much we appreciated them. They rallied together during a tough phase, and in the end, we became a stronger team and created happy customers.

There’s still a lot more work to do, but it’s nice to see the sunlight again and know that you are a little wiser for the experience you just went through. That’s how a great team deals with adversity.