3 Tips on Scaling Agile Development

I’m often asked for tips on “scaling up Agile.” This usually means, “we got Agile working at our team level, but as we’ve tried to expand it to the rest of our GIANT COMPANY, we’ve encountered all sorts of problems. People don’t see the light! How can we make them BELIEVERS?!?!”…or something a little more level-headed than that.

At some point, adopting Agile development becomes an organizational change management exercise that has little do with Agile itself. Last week at the IBM Impact Unconference, I was part of the opening “unpanel” where someone had asked for help in adopting Agile in this context…or, at least, that’s the question I chose to answer. Here’s what I said:

1. You need an executive sponsor, get one – doing Agile at the team level is fine, and you can do a bottoms-up approach. You might even be able to expand out to QA teams (who are traditionally separate from development teams) and others, but to really spread to the rest of the organization, a high-level executive must bless and then force the effort on the organization. Here, the hierarchy of the organization works in your favor: if the big boss says to do it, people tend to do it. Executive sponsorship always gives you permission to screw-up as you learn. It reduces your personal risk (and that of your team). And, let’s face it, the first few iterations of an Agile team are rough: so much of Agile, initially, is about exposing the weaknesses and poor development practices organizations are doing (mainly: promising too much in each release, also, not fully working as a team around one product) – so there’s going to be some failure at first. The executive is your blame-game safety net here: a good Agile executive knows that the first few cycles of doing Agile is all about making people realize they’ve been doing it wrong by exposing the poor results of their practices…and then learning from that, not punishing them.
2. Learn how to report to Management, and do it – as “lower-level” technical people, you probably could give a rats ass about all that “reporting” management does up the chain. The fact of the matter is, all those damned spreadsheets and project charts are a huge part of their job. Management has to somehow measure and report on the progress beneath them so that they and their management can make decisions about what the keep doing, what to stop doing, new things to try, and plans to start making for good or bad futures. “Reports” are practically the only input management has to their job. In your organization, there’s probably a set of metrics (or KPIs) that your boss, your bosses boss, etc. are looking for. These metrics are used to gauge “how things are going,” but are also used by even higher management to judge how that boss is doing (and, thus, you). As someone trying to push Agile, you should learn what these metrics are and learn how to wangle in all the project management data you have into them. Treat that reporting as “story” or part of your iteration – track how much time you spend on it, the benefit it gives you, make it part of your iteration retrospectives and so on. To get all meta: reporting on the project is a key requirement of the project. (Thus, if it’s taking too long, you can track that and report to management and ask them how they’d like the weigh that time against other features.) Recently, the topic of “technical debt” has been an excellent, new metric to start tracking. Also, here, Israel Gat‘s The Concise Executive Guide to Agile provides loads of good input on “reporting.”
3. Isolate the resistors, and hope they drop-off – no matter how well things are going, there will be people who simply don’t want to go along with The New Thing. You’ve tried to reason with them and get them to see how great Agile is, but they still just don’t want to do it. When I was part of the Agile-at-Scale efforts at BMC (under Israel Gat), I was shocked that the most resistant people were fellow developers. They were so used to the way things had been and the fiefdoms they’d carved out that the fluid nature of Scrum caused them all sorts of problems. In general, you can get a sense if someone is a “team player,” or if they’re resistant. While the Machiavellian side of you would like to see these people fired, that’s often not as easy as you’d think in large organizations. In these cases, you should isolate these people (and their work) from the rest of the project. Essentially, you want to make sure The Stagnent Resistors don’t infect the your timeline, code quality, and moral. As I said at the Impact Unconference, it’s like what you do with a weird growth you find on a dog: tie a silk string around it, cutting off the circulation, and hope it just falls off eventually.

It’s getting a bit long in the tooth now, but my “smells of Agile” paper from several years back can be helpful for gauging how Agile your organization is: a sniff test, if you will.

Disclosure: IBM, who put on the Impact Unconference mentioned above, is a client.