Brandi Baron is an experienced Enterprise Agile transformation and Agile adoption leader and coach working out of Minneapolis. Brandi holds CSM, SaFe, Scrum and Kanban coaching certifications, as well as Facilitative Leadership and Coaching Master’s certifications. Brandi’s experience as Business Analyst, Product Owner, and Program Manager have provided her the opportunity to see the coaching experience from an “in-the-trenches” perspective. Along with her coaching and training experience, as a people manager in the IT space for 15+ years, Brandi understands the unique expertise needed in specific industries, as well as, throughout the entire SDLC.
Agile Coaching: Are We There Yet?
There are practices that virtually all successful Agile manifestations typically employ. Deliberately engaging their mechanics begins with knowing what they are. Becoming proficient enough to get consistent results requires clearly defining where you are and where you want to go, while also being willing to take a different route.
Use metrics-driven roadmaps.
Tangible results are not only necessary for evidence that your Agile implementation has successfully impacted risk reduction or increased revenue, it’s also an essential element to keep teams invigorated and committed to the process.
Start wherever you are.
One of the key drivers of a successful Agile implementation, and where my philosophy emphatically rests, is start wherever you are. Even if your organization has been practicing Agile for some time, it’s never too late to define the criteria that evidences success. Think of it like a GPS system. A mapping application is a terrific way to assist you in arriving at your destination, but it needs to know your current location first, and then you can put in the coordinates of where you want to go.
Be willing to take detours or pause at rest stops to regroup. Trust that the pillars of Agile will keep you on track.
The beauty of GPS is also that, if you take a wrong turn or hit roadblocks, your GPS will insist, sometimes repeatedly, make a U-turn! Go back! You’re off the rails! It does this by pre-defined criteria that indicate if you are going from San Francisco to New York and you want the fastest route, don’t go via Canada. But it also manages re-direction. If you want to detour to see the world’s largest ball of twine (it’s in Darwin, MN), you can do that, too. It will let you take the detour and still get you to New York when you are ready. By enforcing Agile principles, but allowing flexibility, you encourage the likelihood of success.
How did we get here and where do we want to go?
What were the reasons behind choosing Agile Methodology in the first place? Those are the problems you are trying to solve, and by definition, are also your high-level success criteria. Was it faster time to market? If so, what was the previous time to market and is it improving? Were there fewer bugs or issues (better quality)? What was the quality rate prior to Agile implementation and how can you measure this now? Fewer bug escapes? Fewer customer complaints (Market-driven Product)? Determine a tangible way to measure these criteria by including relevant comparative time frames for true qualitative results.
Get Lean - Create a plan for today by reverse engineering where you want to be tomorrow.
When you get in your car and you enter in where you are going, you don’t expect to know the exact route to get there, or you wouldn’t need the map, but you do know that you are trying to get to New York.
If the process seems too daunting, start by reverse engineering from the end goal. Example: The end goal is a reduction to 10% bug escapes by the end of 2017. By third quarter end -15%, by second quarter end -25%, by first quarter end -30%. This is an Agile, incremental approach that is measurable. If you aren’t meeting these iterative goals, you can also quickly address what might be getting in the way.
Be willing to change the metrics if you see no value add to the product after the first measurement.
What if you were certain that bug escapes were the go to market issue, and quarter one results show reduction made no significant difference? Be flexible and re-define your goal. Implementing “Agile” is not the goal. Continuous improvement is.
Several Agile practices are intended to assist with continuous improvement. Daily Scrum, retrospectives, and Scrum of Scrums are all not only great tools for determining how to improve or keep delivering, but can also be a sounding bell telling the team it needs to make a U-turn, or take another more efficient route.
Make it visible.
While GPS often speaks to you, it also provides a screen which outlines the detailed, step-by-step directions of where you want to go. If you take a left turn, the map also updates the route. Transparency is key. It would be quite unnerving if the route was super-secret and you had to simply hope it was taking you where you wanted to go. Visibility is not meant to micro-manage, but rather to provide the entire team with the opportunity to re-route, see where they are headed, and avoid potential roadblocks.
Be willing to take baby steps.
Track and measure small things. Over time, resolved issues or improvements, no matter how tiny, become reportable evidence of success. Think of this type of success criteria as keeping the car tuned or changing the oil so the performance is up to par. After all, you won’t arrive at your destination if the car is stalled or you’re pushing it... uphill. The key to metrics-driven roadmaps is to take action. Your GPS will not work until you put the car in drive. Taking the next known action with confidence that you have tools in place to re-route when necessary, reduces the risk of stagnating and or ending up in a dark alley.
Don’t throw the baby out with the bathwater.
Can you imagine if you had driven across the country only to quit when you were almost there? What I’ve seen over the years during Agile Implementation discovery assessments is one of three things: 1) The entire Agile practice is seen as a failure because one element is not working, 2) the team is not truly measuring where they came from, or 3) The team had unrealistic expectations of improvement. They now have euphoric recall about how awesome it all was prior to introducing Agile or worse, they expected Agile to be the cure. Agile is not a silver bullet. It’s only as much a bullet at all as the organization or team gives it the power to be. You can, however, make arrival much more repeatable and successful if you re-route when necessary, clearly defining where you are starting and where you want to go.