Preparing for releases is like preparing for a big party. They take a lot of work, no one will ever understand how much you did in order to make it happen, and you never really know how well it will be received until you actually release the product or throw your party. Managing your budget, resources and time are the basic best practices for any project. Great communication helps too. Is great planning enough? What sets a great release or party apart from a good release or party?
In this blog post, I’ll stay on the topic of creating a great release. I will defer to the party experts to share how to prepare and throw a great party.
Here are some of the best practices I have learned along the way. Some of them came easily and some of them I had to learn the hard way through trial and error.
Manage your time, resources and scope
Understand the problem your are solving
Have a clear measure of success especially knowing when you are done
Listen to those closest to you but also get feedback from users truly using the product
Manage your time, resources and money – Most planners are comfortable with managing time, resources and money especially those that are trained in project management. It should be easy to do, right? It’s not actually, especially for software development. The challenge with managing and building software is that there is always a battle between getting to the known so you can scope it and balancing the risk of the unknown so you can mitigate for the unknown. You want to know everything at the start but it’s more typical that you do not. Over the last several years we have seen a trend in our industry requiring everything up front to requiring less up front. It’s a move from waterfall to agile processes. This shift in managing projects puts more planning and design at the implementation phase and therefore in the hands of the implementers. This is actually a great thing to do. It does add more risk to the management of the project though. A good team can mitigate this risk. It allows the team to adjust to insights as they are gathered and refined. If done right it can help better define a great user experience. You will need to manage the risk by making sure any changes to resources, time or scope are communicated throughout the project. Making timely decisions is crucial to the projects success.
Understand the problem you are solving – Once you understand the problem you can solve the problem. This is my favorite rule. If you do not understand the problem you will spend lots of time designing things that will never be used or completely miss the mark. Adoption is what makes great software. Real, tangible user data is required to deliver a great feature. You will need to watch users work. Gather work processes, impediments to their current processes, and define a process that meet user’s work patterns and also reduces hassle. We use a process called Contextual Design to help us make sure we are delivering on our user’s needs.
Have a clear measure of success, especially to declare when you are done – Requirements help. Designs help. Architecture help. Using your requirements, design, and architecture does help you to know when you are done but the option to do more on your software project never seems to end. You can always put more in a feature, iterate through a design to find better ways to deliver the feature, and determine better ways to optimize the platform. The true test is to confidently declare when you can be done. Everybody needs to believe it. We have a list called “definition of done”. Some of the items on the list remind us that we need to be scalable, high performing, global, enterprise worthy, follow standards for accessible design, reach quality goals and regression coverage. This list helps us to manage the “go/no go” decision process and help everyone to be confident that we can release the product.
Listen to those closest to you but also get feedback from users truly using the product – Assuming you have achieved what you wanted to achieve and are actively measuring what it takes to succeed, you also need to actively listen to your users during the validation process. This is your chance to smooth out the rough spots. Work through those closest to you at the start of the validation process. As you fix and adjust to the feedback, expand your user base. As you expand your user base, you get a different kind of feedback. This type of feedback helps you to continue to smooth out the rough spots and to refine your release. Without it, it is easy to convince yourself that you are ready. Balance the feedback with your requirements and user stories. Then balance the feedback with your definition of done. If you have done all of them well and can still meet the intent of the release, you are good to go.
Okay, now that the easy stuff is done you are ready to throw your party.
What are some of your favorite tips for creating a great release? Please share them here.