Skip to content

Developers: frantic to free in 6 easy steps (part 6)

2011 January 31

This is part of a series of posts chronicling my team’s adventure in making release day suck less.

Note: I would highly recommend giving each of these a shot in a way that fits your team. I would also recommend trying to implement each one at a time. If you spend time focused on each step, tweaking where there’s pain and adjusting to your team’s personality you’ll find everyone owning the end result. You’ll also show them you don’t know everything and need their help figuring some of these things out, which actually helps build a stronger team.

Here’s what we did, pretty much in the order in which we added them to our process:

  1. Unit testing
  2. Code review
  3. Continuous integration
  4. Daily stand up
  5. Iterative requirements gathering
  6. Lightweight develop/test/release process

6. Lightweight develop/test/release process

This is where a lot of companies go wrong. In my experience, small companies start off whipping code out as quickly as they can in a dead sprint toward “break even.” Once they have a few accounts and some large “we can’t afford to lose this account” accounts, small shops start to feel big. Or at least they start to feel the pressure to ACT big for those big accounts.

When that happens, we hire projects managers, set up a PMO and implement some big-name process. In my earlier days it was RUP, and that thing killed the project I was on. Not that RUP or any sort of process is bad — on the contrary I’ve become a bigger believer in process lately than I was after that experience — in this case, the Devil is in the details. It’s all about how you implement that process. RUP has so many artifacts and UML diagrams and process steps it’ll make your head spin. But rarely does every company need every step, every artifact, or every diagram. Implement what makes sense as it makes sense.

Take a minute to let it sink in. Say it to yourself out loud.

If you’re looking to implement a process for your team (heaven forbid this series of posts has inspired anyone), take another minute to think about it.

As I mentioned at the outset of each one of these posts, “here’s what we did, pretty much in the order in which we added them to our process.” We didn’t do all this at once; we added what made sense as the next step as we felt the pain from our lack of process. When we saw something broken we fixed it, and ended up where we are now.

So how did my team define “lightweight?” We went for the bare essentials that met our end users’ needs, allowed us visibility and timely communication for a release, and didn’t eat up developer time:

  • Release once a month – this provides regular, expected communication and feature enhancements to our end users. They know we will put something in their hands the 3rd Sunday of every month. They know three weeks prior to that they will receive an communication detailing the features in the release.
  • Branch code from trunk per feature – this is then merged back into the trunk when complete prior to branching for the next release, which is next in my list. This provides our developers isolation in which to work, demo, and test out features without inundating the rest of the team with code churn.
  • Branch code from trunk per release – this provides bug fix isolation, and keeps us ready to release fixes or enhancements at any time.
  • Business owner involvement – We start early by using mockups to make sure we’re on the same page in terms of requirements. We convert those mockups into code and regular review meetings with the business owners, then have them test it at the end, approving it for release.

There are some other items in there, sure. But I won’t bore you (more) with all the details — these were the highlights that have really saved my team when it came to getting things done that our end users wanted. After just over a year of applying, tweaking, and re-applying the concepts in this series, we’re in MUCH better shape than we were.

One important thing to take away is that this is not a series of things I thought would be useful and applied to the team. This was a conversation with end users, business owners, and most importantly, team members. Anywhere that we interacted and felt pain, we tried to figure out the easiest, whatever makes sense now, approach to easing that pain. For the most part we’ve been successful!

No comments yet

Leave a Reply

Note: You can use basic XHTML in your comments. Your email address will never be published.

Subscribe to this comment feed via RSS