The Problem

If you’ve ever had a software development project done for you, you’ve probably personally encountered a “Project That Sucks.” The code is late, and when it finally gets done you find too many bugs. The program might have less than the functionality and value you were promised.

The development team swears it will all come out in version 1.1, but you ran out of funding already.

Meanwhile, the smart people who are supposed to make this all work are stuck in meetings when they should be, you know, making it all work. The developers themselves have been on it for long hours and weekends. They’re tired and no longer doing their best work. Maybe the project manager is even drinking more than usual. From what you can tell, the team is full of sniping, backbiting, blaming, and defensiveness.

As an executive, you can’t even tell what’s going on. You’re relying on technical people for time estimates, but they keep changing and you’re not sure how to interpret them anyway. (And what is “80% done” really?)

What doesn’t work

• Exhortation, incentives, and threats only help if your team isn’t already doing the best they know how.
• Firing people and starting over would make some kind of sense if you hadn’t already hired the best people you could find. And starting over means acquainting a whole new crew with the goals of the project and your existing resources. This is very unlikely to move things along faster!
• Accepting small schedule slips makes sense when the causes are small and immediate: a key person is out sick for a week, you’re waiting for a decision from the board, things like that. But when work is simply grinding, a small schedule slip won’t compensate.
• Accepting large schedule slips at least recognizes the reality that your project is in trouble. But it doesn’t solve anything!
• Having more status meetings is the worst idea of all. Even when the developers are not personally invited (because you need them on task) they are repeatedly taken off task to provide all the details that get fed to management. It’s not like team leads and project managers know this stuff automatically; they have to ask developers whether it’s in meeting or out of meeting. Still a waste of their time and momentum.

Finally, all that pressure makes things opaque. When the software project is going this badly, almost everyone has a very understandable tendency to cover up missing details, to estimate optimistically, and to be vague about the hard parts. So all the reporting is compromised anyway–it’s the “You can’t handle the truth!” moment applied to our world.

The solution you can’t have

Regular Critical Results readers surely know what I’m going to praise as a solution. But you can’t have it quite yet.

What you want is a truly Agile development scheme. The underlying philosophy of Agile is to glide with the way people actually work and to adopt practices that are proven to get defect-free software finished rapidly. But Agile is a huge cultural change for an ordinary technical workplace, and to be perfectly honest many people are not emotionally cut out for it. Not at first anyway.

And Agile methods tend to undermine the superficial trappings of authority you see in regular IT shops. When your team is really truly self-directed, the first thing one asks is why managers are needed at all! Now that’s a misreading of what Agile actually does, but it still freaks people out at first.

When your project is in trouble, you don’t have time for the freaking out.

What you can have… now!

Introducing Emergency Agile.

It’s a few very easily adopted and immediately effective Agile practices that combine to cut defects, speed development, create transparency, and let everyone feel better about doing their best work.

You can implement this in one month and actually see positive results within the first week. (I swear this is not a diet pill or a baldness cure.)

Pairs to open

The very first thing you can do is start pair programming. At first, yes, it slows things down a bit because you’ve got half as many keyboards going on, but the momentum builds like crazy and you’ll soon find that two programmers get… oh, about one and half times as much done as a single unpaired programmer. Which doesn’t sound so good, as it’s still at 25% loss, but when taking into account a sharp decrease (which always occurs!) in defects you will definitely come out ahead. By the end of the week.

Note that pairing goes a lot better when you start with someone who has done it before.

Second thing: ask three questions

The next thing to add is the most visible (albeit incomplete) implementation of the Daily Scrum meeting. (Again, it’s best if you start with someone who’s actually done Scrum before.) Very briefly, you start each workday with a meeting in which each team member answers the Three Questions:

• What did you do yesterday?
• What are you doing today?
• What could possibly hold you up?

That’s it. The key is to keep the meeting very short and use it only to make an agenda for the Scrum Master, who often  spends most of the day resolving any Third Question issues. That way developers get to do what they do best.

Very importantly: this is the only reporting developers and testers will do except for possibly updating a Scrum-like “burn chart” if you have one. That’s right, they need the rest of the eight-hour workday to do their development and testing. Do not interrupt them for anything.

Now in this stripped-down, not-really-Scrum setup, the Scrum Master is likely to be a development team member too. I didn’t say this is a pure implementation!

Radiate some heat but more light

The third very quick and easily understood Emergency Agile practice is not as well defined, but very important for giving management a realistic sense of security about things getting done and for providing your development team a constantly helpful status display.

It’s the Information Radiator–any kind of display that is easily visible without your having to go looking for it. A lot of well-developed Agile shops, for example, put up Kanban boards (which is kind of redundant because “kanban” is Japanese for “signboard”) to show what tasks are in the various active and waiting queues.

While setting up a true Kanban system isn’t always the right answer when you’re already late, you might choose to display a simplified task queue. You might arrange defect summaries on a big board of color-coded Post-It notes. You might even display a big visual mockup of the whole system with notes and color codes indicating what parts have completed testing, or where the defect hot spots are.

There are so many ways to do this. One goal among many of the Information Radiator, though, is to give your Project Owner (management or customer) the ability to walk right through the work area and get a very realistic sense of how things are going and what the priorities are. When the dev team is using the very same artifacts to do their work as management is using to view the work, confidence increases automatically. It makes the team the proverbial “open book.”

Yeah, guess what?

Emergency Agile takes a lot of trust, and when a software project is already going badly trust can be hard to muster. That’s why I emphasize the openness of the Daily Scrum meeting, the face-to-face cooperation of pair programming, and the blunt reality of Information Radiators.