When picturing an effective and truly agile product development team, one often imagines a software development team, pushing some software to production every day, maybe multiple times a day, ala Amazon.
By doing so, these teams gain the ability to test their assumptions early and often about the solutions they are building from both a technical and business perspective.
The technical perspective includes validating what happens when the product is fully integrated and deployed in production. In other words, “have we built the thing right?”.
The business perspective includes validating how customers respond to the features, the capabilities and the experiences that the product offers. In other words: “have we built the right thing?”.
As a consequence these teams also reduce risk of rework, and waste, and increase chances of being successful in the market.
This is a great place to be in and if that’s where you’re at, good for you. Also if you are working on a product where this is an achievable goal, the world has plenty of resources to help you get there, in the form of experience from others, case studies, and good practices.
But not all industries, business models or technologies allow for this to happen. I am not talking about those companies and teams that suffer from self-imposed constraints and obstacles such as counterproductive internal governance, or old-school development and engineering practices. I am talking about situations where releasing to production early and often is either not possible, or at least extremely costly. That limit on the frequency at which the product can be tested by the entire user population, in production, can either come from a business consideration, a regulatory consideration, or a cost consideration. Think about the next iteration of the Google Pixel smartphone, making a new treatment accessible to all patients, or sending a rocket to space.
If that’s the situation you are in, rest assured that you can still “be agile” and benefit from a lot of the early assumption testing and risk reduction I mentioned above. Here are two strategies and a handful of tactics to help you achieve that.
Strategy #1: Get your product in a “potentially releasable” state as early as possible, and maintain it in that state, even if you don’t actually release it
When teams don’t have a business imperative to release a product, it is tempting to delay those activities like stress tests, UAT, compliance sign-off, documentation, etc. After all, these are only needed when we release, but we aren’t doing that anytime soon, so why bother?
The problem with this way of thinking is that risk builds up over time. As you reach the end of your project and the release date approaches, you want risk to be at its lowest. Yet, as you perform those final stress tests, UATs and compliance sign-offs, you are finally discovering all sorts of new problems. That stress test may reveal a major flow in your architecture and cause a lot of rework. That UAT may reveal that a third of your product features are barely used by anyone, and therefore that the development teams should have spent their time building something else instead. That compliance sign-off which everyone thought was going to be a mere formality may reveal all sorts of bad news that can delay the release of the product.
By always having your product in a so-called “potentially releasable” state, you eliminate those risks. In Scrum, we implement this strategy essentially by
- formalizing a “Definition of Done” where Done includes “potentially releasable”
- making sure we create at least one increment of the product that meets this “Definition of Done” each Sprint
Conducting stress tests, User Acceptance Tests or compliance validation (for instance) each Sprint may seem like a costly strategy. But most teams that try it find out that the benefits exceed the costs. Also, those costs can be reduced by adopting the right approach. For instance by setting up the right team structures (cross-functional, empowered teams) and by investing in the right engineering techniques and tools (test automation, CI/CD, simulators, etc.).
This first strategy is also an enabler to the second strategy below.
Strategy #2: aggressively gather information about your product, without waiting to have direct and exhaustive access to the market
As we saw earlier, the ideal way to test an assumption about your product is to ship it to everyone, in production. However even if you cannot do that, you shouldn’t allow too many assumptions to build up in your product until you can finally launch or release it. Therefore, invest in gaining insights from different sources. These insights may not be exhaustive and collecting them may not be easy, but they are extremely valuable in maximizing the chances that your product will reach its goals. Here are three ways to collect these insights:
- Dog-fooding and internal user groups
Eating your own dog food or "dogfooding" is the practice of using one's own product or service.
In one of the teams I supported as a Scrum Master before, most of the members were genuinely passionate about the product we built and were active users of the product outside working hours. This allowed the team to be a lot more creative and a lot more autonomous about figuring out customer needs and potential solutions. Facebook and many other companies are using this technique.
In some cases, dog-fooding does not happen entirely organically. The team in this case needs to be more intentional about building that community of internal users, and collecting feedback from them.
- User representatives and proxies
User representatives are people in the organization or in your ecosystem that are well positioned to speak to your customers and users’ needs. Internally, these may be people working in Sales, or Customer Support. Externally, these might be opinion and community leaders or user advocacy group members. None of these people individually represent the entire market that you are working with. However, if you have the right number of the right people and learn to interact with them effectively, you can collect feedback that is pretty close to what you would get by shipping the product to production.
In the context of Scrum, you may want to engage with these representatives at least during Sprint Reviews, or collaborate with them on Product Backlog Refinement activities.
- Early Access and Early adopter programs
This practice is about giving access to the product to a small set of users under certain conditions. It is common practice in the gaming industry for instance; where video game editors use it to gain both valuable feedback and a crucial revenue stream before the official release of the game.
But this practice can be implemented more broadly, including for B2B initiatives. One of my clients was building a very ambitious software product targeted at mine operating companies. We developed two strong partnerships with customers early on. The entire development team flew to the actual mines to sit with these potential future users, and test crucial hypotheses with them.
Again, this may not be cheap. But it remains a lot cheaper than developing the wrong product and figuring it out when it’s too late.
Conclusion
In short, YES you can be agile even if you release, say, only once a year. What matters is to have the courage and the humility to recognize that there is a lot you don’t know, and that failure is a possibility. From there, you need to implement the right strategies and techniques to go and find out about the things you don’t know, and then to repeatedly inspect and adapt in order to increase the chances that your product will be successful.
----------------
About the author
Gregory Fontaine is among about 350 Professional Scrum Trainer™ (PST) at Scrum.org and the CEO at Agorax GK. He has many years of experience applying Scrum both in software development and in a variety of other fields. He is the only Japanese Speaking PST and has been supporting clients and students in Japan for many years. If you want to learn more, please consult Gregory’s class schedule or Agorax’s website.