6 May 2014
What Feature Do We Build Next? Our Approach to Software Release Planning.
by Doug Alcorn
Right now we’re documenting the entire software development process at Gaslight. One of the hotly contested subjects around the office is how to build a release plan for new projects.
Does it need to be documented somewhere? Or does it simply exist in the day-to-day interactions of a tight-knit team?
A project release plan is about identifying what features we’ll build and what order we’ll build them in, and it’s one of the possible concrete deliverables during the start-up and discovery phase of a new project.
I’ve heard members of the military say, “No plan survives initial contact.” And that’s true of development as well.
As soon as we start, we learn more about the problem and the technology we’re using. Being agile means we can adjust the plan as we learn.
So why take the time to plan at all if we know everything is going to change so quickly? For starters, release planning helps us build strong, trusting relationships with our clients. It gives us the chance to think through their entire project together and give everyone more confidence the project will succeed.
This initial release plan isn’t “Big Design Up Front.” It doesn’t result in a formal, set-in-stone document. Instead, we’ll often put our initial thoughts into project management software like Trello, which allows for easy changes and updates. Or map out the whole project with post-it notes on the wall.
Sometimes we’ll simply talk through release planning in our daily meetings with clients and never write it down at all. No matter where the plan lives—even if it’s just in our heads—we’re constantly deciding and re-deciding what to build next as we develop, release and refine features.
To me, sequencing features is one of the great arts of agile software development. It’s balancing several goals that sometimes conflict with each other:
• Building the most valuable features first. Ideally, we only build valuable features.
• Taking into account the risk a feature has technically (how complicated it is to build). We typically like to take on higher risk sooner.
• Focusing on the entire system. Without an initial rough plan, there’s a danger you will overbuild one area of the application and neglect another.
• Not allowing the immediate and urgent to overshadow the important. When we have a release plan, we can see how adjustments and reactions relate to the overall software system and project goals.
Ultimately, release planning is a balancing act that our clients actively participate it. We’re always trying to hit the sweet spot between planning and flexibility that allows us to deliver the best possible software for our clients.
Sometimes this means writing things down, and for other projects, it’s enough for the release plan to live in the heads of a tight-knit team that’s working side-by-side with the client every day.
Our approach to release planning is as agile as our approach to software development overall.
