Agile transformations are complicated endeavors, especially for large enterprises trying to keep pace with today’s fluid digital marketplace. Add the additional difficulties of having to orient delivery teams around products and bridging entrenched organizational silos – well that is quite a challenge that requires uplift across multiple dimensions. Many teams have begun their transformational journeys only to find their progress ground to a halt when they come face to face with cultural rifts, challenges implementing DevOps, struggles estimating their work, and unrealistic deadlines to get products in the hands of customers.
For a change to be sustainable, it cannot be done in a vacuum. The entire organization’s culture needs to shift accordingly. At a team level, we began a grassroots adoption of a generative culture, focusing on outcome-based performance and improved collaboration. We broke down role barriers to improve the flow of information and made the end-to-end value stream flow visible from concept to implementation. Failures were welcomed as opportunities for improvement and we made sure to learn from them with customer feedback loops. Knowing that this culture shift needed widespread adoption, we promoted our lessons learned through frequent Gemba walks – 70 and counting. Teams are the test centers of agile evolution, but great initiatives end there without publicizing team successes and encouraging others to work toward the same organizational goals. At the end of the day, we are a team of teams all working together toward the same goal – producing excellent products for our customers.
Meeting the expectations of those customers requires companies to have ever-shorter product life cycles. Quick and incremental delivery is key to remaining competitive in the digital marketplace. In order to reduce the time to market, we introduced the concept of a “minimally marketable product” (MMP) to our delivery team and business group. Because neither can successfully deliver without the other, we also fully integrated these groups into a single team. Incremental delivery allowed us to move our customers to the “happy user peak” without the risk of providing so much functionality that the products became too complex for them. In the same spirit, we prioritized finding the shortest possible path to meet our goal. Leveraging impact mapping and story mapping, the team partnered with our product owners to identify the desired outcome for the customer and the fewest number of deliverables required to realize that outcome. The emphasis was no longer on delivering scope, but on delivering outcomes. To optimize this path, we are assembling a fully persisted requirements library for each product so the team can quickly populate its backlog and start development the same day a concept is introduced, if necessary.
So often, teams are asked to provide estimates for an effort, usually with varying degrees of inaccuracy. As a result, teams can suffer “estimation paralysis” – continuous estimation through a product’s delivery that impedes the implementation of the desired functionality for the customer. This can result in strain and frustration between the delivery team and business. By introducing relative sizing and calculating the rolling average hour conversion, estimation became an increasingly accurate one-time event during each product’s delivery cycle. This approach to estimation allowed the team to focus on a change’s complexity rather than the time they thought it would take to complete those changes. By doing so, we improved trust between the delivery team and business while getting in the ball park for how long it would take to implement the MMP and the associated cost.
Lastly, uplift in three main areas – business acumen, technology and leadership – contributed to one of our larger “aha” moments: our product was not only what was delivered to the customer, but also the delivery pipeline that supported its implementation. If we did not bring the pain forward by prioritizing building out this pipeline and keeping it healthy, it would impede the team’s ability to deliver products to the customer. In the past, technical debt and continuous improvement (CI) work were frequently the first items to be deprioritized in time crunches. Our team used improvement katas to define what technical debt and CI work needed done. We then used CI iterations once per quarter to ensure we had dedicated time. In addition to maintaining a healthy delivery pipeline, this also improved team morale by making the code base easier to navigate and decreasing maintenance costs.
Scaling requires organizations to alter operating models and organizational structures to empower the delivery teams. Entrepreneurialism is risky – encouraging teams to innovate, learn their products and hone their skill sets allows them to better serve their customers. There is a long way to go in our enterprise agile transformation, but the seed is planted and with continued support, can flourish.
Kristen Biddulph is a former Scrum Master, Nationwide Mutual Insurance Company.
