Yesterday, while discussing a particularly difficult team-energy kind of problem, something led me to identify their methodology as “faith-based.” Everyone laughed, and they immediately got my point. Faith in a process is really no way to run a development shop.
I’ve been working on so many offers and new ideas that the blogging hasn’t quite kept up. So right now, the floor (and comment section) is yours. What are your thoughts on software development, Agile practices, and Projects That Suck™? Anything I haven’t covered? Technical or process questions?
It’s time for a conversation. Who’s in?
As a possible starter… affirm, deny, or qualify the following statement: “The cost of adopting Agile development methods is primarily not paid in cash out of pocket.” What do you think?
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.
Wow. I haven’t been this grumpy about business in years.
It all started a few weeks ago when a mutual friend introduced me (virtually) to this fellow I’ll call Ben. Ben had a Project That Sucked. As you know, Projects can Suck in infinite different ways, and this one was considerably less sucky than most. Mainly, Ben’s client had been expecting a new commercial website that was a bit late already, and Ben’s PHP guy had just left for a cool new job out of town. And there wasn’t really that much to do to finish the site.
Ben got in touch with me about this just about a week ago.
It was one of those classic “90% done” issues. Seen it a thousand times. Shouldn’t be that hard.More
Last night I had the pleasure of hearing Jon Stahl‘s introductory presentation on “Agile Explained” at a joint meeting of Cleveland IEEE and the Firmware Engineers of Northeast Ohio. The lighting was not so good for picture-taking on the LeanDog boat, so sadly there are no photos to share.
It was a nice crowd, although I’ve got to say one of the least diverse I’ve ever seen even at a technical event. Being mostly hardware and firmware engineers, they were skeptical about the idea of continuous deployment to production for obvious reasons; the guy sitting across from me used to design circuits for pacemakers! But they asked excellent questions, and in true Agile style Jon gave them The Simplest Answers That Could Possibly Work.
I’ve been thinking a lot about Victoria Brouhard’s recent blog post on “no-brainer” decisions. It’s a clever idea. When you’re trying to decide about accepting something like a job offer, ask yourself, “What would it take for me to say hell yeah?”
In other words, how would you change the offer–if you had the power–so it becomes something you couldn’t imagine rejecting?
I was quite interested in Peter DeYoe’s recent blog post comparing Agile development to the P90X fitness program he just started. Riffing off the slogan “Decide, Commit, and Succeed,” DeYoe winds up with
Decide if Agile is right for your organization. Commit to the principles of Agile and deny your urge to fall back on old habits. And if you make it to the third or fourth sprint, a new, healthier paradigm for software development fitness will emerge and lead you to Success.
I like it! But I have a different model for Agile adoption, which is highly influenced by the life example of my darling Drsweetie.