The incremental-iterative approach does not work without increment. Modern product development requires creating an increment that involves regular releases, including demonstration of new functionality developed during regular iterations, and final version, which will see the world.
The official Scrum Guide talks about the fundamental principles and framework elements for agile product development. Still, you will not find detailed instructions or techniques to guarantee a successful release. That’s why companies turn to experts in Scrum, often to save a sinking boat, patch holes, or just find out what’s wrong. Many scrum professionals would admit that the reliable release strategy is a weak link for many organizations. We are often in a situation where Agile cannot help with straightforward recipes but instead gives a direction.
The challenge is not in misunderstanding the place of release in the iterative-incremental approach but in the lack of a release strategy. By strategy, I mean meaningful, conscious actions aimed at ensuring regular product releases, despite the temptation to plunge headlong into process operations.
The key to successful releases:
- Awareness of the product goal
- A team that can achieve it
One way or another, the lack of a release strategy is really one of the most problematic areas in product development today.
Increment Without Release
It is not difficult to detect a time-lapse mine in digital product development when an agile team is building an increment and not releasing it. Most developers are quickly immersed in the process. In fact, this is their advantage and strength – to focus on development to create a product increment. Iterations involve concentrating on the process, and for this reason, the product release somehow does not reach the real users!
Obviously, most programmers do not think about presentations, demonstrations, or communication with the end-users. Developers are unlikely to worry about release whistles and bells, such as choosing the best day and time, place, and audience. Testers, designers, and programmers have not studied how to organize release events. However, the lack of details in the release strategy is a boomerang, and it is a matter of time before it returns to knockdown.
Failing Release Event
Let’s recall the infamous case of Elon Musk, who hurried to surprise the world with electric pickup Tesla Cybertruck. A presentation of a miracle car took place near the Space X rocket workshop in Los Angeles. The ideological inspirer and founder of Tesla boasted of its futuristic design, especially the body made of the same steel as the SpaceX Starship!
After a long-distance test, Ilon Maska’s assistant threw a significant steel bearing into the glass, and it shattered in front of an enchanted audience. Elon obviously didn’t expect that his “transparent metal” that should withstand the blow of a shotgun would be crashed in such an easy way.
It was not necessary to throw the second bearing. Still, the intrusive assistant did his duty honestly – he hit the second window. Now Cybertruck had two cracks. If the assistant was given the third ball, he would definitely hit the third window! The initiative was intercepted by the founder of Tesla.
Elon tried to get out, to find some positive in the broken electric car. At the same time, marketers reassured him that the case allegedly attracted the attention of the public. No matter how skillfully the big dreamer covered himself with fig leaves, the release failed.
Something similar is happening in software development. However, IT releases do not attract as much attention and sympathy as electric car manufacturers. Maybe we just haven’t learned to make noise around the software increments.
The conclusion is obvious and straightforward: you need to prepare well for the release in advance.
Varieties of Releases
There is a variety of releases:
- Major vs. minor
- Value drop for beta testing
- A/B testing
- Live pilot vs. official large-scale
- Releases by stages/levels
- Continuous deployment
In the modern Scrum entire team, including Developers and Product Owner can create an effective release strategy. Product Owners can describe releases as big or small in terms of the complexity of the increment. Still, only developers will know the degree of complexity. Simple functionality unexpectedly can impact the entire solution, which could lead to release strategy changes. Disappointed stakeholders would just shift an official date for the large-scale rollout, but why not just swap the character of the planned release instead? The team can roll out the same release, but rather for the live beta testing, which can de-risk the delivery of the complex changes.
Test releases. Such a release is on a staging environment, which is adapted to the realities of production. Here, the presentation of the release takes place in a narrow circle of testers themselves. It will require a small group of qualified engineers with prior knowledge of the application and business domain to push parallel exploratory testing all day long.
Pilot releases. The release is no longer on a staging environment but in the environment of an actual product infrastructure. The increment is delivered to a small group of five to seven users willing to try out the new application as part of their daily jobs. Extensive use of the released application by a smaller group of real users can gain more confidence to roll out your product to the bigger group.
A/B testing. This is an essential type of release, relevant when comparing new and old versions of the product. The audience is divided in half, giving feedback on the old version and the new one. The goal is to gather valuable information promptly for subsequent iterations, improvements, optimizations, or other purposes. The questions asked in the A / B testing process may be: “Is the new version really better than the old one?”
Large-scale release – for a large audience.
Releases of intermediate increments. The release itself can be important for developers, not impress the general public. New functionality can work in the background. Developers can silently monitor the system logs, which would be impossible to collect in an isolated testing environment.
Official – provide a demonstration of a product in the presence of officials. Official releases should be stable with proven quality achieved in the previous stages.
Other releases – by stages/levels, etc.
Who is responsible for the release strategy
Previously, the release strategy was determined by the Product Owner and only him. As Scrum evolved, it became clear that the individualistic approach for release planning was problematic. After all, one person can make mistakes, get tired, be guided by individualistic ideas that do not always keep pace with the team or stakeholders.
In today’s Scrum, the entire team is responsible for developing the release strategy.
The crucial role in this matter is played by the Scrum Master. He will not make the final decision because it is the prerogative of the management and the team. However, he will do everything for a masterful presentation of the increments as potential release candidates, eliminating misunderstandings, and promoting consensus. Someone should create an environment for honest expression of doubts and enrich the discussion with the experience or expertise of different team members.
It is important to note that the scrum master does not organize a working group for release management. Its emergence should be the result of a mature self-organized scrum team. The scrum master should facilitate the release planning process, ensuring that collective decisions have achieved the outcome.
Therefore, the entire scrum team is responsible for organizing the releases.
Examples
Here is an example of a successful release. Ukraine has recently created a platform that gives an API to access a public register of politically exposed persons (https://dataocean.us)
The product presentation was attended by supervisors of banking institutions and insurance companies, who had the opportunity to ask questions and see for themselves what data the system could provide.
At the public presentation of the DataOcean release, stakeholders asked, “Can the system search by tax ID?” The product owner replied: “Not at the moment because the current legislation does not allow it. But there are other ways to identify a person, so we will demonstrate new functionality and additional criteria for identifying a person in future releases. We have now come together to show you two features of the product: the search for declarations and the analysis of public relations of a public person.”
Undoubtedly, the developers of DataOcean had a clear release strategy.
Automation of Mortgage Valuation
As you know, financial institutions have a rather complex system of data acquisition worldwide, in many cases too bureaucratic. This creates inconvenience for ordinary citizens and a big problem for businesses.
I had the honor of fruitfully cooperating in creating the digital solution for the valuation process, one of the mortgage valuation IT companies.
The developers faced a difficult task. It was about a user-friendly interface and automated data processing, creating separate evaluation tools, and many other nuances. Different teams developed different components simultaneously, which did not make product development more convenient. How to plan a release in this case?
If one person (for example, the Product Owner) was planning the releases, it would not be possible to count on something worthwhile. Only teamwork helped all participants to constantly remember the purpose of the product and systematically release it. The unnecessary was eliminated in time, and the really useful was added.
As you can see, the release of digital products is significantly different from the releases of Ilon Mask’s car. The development of information technology usually involves a variety of multi-purpose components. In complex products, each piece may be a different platform that serves a separate category of users! They all need to be integrated and adequately tested before talking about a stakeholder demonstration.
Recommendations
To create a successful agile release strategy, you need to:
- A clear understanding of what the business wants
- Decide with the team exactly how to adapt the work to consider the business’s needs, requirements, and expectations
- The depth in the release plan. Premature demonstration to a broader range of people involves too high and even unpredictable risks. Hence the first release can be done in a small pilot group (2-3 active users). We remember how the global car manufacturer Volkswagen AG had to recall about 500,000 cars from the US market due to certain defects related to the negative impact on the environment. They hurried to release “on time”, with “fulfillment of the technical task in full”. Still, They did not attach importance to regular testing and previous releases with the appropriate conclusions. Volkswagen could allow this, but for most IT, negligence in testing and release depth would mean the company’s self-destruction.
- Involve different team members in planning releases who may be directly involved: key developers, testers, product owners, analysts, information security professionals, and others.
- At the same time, do not forget about team building – synergy between all its participants for the better realization of the product goal should be facilitated by the Scrum Master.
- Allocate one hour each week to inspect and adapt release strategy. New outcomes, new knowledge, new risks, new opportunities for optimization and improvement appear every week. Many events are happening during the week that can affect the release strategy in some way. This is important to consider and discuss when planning releases.
- Stages. Consider the stages of testing:
The first level of testing applies to an infrastructure adequate for the needs of integration testing. The main goal is to make sure that the system works correctly. Here we can test it quickly.
Here we go deeper, and it is expensive. Testing covers different levels. We need to make sure that the system can withstand the load. Integration works smoothly and reliably. - Do everything to avoid confusion in developing a complex product, including 10+ components. Each of which has different versions, different interactions with other products, and more. The further the development, the more confusing the relationship. The earlier we detect and track them, the faster and better the increment will be created.
In conclusion, I would like to emphasize that the whole team should work on the releases. Releases need to be adequately planned, adjusted, and tested before releasing a product or part of it.
JOIN AGILE.LIVE
- Check the nearest certification trainings at Agile.Live: Professional Scrum Master (PSM), Advanced Scrum Master with PSM II Certification, Professional Agile Leadership Essentials (PAL-E)
- Connect with Agile.Live on LinkedIn
- Subscribe to Agile.Live Telegram channel
- Subscribe to Agile.Live YouTube channel