How Does An Agile Product Team Fall Into The Big Bang Release Trap?
Agile? Waterfall? Or caught between both? Far too often I have seen product teams trying their best to work to regular releases, but end up being governed by a traditional project framework — culminating in a big bang deliverable (where the product has one big release of as many features as possible).
Big Bang releases almost always end badly, with a myriad of post live bug fixes and fire fighting UX issues from customers.
How does this happen? Why is the big bang release favoured over incremental enhancements to a product? Here is what I have experienced working as a digital product manager in traditional organisations:
“Project” Governance Is Still Mandatory When Working In Agile
Product and Project culture collide in organisations that have a traditional Project Management structure. Agile-based product developments must be presented and signed off by a project board (in most cases the board cannot be bypassed).
This situation demands flipping between the role of a Project Manager — producing lengthy documents, project charters and weekly status updates, to managing the day to day work as a Product Manager — working in an agile customer-centric way with designers, developers, testers and business stakeholders.
Trying to squeeze agile epics and stories into fixed-date project milestones defeats the purpose of agile delivery.
Product teams are forced to stealth-release features incrementally, without customers (and sometimes management) knowing. This can be the only way to work in agile and satisfy the traditional project structure that is in place.
Senior Execs Select A Random Delivery Date That Is Fixed
When launching a brand new product or developing new features, these can gain visibility and become high profile within an organisation. As a result, senior execs can often stamp a release date on them and publicise this to board members, making it hard to back out of the delivery date.
Setting a firm date forces a project timeline approach, with a heavy focus on development and little time for an iterative approach to testing and customer feedback.
Compromises are made to get the product over the finishing line and the big bang release often paves the way for a “phase 2” project to fix known bugs or add features that missed the deadline.
Big Bang Releases Are Perceived To Be Better For The Customer
In less innovative organisations, being a Product Manager can be an uphill struggle. Cultural changes are required to embrace agile ideas such as fail-fast, test and learn approaches, being customer focussed and understanding real problems that need to be solved (rather than solving perceived problems).
Traditional organisations see change as something that should happen as least often as possible, making incremental changes quite unsettling.
A big bang product release is perceived as being good for the customer for the following reasons:
- Communications to customers are sent in one hit, minimising the risk of backlash (in reality the disruption caused by the big bang release is far worse for the customer).
- Internally gearing various teams up for one set of process changes is deemed more efficient than an incremental test and review approach (however with significant change all at once, internal teams suffer and human error increases).
- Customers don’t like change, so one big bang release will be less painful (wrong! If change is done right and solves a real customer problem, then change can happen as often as necessary to improve the product).
Trying to work against these misconceptions can be challenging. Do not lose hope — there are a few techniques you can use to help change the mindset and approach of your peers.
How To Avoid Big Bang Releases
As early into the product lifecycle as possible, attempt to steer clear of a big bang release by trying the following:
Iterate and Demonstrate
Regardless of being forced into a waterfall structure, design prototypes, get user feedback and showcase the results to senior management. By doing this you are leading by example showing how iterative and quick development followed by feedback can make a better product.
Competitor Landscape
With some research, it is easy to find competitors that are adapting to an innovative approach (like most successful start-ups). These are great examples to demonstrate to your peers about agile and iterative releases leading to market leading products. Dive deep into these organisations and learn about their culture, the agile processes and how this has transformed their products.
Cultural Awareness
Be the Agile advocate your company needs, demonstrate qualities of agile thinking. Hold sessions or workshops on agile methodologies and show the results of your agile work. By gaining a following and identifying influencers in your organisation, you can help stop unnecessary big bang releases.
Final Thought
As a Product Manager remain true to your product and its customers, release frequently and ensure customers are delighted with every increment. Avoid confusing big bang releases that leave customers disgruntled or with a steep learning curve due to the number of changes. Remember a Product Manager’s goal is to help make people’s lives easier.
