We reached our 100th agency transformation milestone a month or so ago, and I’ve been spending a lot of time thinking about what we have learned. Not everything went perfectly during the last 7 years, not by a long stretch, but I think we’re doing pretty well, and my biggest takeaway is that doing this well has as much to do with transformation management as it does the actual techniques. We didn’t start out as change management experts, but I now believe that is to where the pursuit of real Agile transformation leads.
Mastery of the Agile techniques matters greatly, yes, especially the ability to customize and tune them. But as the famous phrase goes “Culture eats strategy for breakfast.” No matter how killer your Agile techniques are, if you’re not dealing with the core culture of the organization, your transformation will be challenged and will struggle to gain traction or maintain its level of adoption. “Organizational culture” effectively means “how the organization behaves”, and it is managers and leaders that shape and control culture in this way…because they largely control process.
In our dataset, it also appears to be size-based challenge. In small organizations, say 20 people or less, there are usually few managers and as a result they have a fairly easy time of switching to Agile. But larger clients, with 60 staff or more, often have massive numbers of managers (30% or more of the organization is not unusual.) When implementing a technique like Agile, where a key part of the managerial function is passed to the team of workers (that’s what self-managing teams means, btw), means that managers need to change as well, even more so than teams.
These managers are also an opinionated lot — more on that later — and for time eternal prior to the shift to Agile, they’ve called the shots in terms of how their processes work. Your Agile transformation is not unlike telling your neighbor how to mow their own lawn. Setting an understanding of the benefits, managing expectations of the coming changes, and smoking out those who will be a challenge, are among the many good reasons for why you’ll want to have a real plan, not just an idea and a still-wet Certified Scrum Master certificate.
I’m going to just bang through some high points that I think matter — hopefully helpful for you in this format — and I’m using a mental model from our work with HelloWorld, whose case study we just published here.
You need an approach. One easy trap to fall into is just starting without a plan. A lot of Agile writing encourages this, saying “Just get going!” If you’re doing the type of Agile that will change things in a big way, you need a change management approach. We’ve always had a framework for our training, including the pacing, which is critical. I know you might say it is not very Agile to be writing a GANTT-style plan, but hey, write the plan.
You need your North Star. Or Southern Cross, if you’re down there. Understanding Agile, and how it really works, is essential. Many folks we’ve spoken to had sent a few project managers to Scrum Master training, and hoped that they could implement Agile. But the CSM training is pretty darn vague, focusing on basic mechanics and somewhat silly games.
Since every Agile technique will likely need adjusting to your situation, you need to be able to worry less about how to do a stand-up meeting and more about what the principles at play are, such as self-empowerment and ownership. That’s the North Star — you (or someone) will need to know what matters, and know how to break the “rules.” At HelloWorld, they had a whole half of the shop that was running SAFe, a dev-oriented version of Agile. It didn’t work well for the agency side, but it meant that they already understood a good number of the principles before they chose working with us.
And you need a finish line. Define the business case for doing this. What will you make better and by how much. For example, being able to deliver work with a higher level of quality (less rework, for example) could be a worthy goal. In the case of HelloWorld, they had problems with scope creep on their larger projects, so that became their target and ultimately a well-defined win. Then design your program for the processes that you need to implement in order to achieve that result.
And most finish lines are preceded by some hurdles — they’re important too. Define what Agile will not fix — that includes people. Agile techniques do not fix bad managing unless the bad managers (or their managerial style) change. Actually, failure at this one step is probably the largest source of Feckless Agile as I described in my article on mis-managed Agile (link).
Get your sponsors not just involved, but engaged. At HelloWorld they very quickly involved the CEO, Peter DeNunzio, in order to make sure that the business case — and shifts needed — would align with his vision for where the organization needed to go. And that’s just the starting point. Saying that leadership is behind something creates one sort of behavior, but saying that “this is our new way” creates a whole different behavior. Conveying that latter message means being engaged daily in honoring, observing and celebrating the shift to more-empowered teams. Think “soccer mom” if you want a good metaphor.
Beau Lane, CEO of 100+ person LaneTerralever, attends almost every morning stand-up meeting. Guess what, he loves it, and says its been years since he’s felt this connected to what’s happening in the agency. And Beau isn’t alone: most of his leadership team attends as well. Likewise, at HelloWorld, they invested in continuous facilitation and engagement by a group of managers to reinforce how important the process was, and that it was, in fact, their process too.
Training is a team sport, just like Agile. All training should be all-hands. I’m always surprised when someone suggests otherwise. I mean, aren’t we trying to create teams? Since when does training just a few people lead to the other people feeling like they are all one team? One of the other pitfalls of the CSM model is that only a few people are given knowledge, and that results in their having to tell people what to do and how to do it…controlling them; which is the exact opposite of the desired Agile managerial behavior.
Also, classroom trainings have their limitations. We’ve seen hands-on workshops create superior results. If people can’t apply it right away to their work, then they likely never will. Sending a few people to a CSM class where they’ll do a stand-up with a bunch of other people they don’t know (using a pretend scenario) means that your future teachers have never even seen a real stand-up, much less a good one, themselves.
Be ready for the Challenging People. We get asked lots of challenging questions, like “How could you possibly train my whole team and have them learn it well?” We say “Teams are easy — they get the benefits of Agile the minute they see it.” It is always a manager asking that question, by the way.
Managers are the ones who have the hardest time adapting to Agile — you’ll need to spend a good deal of time playing WIIFM: What’s in it for me. Many line and middle managers have been promoted up from a specialist role, and are not even aware of the real role of managing: managing and shaping behavior, rather than directing and controlling process. You need to over-index on spending time and training with them.
In a non-Agile environment, process-direction is the standard way of managing: tell people what to do, when to do it, and maybe even how, if the mood suits. Effective Agile managing is facilitative and looks a lot more like being a golf coach than a drill instructor. In the end, most managers enjoy the change, as it is far more rewarding. Except, for those who don’t.
Plan for those who will leave. You will lose some people. And that’s fine. We see about 10% attrition from a good transformation. Why’s that? Because your current staff falls into two personality styles: those who are there despite the management style you allow, and those who are there because of the management style you allow. If you change to an Agile style of managing, where managers empower rather than control, you’ll lose those people who want to tell others what to do and those who want to be told. You’re probably better off without them — that’s the consensus we hear from our clients. If you stop and think about it, you may even know who some of them are.
But another learning that we have, and one they also saw at HelloWorld, is that us humans can be pretty amazing when you really give us a chance to shine. As I noted in my Media Post article, How Good (Or Not) Are Your Agency Managers?, poor managing is quite invisble and can bring people down…and we can be quite myopic to this, relying on the manager as the source of truth. Once the managerial environment gets better, HelloWorld (and many other clients) have seen people step up, demonstrate previously un-seen skills, and generally start taking more responsibility for making sure things go well.
Measure and adjust per feedback. One of the Agile founders was quoted as saying that there will be no Agile 2.0 — that was because every Agile implementation should be built for the situation’s needs and the team doing the work. A good Agile implementation ends up being like a custom-tailored suit: a mix of both tight and loose-fitting in the appropriate spots. Judging the fit needs to be done with metrics, not opinions. We encourage our clients to deploy Net Promoter Score or NPS to all of their clients or stakeholders. You can also do an eNPS version for all employees. When the numbers go up, you’re doing it right. Very simple. Measure every 1–3 months and share it with everyone.
Give yourself time to succeed. In a purely technical sense, one could “teach” Agile quite quickly. But a good deployment approach focuses on pieces one at a time. For example, learning how to talk about scope, especially with a multi-discipline team, is something that requires some practice before it comes natural. Make sure your plan breaks things into bite-sized pieces in order to build mastery. HelloWorld chose to pilot the techniques on a major client account in order to both learn how to best implement, and also to set up a model that others could emulate. By focusing on one account team, they built mastery at all levels.
In the end, the most important part of your plan will be the new roles you’ll need in order to sustain your successes. This doesn’t (or shouldn’t) mean more people. Sustainment actually is far more rigorous than most realize…and having an all-hands method like Agile requires that you’re open to full feedback. Keeping things centered throughout that conversation requires three different roles:
- people who own the conceptual North Star for what Agile is and what it means to the organization, who will also ensure that people keep the values and goals in sight. This is a leadership role, and further underscores the need to implement Agile as a holistic change to culture, starting with the leaders.
- people who will measure and monitor understanding and compliance to process, helping with adjustments. This is needed because feedback can get distorted when coming from a non-compliant team: if they don’t know how to do it, they will think Agile sucks, and they will be right. HelloWorld had a training manager assigned to ensure that everyone was trained up and competent.
- people who will be responsible for facilitating day-to-day execution, ensuring, as best they can, that everyone remember the rules, and also being facilitative to ensure great group behaviors. These people should be numerous — aim for 20%+ of your people to feel like they can do as well as guide and teach.
The first two types, you can cover with just a few people, but for this latter one, you’ll want people in every team and context. And I think that this is where HelloWorld really shined — they mirrored their commitment with a small team of managers and leads who realized that success is a team sport as well their own.
