5 Steps to Take When Your Agile Transformation is Struggling
Picture this. You’ve rolled out your transformation to your team(s), and even though there was some initial skepticism, most people got on board (or at a minimum have agreed to execute the steps/go through the motions). Things are chugging along, but suddenly, things change. You’ve missed a key deadline. There’s friction between a few of the team members. A senior leader is frustrated. What do you do?
First, let’s take a step back and breathe. This is common when leading a team through any business process change and things typically get at least a little worse before they get better. If the change is your brainchild, it can be especially concerning for your survival at your workplace. I’ve been there, and I’ve lived to tell the tale. Here are some steps that have worked for me.
Do a personal retrospective
I like to do a personal retrospective and write it all down. Retrospectives are a chance to look back, take stock of what happened, and distill action items. When doing a personal retrospective, I prefer to do this literally on paper and not digital format, as it’s tangible, more private, and maybe you can crumple or burn it later for a little catharsis! Whatever method you prefer, assess what happened when you thought of your new process, identify your established goals, and detail what happened once you rolled it out. What were the reactions (who said what, what skeptical comments were said)? What went well? What could have been done better? Were there noticeable successes to be celebrated?
Document the current complaints/concerns you’ve heard and clarify if they’re issues that will be resolved by staying the course or if changes should be made. If changes are required, identify what changes can be put into motion. An effective way to do that is to use systems thinking to analyze how work has flowed through your new process. Were there gaps? Was work waiting? Was there poor/unclear/no communication? Look for AntiPatterns, or bad responses, to a recurring problem that’s ineffective.
You should “leave” this retrospective armed with some specific tactical steps to change and improve the process.
Solicit feedback from friendlies
As you lead change through an organization, it’s important to develop a bunch of early adopters, or as I like to call them “friendlies.” These are stakeholders at any level in the organization who like your ideas and adopt them early. Sit down with some of these friendlies, do a similar retrospective with just them, but let them do the majority of the talking. Be an active listener. You should be in a position of trust with these folks so simple questions like, “Where did I go wrong?” might be a good starting point, but you might need to probe a bit. Think about what you identified in your solo retrospective. Ask about those items and find out if they think you were unclear on some of the finer details. These meetings should (hopefully) provide some additional tactical changes to make to the overall process.
Call a meeting with the team
Ok, you should have insights about what went wrong and now it’s time to discuss it with everyone. It’s important for your credibility as a leader to not have your head in the sand about problems. It’s critical that you address them with transparency. You should walk into this meeting like a lawyer about to cross-examine in that you should be able to predict what they are going to say.
(Re)state the vision:
If you haven’t yet messaged what you’re attempting and why (you should have when you rolled out – if you read my previous blog post, you’d have known this – shameless plug).
Remind them that challenges are part of the process:
Bumps in the road are normal. It’s common for big changes to initially slow productivity down before it improves, but don’t downplay the issues. Again it’s crucial that the team sees you as accountable and trustworthy.
If you’re looking for an example to reference about how and why it’s normal for teams to struggle initially, you can reference Tuckman’s stages of group development. The group may have already been in existence – but the way they are doing work now has changed, for that reason, this model becomes very applicable.
Show you’re taking action:
Document what went well, what didn’t, and create action items from this list.
Identify and celebrate the wins. It, of course, can be easy to overlook the positives if the overall sentiment is negative.
Workshop the adjustments
If you’ve distilled any adjustments that can be made, propose them with the group. Use vocabulary like “adjustments” or “tweaks.” it’s important to set the paradigm that the changes needed are small and attainable and that we’re adapting and learning. Emphasize that learning itself is a positive outcome. When you’re meeting with the entire team, make sure to record your notes in a shared digital format like Confluence so they can visually see the action items and how the team is trending against it.
Give it time, but set a date to do a retrospective on the changes made. I suggest giving it at least two months. This will further demonstrate that as a leader you are listening and want to receive feedback and adapt. A great way to collect feedback and allow people to comment freely, anonymously, and over time is to use a retrospective starfish.
Here’s how they work:
You use either a dry erase board or a flip chart and basically draw a pie chart with five equal sections.
Label the sections with “Stop”, “Start”, “More”, “Less”, “Keep” – this allows people to put a sticky in the area that matches their thoughts (i.e. Stop discussing Work in Progress, Keep removing our blockers, etc.)
And if all else fails, learn
Understand that changing the way people do work can be difficult. There’s always the chance that your transformation may outright fail and you may be forced to abandon it. I’ve experienced it myself and learned from it, specifically the importance of having those friendlies I mentioned earlier. In a previous job, I had transformed a Systems Engineering team’s workflow which was essentially “whoever screams the loudest wins” to Agile with Scrum. When problems hit, I didn’t have feedback and thought I knew how to fix it. I tried adjusting our new workflow, but my adjustments were not resonating with all of the engineers nor with some of my stakeholders. I ran out of time and was forced to abandon the transformation altogether.
But I learned.
It’s important to fail the right way. To do that you must have a mindset of, “I either succeed or I learn.” But if you’re going to learn, make sure you’re actively learning. Pinpoint what the reasons were that caused the transformation to fail. Did you not address a stakeholder? Is there a cultural nonfit? Is there a way forward with that team?
However it plays out, you will level up your grit by leading change in an organization. Change can only happen if you build the trust of your team and continue to listen, learn, and adapt. If you can be this kind of leader, success is bound to find you no matter how many “lessons learned” happens along the way.