Lean, agile and Lean Startup can strengthen each other for driving improvement. Lean Pilots, a data-driven improvement framework for removing major cross-functional organizational impediments, has been used to drive internal continuous improvement.
Mariya Breyter, Director for Agile and Lean Practices at Dun & Bradstreet, spoke about the Lean Pilots framework at the Lean IT Summit 2017 in Paris, France. The views expressed below are her own and not of Dun & Bradstreet.
Breyter started her talk by explaining how they have built a framework that helped them solve challenges by identifying cross-functional inefficiencies, and experimenting with combining ideas from lean and agile to come up with solutions.
When a new improvement team starts, the first step is to find out what needs to be accomplished. You have to be clear on what you need to achieve and know exactly what success looks like, said Breyter. Teams use a single page description which documents the why and what of the improvements that they will make.
Improvements are done using a Scrum approach. Professionals work together to succeed as a self-organized team, regardless of where they come from. They have a backlog with improvements and a product owner who prioritizes the improvements. They iterate in two week six sigma DMAIC cycles. At the end of each improvement iteration, they do demos where teams show the results and have lots of discussions. They have synchronized the cadence of demos and retrospectives.
Teams also use lean startup to experiment and validate the solutions that they come up with. If it turns out that something doesn’t work, then they kill it and look for other solutions. Don’t fall in love with the solution, fall in love with the problem, said Breyter.
InfoQ is covering the Lean IT Summit 2017 with Q&As, summaries and articles, and interviewed Mariya Breyter about driving improvements with the Lean Pilots framework.
InfoQ: What are the main challenges that organizations face when they want to address and remove major impediments?
Mariya Breyter: According to the 2016 State of Agile Report, common challenges include slow product delivery, inability to manage changing priorities, challenges with delivery predictability and visibility, all closely coupled with low employee morale and multiple difficulties related to managing distributed workforce across cultures and continents. At Dun & Bradstreet, we experience similar challenges, which may affect our ability to quickly deliver products that delight our customers and impede business success. Examples include migrating our customers to new platforms, onboarding third party vendors, consolidating sales assets globally, or renewing service contracts with our customers – in each case, we identified a need to simplify, automate, streamline the process and make it delightful and productive for our customers, internal and external.
InfoQ: How can Lean and Agile complement and strengthen each other?
Breyter: The relationship between lean and agile is complex. Some agilists do not even see a direct relationship. Even those who recognize that agile mindset is based on lean principles of value delivery, reduction of waste, and system thinking, frequently have a perception that while lean is a manufacturing approach that focuses on minimizing costs by eliminating waste and improving process efficiencies, agile is just the application of lean mindset to software delivery with a set of processes around it. This is only partially accurate because agile, and specifically Scrum, bring two important concepts into lean: incremental delivery and cross-functional team-based execution.
Our Lean Pilot framework implements lean six sigma DMAIC cycle at cadence using Scrum framework. DMAIC is a data-driven quality strategy used to improve processes. It is an integral part of a Six Sigma initiative, but in general can be implemented as a standalone quality improvement procedure.
From the Scrum perspective, it means that for every iteration (Sprint), there is one or more high priority features from the improvement backlog (may be related to business process improvement, process automation, or product enhancement) that is getting implemented and then measured to define whether the result meets Lean Pilot’s success criteria. This is where lean startup experimentation concept comes into play. If the measure brings performance to a pre-defined level, we persevere; if the result is unfavorable, the hypothesis is invalidated and the team pivots the next sprint to implement the next highest priority measure. This provides a safe and fast way to fail, and ensures high efficiency in validating any assumptions.
This combination, coupled with cross-organizational and cross-functional nature of modern-day impediments, makes lean-agile framework so powerful.
InfoQ: Can you describe Lean Pilots? Which purpose does it serve and how does one use it?
Breyter: Here’s the definition: Lean Pilots are internal improvement initiatives which provide a framework for removing major cross-functional organizational impediments that have significant organizational risk associated with them.
What do we mean by that? Since Lean Pilots are internal to the company, I have to start by describing who we are. Dun & Bradstreet helps our customers build business relationships by utilizing the largest commercial database with records for over 250 million companies worldwide.
Lean Pilot provide a way for us to rapidly resolve internal inefficiencies as well as provide long-term solutions. Normally Lean Pilots that we run are related to process inefficiencies, customer dissatisfaction, or multiple types of waste in end-to-end processes. In each case, these pilots include analysis and ongoing experiments performed by self-organizing teams and measured in short intervals to decide whether the team should pivot or persevere.
The most important part of the Lean Pilot process is that it was created in a lean way, just-in-time. When we started Lean Pilots, we only had an idea to deliver DMAIC on cadence by a dedicated cross-functional team, using Scrum framework. It means that we managed our lean project backlogs in JIRA or Trello; all Lean Pilot teams had their Product Owners responsible for prioritization of "user stories" in the backlogs, and Scrum Masters, responsible for implementation and continuous measurement of the selected improvements. We ended each iteration with a "demo" of the completed "product" to our stakeholders, and a "retro" where the teams came up with the Lean Pilot process improvements. Over the time, we had to build multiple boundaries and define best practices; as an example, we developed and validated our scoring mechanism for lean project intake and exit.
A few thoughts about exit criteria. Over the period of six months, we realized that while a "go/no-go" demo every three months allowed us to cut costs early for those pilots who invalidated every hypotheses we could think of, we realized that some of those hypotheses were viable and worth trying. So we changed our approach from managing pilots to building self-organizing teams around them. Now our coaches can exit after 4-6 sprints without any impact on the team which becomes self-sustainable. This was a big win and a pivot in how we approached the concept.
InfoQ: You presented several case studies with Lean Pilots. How have you used Lean Pilots to remove impediments?
Breyter: One example is our Contract Automation pilot. For years, our service contracts with customers have been high-touch for our sales team. Each renewal required heavy manual intervention and our average cycle time was measured in week. We validated some hypotheses related to changing the verbiage of our Master Service Agreement and invalidated those that were related to pricing strategies, before actually implementing them. If we went the traditional route, we would start with a workflow automation tool and it would become a multimillion dollar project. With Lean Pilots, we implemented minor customization on our QTC application with nominal investment, and achieved significant increase in the number of customers who sign our contracts electronically, without any human intervention. In 12 months, the number of electronically signed contracts increased by 34%.
In sum, the whole framework developed organically, and the choice of pilots was not intentional, though the mix reflects potential pilot mix very well. Let me name a few: Contract Automation pilot to increase the number of contracts electronically accepted by our customers, Privacy Shield pilot to meet an aggressive timeline in complying with a new EU regulation, Comprehensive Assessment Report (one of our products) process enhancement, Customer Experience improvements related to DUNS Numbers (unique ID) generation for new businesses globally, Third Party Vendor experience and overall process. Most of these projects included IT component, e.g. we implemented portal changes to improve workflow tracking for the Third Party Vendor experience. What is remarkable is that all those pilots, business and IT stakeholders composed a single Lean Pilot team with clear roles, expectations, and responsibilities.
InfoQ: What have you learned from applying the Lean Pilots framework?
Breyter: We learned many things, both positive and challenging. Let me start with challenges. All team members on our Lean Pilot teams are subject matter experts in their areas: IT, sales, product, marketing, legal – as it applies to each specific pilot, and all of them have been working on Lean Pilots part-time and multitasking with their day-to-day responsibilities. This was a challenge. What helped a lot was their dedication. Dun & Bradstreet core values are data inspired, relentlessly curious, and inherently generous. All three values spoke to team members. No one was "allocated" to a pilot- everyone was asked whether they would like to contribute. We also implemented a specific approach to ensure that this did not affect team members’ sustainable work-life balance – I’ll share additional details when we talk about retrospectives.
Another challenge was baselining our pilots. Each of them was data driven with success criteria defined prior to starting implementation. However, data collection frequently included legacy systems or global impediments with multiple workflows, stakeholders, systems involved across the globe; and it was not an easy effort to define and incrementally measure success. As a result, we implemented data baselining as part of our Sprint 0 and had a data measurement "user story" in every sprint. The reason this was a significant challenge was that if we did not predefine success and then continuously measure results against this, we would never know when to stop. Moreover, we would not know whether we achieved the result we were looking for. For example, when we started the vendor onboarding improvement project, we knew we needed to reduce cycle time from 17.5 days, but we needed to decide when we would consider the project successfully completed. We did the research and found out that the comparable average was 10 days. Then, we decided that our pilot would be successful if we reduced it at least to six days, based on the Voice of Customer survey. As of now, we are at 9.1. Once we reach the service target level of six days, we will close the pilot.
Now, a few things that worked well. Incremental delivery with "go/no-go" checkpoints at cadence worked very well. In combination with well attended retrospectives, this created a powerful cadence that achieved two purposes: eliminating waste and allowing the teams to receive ongoing feedback and establish close relationships with the stakeholders. As an example, initially we struggled with team members’ availability because none of them were fully allocated to a dedicated Scrum team. Based on a retro item, we developed clear expectations and got buy in from managers of the team members before they joined Lean Pilot teams.
We also started with each potential Lean Pilot member by asking if they would like to work on a Lean Pilot so that the team would feel autonomy, and was empowered to make their own decisions. It was also very helpful to make every process repeatable and document it in a Playbook just in time, as soon as we encountered the need to develop it. Because of that, there was almost no process development and documentation overhead and we were able to create a framework that has been tested in practice and improved in real time via ongoing feedback loop.
Most importantly, we are still learning and continuously improving. If anyone would like to try this out or learn more about it, we are always glad to share our experience – it’s not a commercial framework, but it is something that works for us internally at Dun & Bradstreet, and we will be glad to share and learn back from the community.