Sep 7

Software Development Goals

The goals for your software development team should support your business goals. Sometimes there's a very clear connection between the two, and sometimes the connection blurs. It's been my experience that software development goals tend to change often while during the same period of time business goals remain constant.

Software is intangible and often thought of as flexible and easy to change, which it certainly is compared to its counterparts (e.g. hardware). When goals and requirements are changing frequently however, software can easily become brittle and difficult to work with (so-called technical debt).

Fortunately, there are ways to remain flexible in the face of changing requirements. Presented here are some simple things you can do with stakeholder buy-in to improve the situation, and failing that, some worst-case steps that might keep you from quiting your job.

The Routine Interruption

Jeff gathered his thoughts quietly in his office while waiting for Mike, the CEO, who would be finishing up with the 10:30 sales call any minute now. He expected to see Mike right after, at least that is his usual pattern when it came to calls with large potential customers.

Like clockwork, Mike walked into Jeff's office with a burst of excitement. "What would it take to make the portal parse Excel documents?" Mike asked, even though he had already made up his mind what the answer was. "That's not something we've thought about before, I'd have to talk it over with the team and get back to you," Jeff responded.

Mike didn't seem to like that answer, "I don't think it would be too difficult, and if we can get it done in the next week or so we could win over this new customer. It's worth a lot of money."

Having been the manager of the software development team for the last three years, Jeff wasn't surprised by Mike's request, nor his insistence. This was actually a rather regular occurrence, and one that impacted the ability of the development team to deliver what was already scheduled.

Thankfully, Jeff had already started down the path of solving this problem and began making changes to the software development process about six months ago.

Write Software Incrementally

There has been a lot of focus on software development methodologies during the past few years, especially those featuring incremental development. While there's no one-size-fits-all solution, with this specific problem incremental development can be very helpful.

Call them iterations, sprints, or whatever you want, but they should be short. Start with two week cycles if possible. That's long enough to deal with vacations and holidays, and short enough to be flexible in the eyes of your stakeholders.

If you're not already doing incremental development it will take some getting used to. It takes practice to break features down for each iteration so the development team is able to produce working and usable code. When the iteration ends there should be a sense of accomplishment, a complete unit of work is done, and the team is ready to start the next.

The short cycles also lend themselves well to measurement and adjustment. If you estimate tasks for an iteration in something like story points, you can calculate your velocity, that is, the number of points the team can deliver in a single iteration. Since velocity is based on the previous iteration, it's self-adjusting and once the team jells it will stabilize.

Velocity is great for iteration planning but can easily be misused as a measurement. In this case, Jeff will carefully use it to measure the disruption caused by changing requirements.

Create a Sortable Work Queue

If you're not already doing so, you should seriously consider a way to keep track of what the team is working on, and what they need to do next. You usually break all work into three categories:

1. The pool of all work that isn't scheduled (a so-called backlog)
2. The work that is scheduled for the current iteration
3. The work that will be done in the next iteration

It should be easy for stakeholders to reorder the upcoming work based on the priorities of the day, add things to the queue, and otherwise have a view into what the team is doing. Think flexibility and visibility.

The hardest part is figuring out how you're going to make it available to the stakeholders. Whether it's a bug tracking system, a wiki, a whiteboard, sticky notes, or 3x5 cards doesn't really matter as long as people actually use it. After the newness wears off, if stakeholders stop using the system then you don't really have a system at all.

Solicit Buy-In From Product Stakeholders

"Mike, let's put the Excel parsing to the side just for a few minutes, I'd like to talk to you about something," Jeff said. Mike stepped out of the doorway and sat down in the chair in front of Jeff's desk.

Jeff continued, "Back when we switched to working in iterations I started to collect some measurements and performance data before and after each iteration. One of the tools we use for planning the iterations is our velocity. Basically, it's a number that tells us how much work the team can do in one iteration. Here, look at this."

Jeff turned his monitor so Mike could see the graph that was displayed.

"I remember you talking about velocity before. So this shows that for the last few iterations the team has been able to finish 34 story points, right? This graph looks pretty stable," Mike said as he turned from the screen back towards Jeff.

Jeff had a confession, "It's not an entirely accurate graph though. The iterations haven't actually been that stable. I averaged out a few bad iterations to show you what it'd be like if we did have a stable velocity. Here, this graph shows the real data for those iterations," Jeff brought up another graph.

Mike was confused, "Alright, so what's wrong with those iterations?"

That's just the question Jeff wanted to hear. He knew that he had to present the case in a way that would get Mike emotionally attached. It might have been a bit of a bait-and-switch, but it worked.

Jeff tied it all together for Mike, "At some point during each of these six iterations the development team was interrupted when we decided to change what was going to be done for the remainder of the cycle. That usually means we have partially finished work returning to the backlog, and some lost time while we plan and shift gears."

Mike knew where this was going. Jeff continued, "The reason we interrupted the iteration was to squeeze in some features to help make a sale. During the last six months we disrupted six iterations, which resulted in two additional sales. Based on what we could have done during those iterations, I figure we lost just over $10,000.00."

Before Mike had a chance to interject, Jeff sprang his proposal, "I have an idea of how we can stay flexible and also keep disruptions down. I'd like to do two things with your help: 1) agree to not interrupt an iteration, and 2) actively involve you in the planning of iterations."

Jeff took a breath and then put the final bits in place, "If we can delay changes until the next iteration starts, we can keep our velocity stable. If something urgent comes up, we usually only have to wait about a week before we can start working on it."

Mike had the feeling his hands were being tied but Jeff made a compelling argument. Mike looked at the graph again and then said: "I don't want to lose the flexibility I have right now, but let's give it a shot and see how things work out. I'll expect you to keep this graph updated and go over it during the management meetings."

I walked right into that Jeff thought, but if this works, it will be worth it.

When All Else Fails Call Batman

Things don't always work out so nicely. Before you throw in the towel, here's something to try as a last ditch effort: assign a batman.

The idea is to have a developer on stand by (not working with the rest of the team) in case an urgent change rolls down the hill. Since this developer isn't working on the critical path, the team doesn't get disrupted with change. To keep your developers from quiting on you, rotate out the batman with each iteration.

The hardest part of this solution is trying to figure out what to do while no changes are pending. It's probably best to keep the batman working on something light and easy to interrupt. Documentation, refactoring, and writing tests are good candidates.

Key Points and Alternatives

Let's close with some observations on how these ideas can be customized for your environment, and some precarious boundaries:

• Feel free to play with the length of an iteration. You might have to shorten it to a single week, keeping in mind that just one business holiday will reduce working time by 20%. On the other end, moving to iterations longer than four weeks greatly reduces flexibility.
• Iterations must remain uninterruptible. You'll have to provide the push back when stakeholders want to change something midstream. Of course, you have to be flexible if a real emergency presents itself.
• It's tempting to use software for your sortable work queue, but be wary. I prefer a physical system where I can actually see stakeholders moving things around with their hands. The added benefit is that something like 3x5 cards will cost $4 and take 10 minutes of work. That said, software might be the only option for geographically distributed teams.
• Incremental development is the key to making this work. If you have better ideas on how to keep the team's cycle synchronised and interruptible, I'd love to hear them.

On that note, if you have something to add or something you disagree with, you should post a comment and start a discussion.