Four Signs Your Agile Transformation May Be Off Track

This video is the first in an ongoing series on improving Agile outcomes in the federal government context. Today, Summit introduces its Agile Transformation Team and highlights four signs that your Agile transformation may be getting off track.

Meet Summit’s Agile Transformation Team

Kaye Burton is a certified SAFe Practice Consultant 6.0, Registered Scrum Trainer, Registered Scrum@Scale Trainer, Registered Agile Coach, Certified Business Analysis Professional, and Certified Project Management Professional (PMP).

Derek Hills is a certified SAFe Practice Consultant 5.1 and Certified Business Analysis Professional.

Andrew Robbins is a Registered Scrum Trainer, Registered Scrum@Scale Trainer, Lean Six Sigma Black Belt, and Prosci Certified Change Practitioner.

Jackson Walbridge is a registered Scrum Trainer, Registered Agile Coach, and Lean Six Sigma Black Belt.

Summit’s Agile Transformation Practice

Core services we offer:

• • Strategy and execution to improve organizational effectiveness and business agility
  • Workflow mapping and analysis
  • Organizational design
  • Impediment identification and resolution
  • Training in Agile (SAFe, Scrum, Lean) with coaching support
  • Team formation and launch
  • Proxy backlog and product management
  • Stakeholder engagement and communications

Transcript

Derek Hills: Hi, I’m Derek Hills with Summit Consulting’s Agile Transformation Team. I’m here today with my colleagues Kaye Burton, Jackson Walbridge, and Andrew Robbins, and this video is the first in our series about implementing Agile effectively in a federal government context.

Agile has become much more popular in recent years because when it’s done right, it promises better results faster, at least compared to traditional program management practices.

But that doesn’t mean that it’s easy. For those of you who have been to Agile training, you know that your federal government context doesn’t look a lot like the textbook Agile context you learn about in class. Why is that?

Well, you can’t say what business you’re in, for one thing. Also, you have outside parties, like the White House and Congress, continually meddling with your priorities. And also it’s hard to staff people full-time to your program—and even when you can find those people, they don’t always have the knowledge or skills required to contribute effectively to your Agile program.

So what do you do? You go to market and hire somebody to do the job for you. But how do you monitor those folks? And how do you know they’re working on the right things?

These are the kinds of topics that we’re going to be talking about in this series, starting with today’s subject: four signs that your Agile program may be going off the rails. And to kick things off, I’m going to pass it to Jackson.

Jackson Walbridge: Hey folks, we’ll start right at the beginning of any transformation. Learning about Scrum, learning about Agility is really exciting. Finding that there’s new ways of working, new ways of organizing your work, and working more efficiently as a team can get a lot of really positive energy driven in directions that need a lot of guidance.

For teams that are in a new transformation, or they’re exploring new ways of working, it can be very tempting to try and lump all of these really cool ideas into their first release and trying to get all of the features, all of these improvements, all of these additions added into this new release. And so teams that are exploring transformations, they’re exploring new ways of working, us coaches like to step in and help them explore ways of implementing these slowly and in a sustainable pace.

Kaye Burton: That is so true, Jackson. I see this especially in the government context when you have that client-contractor relationship, where the contractor may not feel comfortable sharing what they feel is an unfinished product with their clients. So really important to set those expectations of clients early and often.

One red flag that I look out for is people complaining about too many meetings. So I know what everyone’s thinking, right? Who doesn’t complain about too many meetings? I know I’ve done it. But when you hear this in an Agile environment, it may be an indicator of one of two things happening...

So the first one is that your Scrum events are not being run very effectively. So maybe your daily Scrums have really started feeling more like a status update, so your team isn’t finding much value in that. The other thing is that your team may have simply added on all of their events—all those Scrum events—onto their existing calendar without taking away any of those previous meetings. So this can lead to duplicative meetings and a lot of waste for teams.

Andrew Robbins: Kaye, I’ve seen that exact same thing. In fact, on a team I’ve worked with recently, when I dug into some people who were saying that they have so many meetings on their calendar, I found out it was because they were on multiple teams.

Sometimes multiple Scrum teams, sometimes not—regardless of whether they have duplicative Scrum events across different teams, or if they just have a lot of meetings on a non-Scrum team and all of the events on a Scrum team, it was a lot of time spent in meetings. Beyond just the time spent in the meetings, they also had to contact switch from one body of work to another.

That loss of productivity, that mental unpacking and repacking every time you have to put away one piece of work and take out another, it really does drag on the team’s velocity. So if you find a team or even a few individuals who are spending more than a third of their time outside their core Scrum team, that’s a flag to at least ask the question: Can we start offloading some of that work to somebody else? Can we start dedicating more time to their core Scrum team so that they can truly have a home, feel like a team, have each other’s backs, follow that pattern of dedicated Scrum teams? It’s a huge boost to productivity and can help a team find a lot of efficiencies and speed the work a lot.

Derek Hills: Those are all terrific points, Andrew. Thank you.

You know, another difficulty that teams transitioning to an Agile execution framework face is in choosing the right metrics regime to follow. A lot of programs start off with team productivity metrics—so things like velocity, cycle time, predictability—and these are important to know how much work a team can do in a Sprint, or how quickly they can turn around a user story, and if they actually do what they say they’re going to do.

But a team can be firing on all of these metrics and a product owner can still feel a little underwhelmed. Maybe they don’t feel like they’re getting the value they expected for the effort expended. And this could be because they haven’t also implemented a basket of complementary performance metrics. And performance metrics are just a way to quantify progress towards a business goal—for example, reducing process time.

And these can be difficult to get depending on your context. But if you can get that information and kind of analyze it, it can inform the makeup of your backlog and you can generate better user stories that you can prioritize to leverage that effective, efficient team more effectively and deliver more value to your customers sooner.

Kaye Burton: Thanks, everyone.

So these are just a few of the red flags that we’ve seen working on Agile transformations in the government context. And these are just some of the examples why having a dedicated Agile coach helping your team can be really helpful to help overcome some of these issues.

That is a wrap for us today. We are the Summit Agile Transformation Team. Please reach out to us to learn more or find out how we can support you in your journey.