Kicking off a software project successfully is no small feat. At Umbrage, we really strive to set the tone for success before the development work even begins. We make sure we have the right people in the room and that we utilize the right types of research to align on our goals.
It’s only once those first two steps are done can we move forward to the real work. For our software product teams, that means it’s time to “Get Dev Ready.”
Ready, set, code
We use this phrase a lot at Umbage. “Getting Dev Ready.” It means a lot to us. It’s a heavy statement to us. There’s a lot of intense and intentional work, often several weeks, that goes into it. And we’ve learned a lot about how you can do it well and how you can do it not so well.
But what we mean by “dev ready” is this: building a project backlog for your software development team that provides at least 4-6 weeks of groomed, prioritized, and story-pointed work that has been validated with business stakeholders as the right and valuable work for the team to focus on when development starts.
This is where we want most projects to be. We want to start development with a solid backlog of work that we can use to populate our sprints. And we want enough of it to provide a runway where as things come up, like assumptions we didn’t catch early on, or data or other technical dependencies, or late-game revelations by stakeholders about what-is-actually-important, the team has that runway to pivot and be flexible while still being productive, and while the rest of the project team (product manager, scrummaster, designers, stakeholders, etc.) continues to evaluate, adjust, and refine the backlog.
Being agile shouldn’t mean you don’t have a backlog
Iterative software development teams should just… iterate, right? But like many things in life, you get out what you put in. So it’s very important that when you kickoff a new software project, you have a validated backlog or a pretty damn good and well-articulated idea about what you want to build. And then some. Your development team is going to be asking, “What do we do now?” followed by “What do we do next?” And a validated backlog answers those questions now and for the upcoming weeks, and it continues to answer those questions if you take care of it.
If you’re finding yourself in a place where you don’t have a runway, if you feel like your developers or your software product team is spinning its wheels, then take a closer look and read between the lines. Nine times out of 10, we find that it’s often not enough quality backlog, or some aspect of creating and curating the backlog that is not getting enough TLC, whether that’s designing UI and defining stories, validating and prioritizing those stories with stakeholders, grooming and estimating them with development, etc.
Your backlog is your thermometer for project health and overall delivery. Garbage in, garbage out. But if you put good things in, you’re likely going to get good things out. It’s like software alchemy. If you throw a bunch of poorly defined, misunderstood requirements into a bowl, you’re probably going to get the same out of the bowl. But if you really work at it, take care, and have a good grasp of what you put into your backlog, you can very well make lead into gold.
The best tool we’ve found for achieving and maintaining a healthy backlog are the things mentioned above and in the past couple of posts in this series. A strong, user focused-project kickoff followed by collaborative activities that help us quickly understand the user we are building for and what those features will look like. At Umbrage, we call this our “Define and Design” phase of a project and it’s the best way we have found to “Get Dev Ready” and quickly mobilize a team toward building quality, valuable software.
Discuss. Design. Define. Validate. Prioritize. Estimate. Plan. Develop. Demo. Iterate.
If that sounds interesting or appeals to you on some deep, emotional level with challenges or situations you are experiencing on your own software products you are working on right now, then hit me up. Let’s chat and I can tell you a bit more about how we do it at Umbrage and the things we have found that work well for producing great software experiences.