The Agile Warrior

Leadership is one of those personal things I find hard to give advice on. As if there were merely 10 things you needed to do to successfully lead your agile team. I feel no more qualified to tell you how to lead your software project than I do telling Wayne Gretzky how to play hockey.

Having said that, there are some things I’ve seen really good team leads do that enable them to:

• make the delivery of ‘bad news’ a non-event,
• tell very early whether their project is going to ‘make it,’
• create and maintain a culture of excellence from day one on the project,
• and make coming in to a work a joy while being able to sleep at night not worrying about the craziness of tomorrow.

Not everything on this list is going to work for you. Like I said, leadership is personal and everyone has got to find their own style and way.

But if you are looking for a starting point on how to lead your agile team, you could do a lot worse than starting with these.

1. Ask the Tough Questions Early
2. Go Spartan
3. Make the Truth Self-evident
4. Deliver Fiercely
5. Set the Bar High Early and Keep It There
6. Make Yourself Obsolete
7. Make the Team Accountable
8. Cheerlead
9. Give Up Control
10. Accept Three Simple Truths

Let me expand on each of these points a little.

1. Ask the Tough Questions Early

Working Down Under, I had the opportunity to ride shotgun with one of ThoughtWorks’ top salespeople—a gentleman by the name of Keith Dodds. One of the many things Keith taught me was the importance of asking the tough questions at the start of any new engagement or sale.

1. How much experience does your team have?
2. Have you ever built a search engine before?
3. Do you foresee any problems with two analysts and thirty developers?

At the beginning of your project you want to do the same thing. You want to get all the skeletons out of the closet and into the open. What’s the single most important thing this project needs to do? Anything keeping you up at night? Everyone clear on what success looks like?

It’s about alignment and making sure you’ve got the right people on the bus, and everyone understands the direction we’re headed.

My favorite tool for doing this is the agile inception deck, a lightweight project chartering tool consisting of ten questions you’d be crazy not to ask before starting any agile project.

However you do it, call out any craziness and deal with it before the project begins.

2. Go Spartan

This is one of the best strategies I know for setting expectations around dates, and determining whether you’ve got schedule risk with your project.

The premise is pretty simple. When you start delivery, build the simplest, most spartan, stripped-down, bare-bones version of the system you can. Build a couple of critical end-to-end stories and see how long that takes.

Why? Because if after three or four iterations of this it becomes apparent the date is out of whack, delivering that message after you’ve gone spartan is way easier.

Even going flat out, delivering the most simple stripped-down version we can, there is no way we are going to able to that date. What do you want to do?

Going Spartan is great because it enables you to have this conversation from a place of integrity, honesty, and conviction. Something has to give. No drama. No need to get crazy. Just a case of too much to do and not enough time. In other words, the state of any interesting project.

By doing this, you are also making the truth self-evident.

3. Make the Truth Self-evident

No one likes being the messenger of bad news. Fortunately, agile makes it easy to let the facts speak for themselves by tracking and making visible things like:

• team velocity
• projected delivery dates
• blockers keeping the team from delivering

You don’t ever have to say: “The project is late.” It will be obvious the project is late! Everyone can see it. You’d look foolish trying to ignore or deny it. No wishful thinking required. Just acceptance.

And if you did the inception deck, you will have already had the conversation about what you were going to do when this happened. You can cut scope, push out the date, or something else. But at least you are dealing with it. No one is hiding it, or denying it, or setting someone up for failure later.

By creating a visual work space, and showing and making the true state of your project obvious to all, you won’t have to be the bad guy. You are simply showing that which is.

How management deals with this news is up to them, not you. So don’t take it personally. It’s just our duty to make sure they know early enough so they can do something about it. Which is why we like to deliver the bad news early.

4. Deliver Fiercely

Some people are afraid of spiders. Others, snakes. Those things don’t really scare me so much (snakes maybe a little). Nope. My greatest fear in life (and software projects) isn’t failing. It’s not trying.

Failing I can deal with. I fail all the time. I write blog posts that don’t resonate. I write software no one cares about. I regret how I handle certain situations and conversations.

But I try. And as long as I know I did my best, I’m good. That’s what lets me sleep at night.

Success is peace of mind attained only through self satisfaction and knowing you made the effort. Do the best of which you are capable. Don’t try and be better than someone else. Just make the effort to be the best you can. Don’t expect to make tremendous improvements each day. Make a little each day. Make each day your masterpiece. -Basketball coach John Wooden

This is what I call fierce delivery.

It’s showing up every day ready to work. It’s demoing the first version of your software two weeks into your project. It’s being a professional—even when you don’t feel like it.

Delivering fiercely does two things:

• It builds trust with your client.
• It makes everything easier.

When you’re busting your hump, iteration after iteration, your customer is going to notice, and they are going to like it. Trust me. There is no better way to build street credibility and trust than to simply rock up and deliver.

If they are like most customers I know in large, slow, bureaucratic organizations, they aren’t going to be used to this level of service. You are going to blow them away. Then with all that trust and goodwill you’ve built up, everything suddenly becomes easier. Your customers are going to be more forgiving on schedule. They’re going to give you the benefit of the doubt when you screw up. They are going to trust you to do the right thing and get things done.

It’s a way more fun way to work, and once you’ve earned that trust you are never going to want to lose it. It’s better than money.

Display your intent—deliver fiercely.

5. Set the Bar High Early and Keep It There

It’s way harder to correct bad behavior late, then to set good behavior early.

Take testing. If you don’t make it clear that writing automated tests is part of development for a story, some developers won’t.

Or continuous integration. If people don’t understand why it’s important to keep the build pristine, production ready, and working 100%, they’ll see no problem with checking in on top of a broken build and not getting excited when it fails.

Production readiness, quality as a team responsibility, refactoring, whatever is important to you and the team, make it explicit and set the bar high at the beginning of the project so everyone knows what the rules are going in.

6. Make Yourself Obsolete

Teams work best when they can take initiative, solve their own problems, and think for themselves. They can’t and won’t do that if they are highly dependent on you.

The best-led agile teams I have seen are the ones where the leader could disappear for a week and no one’s the wiser. It’s not that the leaders aren’t valuable, or they aren’t contributing. It’s more that they do such a good job setting the project and team up for success that they aren’t needed day to day.

Put yourself in your customer’s shoes. Would you rather have a team lead who can set his or her team up for success, teach them how to take initiative, and fend for themselves if he or she stepped out? Or would you want that guy who hoards information, takes all the credit, and entrenches himself so deeply in your world that having him leave would kill your project?

I am not saying you can’t lead and be valuable. But if you want to serve your customer well while freeing yourself up to move on to bigger and better things, make yourself obsolete.

7. Make the Team Accountable

You still with me in this article? Good. Because you know what? There are a lot of people, in a lot of companies, who don’t care about software the way you and I do. I know it’s shocking, but it’s true.

Good teams don’t have a problem with accountability. They make themselves accountable. You couldn’t stop them if you tried.

Other teams, however, need a little help. That’s why, if I suspect that a team I’ve got is lacking the accountability gene, one good way to instill it is to have them personally demo their software.

How many times do you think a team will show up unprepared with:

• no demo environment,
• no test data,
• that looks terrible,
• that crashes on startup?

Once is usually enough.

When teams know they are the ones who will be giving the demo, and that they are the ones who will explain why things do or don’t work, they’ll become accountable. And if they don’t, you’ve got a bigger problem.

8. Cheerlead

When you’re delivering fiercely, and pumping stories iteration after iteration, it’s easy for the team lose sight of the great work they’ve been doing, and the difference they are making to the lives of their customers.

Remind them.

Give them boost. A sincere hug. A pat on the back, or just appreciation and acknowledgement for a job well done.

Companies don’t do this nearly enough—so sometimes you need to do this for them.

How? Call out people who do exceptional things at standups. Make your team look good in front of the customer when demoing. Remind people of how cool the technologies and tools are that we have to work with, and how lucky we are to have jobs!

Injecting life, pulling peoples’ heads above the clouds, and a box of donuts can go a long way to lightening things up and making people feel good about themselves. Which leads to better work.

9. Give Up Control

This is the hardest point on the list. It’s counterintuitive, it can be highly contextual, and yet when done right it can lead to outstanding results even with average teams.

It stems from the understanding and acceptance that everyone who works for you is a volunteer. They don’t have to be there. They could be doing something else, and if you don’t serve or lead them well, your best and brightest are going to leave.

Don’t believe me? Try holding on to great talent today.

Our industry’s best and brightest crave three things above all else: autonomy, mastery, and purpose. You take away a their autonomy and you’ve taken away a huge motivational lever.

What does giving up control mean? It means letting teams take initiative and figure things out for themselves.

Don’t have a server? Go get it.

Need some feedback from the customer? Make the call.

Pushing code live becoming a pain? What could we do to fix that?

That’s doesn’t mean you don’t contribute your best ideas or stop teams from going off a cliff. It just means that you understand that people are going to take way more responsibility and ownership if they solve problems themselves instead of constantly having someone (like you) tell them what to do.

Self-organization is big part of agility. It’s what enables teams to get quality stuff done fast. But it only works if teams are empowered and trusted. And that means you’ve got to loosen the reins.

10. Accept Three Simple Truths

It is impossible to gather all the requirements at the beginning of a project.

Whatever requirements you do gather are guaranteed to change.

There will always be more to do than time and money will allow.

Once you accepte these three simple truths, leading agile projects becomes a lot easier.

You don’t stress as much about schedules (we know we’re already late!) You stop trying to own problems that are outside your sphere of control. And you just accept that there is always going to be more to do than time and money allow.

You stop taking things personally.

And software is personal. You put a lot of yourself into a software project, and it’s easy to take feedback, criticism, and things like schedule pressure personally.

But accepting these simple truths frees you from all that. It allows you to see that which is clearly, and to not try and change something that can’t be changed.

Bonus point:

11. There Is No Leader

This list makes a big assumption: that there is a single leader on an agile project. That is rarely the case.

That doesn’t mean that agile projects are leaderless. There can be many leaders on agile projects, and they may all lead at different times and in different ways.

You can have the strong vocal expectation setter who watches the bottom line, and makes sure the customer is getting the greatest bang for their buck.

You can have the quiet, behind the scenes analyst, who doesn’t say much, but when she speaks everyone listens.

Then you’ve got the developer who refuses to let any bugs into production and whose diligence and attention to detail causes everyone to raise their game.

The point I am making here is that leadership on an agile project is more about meritocracy and less about titles and roles. So don’t get stressed, if you’re the leader in title, but find others are leading in fact.

Agile teams are generally flat, and leadership is something to be earned (not taken or assigned). In fact some of the best projects I have been on have had no explicit leader. Just a team, a customer, and a commitment to getting things done.

Enjoy the ride.

Leadership is one of those topics that is hard to give advice about because it’s so contextual. For every point I just made on that list, I am sure you can think of examples where it won’t work. Great leaders make it up as they go, and you are going to have to do the same on your project.

But that’s a good thing. You are going to have your own style, charm, personality, and strengths, that make you effective in your own way. Work with that. Everyone leads differently, and what worked for Walt Disney and Steve Jobs won’t work for you and me.

Take what you need from this list. Ignore the rest. And find your own voice and way.

Really, the best advice I can give is:

Follow your gut. Serve your team. And be prepared to get out of the way.