Do what you gotta do. When you gotta do it. And not a moment sooner.

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.

Come to Notacon!

I’ll be speaking on Why Your Software Project Sucks (and how to make it not suck) at Notacon, April 15th to 18th, at Cleveland’s Playhouse Square. Tell Froggy I sent you!

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.

5 thoughts on “Do what you gotta do. When you gotta do it. And not a moment sooner.”

  1. I usually implement exactly those three things first when I introduce agile to an already sucking product. It’s really great to see how many bugs get caught by pairing, how communication between team members suddenly starts again triggered by the daily stand-ups and how the visibility created by the information radiators shows bottlenecks in the process (e.g. overwhelmed testers).

    I would add one more thing to the list: Sorting all requirements into a backlog. Get rid of priorities like 1a bold, red, blinking and decide, what shall come first, second, third, etc. This really forces the gold owners to understand that they cannot have everything at the same time.

  2. That’s a really good idea, Matthias. I’m turning this technique into a full four-week program, a service you can actually buy, and Week 4 is sort of open to whatever needs the first three weeks uncovered. By default, though, setting up a Product Backlog and a Task Backlog might be the best Week 4 activity. They’d feed naturally into the Daily Scrum and at that point you’re halfway to having a real Sprint mechanism.

    I’m trying to avoid just handing people a whole methodology and saying “Here, you got Scrum.” They’re behind schedule and they don’t need to spend time on “methodology,” even a relatively simple one like Scrum. What they really need is to grab the easy wins first so management calms down and regains some trust.

    Trust is a big deal when Projects Suck. Often, it’s impossible to “sell” what you and I might know to be the best solution if it doesn’t make things visibly better really really soon. Let them see some results first and then rely on their faith in more.

    Anyway, yes, I like the idea of doing a backlog next.

  3. Mark, I fully agree with not handing over the complete package at once. And maybe it’s best to assume that the people know at least what they are doing. Just getting it done is the problem. Then your approach is perfect.

    I just have seen it too often, that the execution was less of a problem than the scoping of the work. More than once I came across a product owner who just slammed a great team with plain stupid requirements and the biggest part of the problem were his expectations that everything gets delivered at once. In such a case introducing a backlog might help more than the other things.

    I guess, it heavily depends on the situation in the project. I really like your approach and I think it’s a great idea to offer it as a real product.

  4. Don’t do thinks you don’t “gotta do” so that you have more time for the things you do “gotta do.”

    Many agile developers do get their most important things done when they need to, but they are lazy prioritizing the left-overs.

  5. I don’t remember who first put it this way, probably Ward Cunningham, but there is no such thing as doing an unnecessary task early to “save time” on it. You can’t save time. Time goes by. If the task becomes necessary then you do it. If it’s not necessary you don’t do it. There are always more necessary tasks to do than you have time for anyway.

    The definition of what’s “necessary” changes depending on your goals and the path the project takes, but it’s always important to stick to necessary work.

Leave a Reply

Your email address will not be published. Required fields are marked *