How You Can Start Improving Your Software Process Today

Are you a developer who dreams about a better software development process in the organization you work for? Maybe you read something about fancy practices on your favorite blog or mayhap you even touched one of those old-style paper collections called books? Do you have some concrete ideas on how to improve, but don't know how to start? I was in the same situation a year ago. Here's what I did and what I would do differently today.



One of the big obstacles when trying to implement change is your own doubt. When you've still got some sense left you'll be very insecure about things you didn't even try yet. Perhaps you even mentioned your idea already to some team members or a project lead, but all you got is skepticism. This is the point where it is easy to give up. How can you as a mere team member introduce any big change without the full support of the team and your management? The answer is simple: you can't. At least not in one fell swoop.

For me doing nothing is not an option when I see the opportunity to improve. So how can you introduce a big change in small, safe steps and more importantly how can you convince your team members and management to try out your proposed changes?

First: How do you measure up?

The practice I expected to be the hardest to implement proved to be a fast-selling item: the story board. This is why I would aim for this target first. The story board will not only make your development process more transparent, it will also provide a simple process metric, your velocity.

To set up a story board is not that hard. Get a pin board, write your requirements and the predicted effort on small paper cards and pin all the cards you plan to finish within a fixed time (we use two weeks) to the board in a column headed "todo". Whenever you start to work on an item, move the card to a column labeled "in progress" and when your task is done (really done) hang it over to the other finished cards where it can happily indulge in self-display.

After a fixed amount of time you take all the cards that are finished and count the effort you managed to implement. This is your velocity. Simple, easy, and hard to game. If you want to learn more about it, there's an excellent article by Ron Jeffries about the metric of "running, tested features".

But wait, isn't measuring the software process what evil consultants do to make huge amounts of money by playing with fear? Yes, it is. Then again, no, it's not. It depends on what you do with the data. Metrics are a two-edged sword. You can use them to learn or to judge. Never do the latter.

Introducing the story board is not hard. I did it without asking anybody for permission. I just organized the pin board and started to pin up stories I worked on. It doesn't take a lot of time, so it's not too hard to get your team members to buy in. When you show your management that you finally managed to produce an easy, transparent metric they'll find it useful, too.

Second: The problem with problems.

If you want people to change you'll have to come up with a good reason. Change is never easy, so you have to convince people that you're going to scratch their itches. To identify problems and assets you can use a retrospective. Propose a meeting where you discuss what runs smoothly, what runs not totally perfect and how to improve. Try to get the commitment to do this on a regular basis.

This should not be to hard to implement, either. From what I've heard management people usually don't object to process improvement loop. And why should they? But what about your team mates? Do you think they will let the opportunity slip to vent their anger?

Third: The solution.

Now the really hard part begins: the actual change. The first two steps will make introducing the change easier since they provide a platform to introduce a change as a solution to a real problem and safeguard the change by measuring it's outcome.

The platform is the retrospective. Let your team mates say what bothers them. If your observation of your development process was correct, they'll bring up the same issues you already identified. After the rumble dies down, propose your change or set of changes as a possible solution. Now you have to face the storm.

But we have the velocity metric as a safe guard. Propose to try your improvement and see how it affects productivity. You can simply try it until the next retrospective and judge based on more experience than. This makes it easier for your management to support the idea, too, since it is clear that the final decision is yet to make.

Steering your development process.

If you are familiar with the concept of Test Driven Development you know the concept of steering your own design. The same principle is used in Extreme Programming on a higher level to steer the product features by the planning game. The key principle is that each day you gain experience and are able to make better decisions based on your expanded knowledge. Or, as Ron Jeffries likes to put it: Today is the dumbest day of the rest of your life.

Using a simple meta process you are able to steer your development process. Identify a problem, try a solution, measure the outcome, inspect what you learned. Redo from start. It's not easy. In fact, it takes a lot of work to keep yourself and your environment self-aware and open to change since people seem to avoid change - it always means risk and effort. But using the same methods I used it's not impossible, either. Taking the test driven way to process improvements will force you to make baby steps - sometimes you'll hardly recognize movement, and this can drive you up the wall. But I'm still idealistic enough to believe that those baby steps will sum up and in the end you'll reach the sun. Wherever that is.