Going from “doing agile” to being agile

Editor’s note: Bill Murray is a startup mentor/innovation catalyst with American Family Insurance.

Working “agile” can come with a lot of frustration. You’re doing all the right things. You have a daily standup. You have a backlog. You’re demoing your work with your customer. So why does it feel like you’re still working the old way? Agile promised better outcomes like faster results, better alignment to customer needs and improved team morale … but you’re still buried in work and your customers are almost as unhappy as your team. What gives?

The benefits of working agile don’t directly come from rigid execution of scrum ceremonies. Agile is a mind-set that drives how you approach your work. When teams start working agile, that mind-set is still developing and won’t start to impact the work for a while. What I’ve seen is that when teams set up the traditional scrum ceremonies and go about them with an experienced coach or scrum master, the development of that mind-set is significantly accelerated. Below I’ll share some of the signs of evolution from different agile ceremonies and tactics that I look for as I help teams go from just “doing agile” to being agile.

Get a sponsor for your agile journey

Where to start? Get a sponsor or product owner. This person will own the team’s work and clear obstacles that would ordinarily slow a team down. The coach should be meeting with the sponsor regularly to help guide their agile journey. Sponsors are often tempted to manage a team at the outset, but quickly learn to mentor instead. Their value comes from the great questions they ask the team about their work, rather than a series of directives that limit the team to the sponsor’s assumptions. 

Working with the sponsor, inventory the skills of the team. Do you have the right mix of talent to do the kind of work you’ll be expected to do? If not, how can you procure it permanently or on-demand in a way that doesn’t slow the work of the team. Over time, the team will become less an assemblage of individual talents working in silos, and instead a blend of multiskilled team players with good communication who can seamlessly move from task to task.

Decide how your team takes on new work

An important early step is building your intake process. How will your team take on new work? What is in, and more importantly, what is out of scope for this team? How do you learn what you need to learn to develop a clear understanding of your customers’ outcomes in the work they bring? Watch for this process to change and improve with each intake cycle. Early team frustrations will come from taking in all work, taking in out of scope work or simply not having a good idea of the scope of what they should take in. Sponsor support is key here. The transition to being agile comes with a radical bias to learning and a finely tuned intake is the front door to that learning. 

Great agile teams say no to some work and maybe to other work by breaking it down and testing value quickly before committing to a lengthy build.

Prioritize tasks

Once work is selected and scoped, prioritize the tasks that should be accomplished to drive the customer’s outcome. Here is where a lot of evolution will take place quickly. Initially, teams will tend to cherry-pick the backlog for low-risk or easier items to complete or avoid items that feel “scary” because there’s a risk that the customer might reject the work product. They’ll soon see that this behavior doesn’t move them very far to learning the right things to be able to answer the “how do we build it well” question. As early as the team’s first retro, you might hear:

• “We’re not learning what we need to learn and building too soon.” 
• “We’re not doing a good job of breaking work down.”
• “We’re not approaching our work in a logical way.” 

These are great signs of progress, and an opportunity to help the team improve how they work. 

Change the way you discuss work progress

Daily standups will change with the right mind-set. Most of us are used to the typical share out meeting and the early standups will mirror that habit. This is where the coach can change the behavior quickly. Instead of an open status update that could be similarly accomplished by e-mail, the coach can prompt the team. 

• “Is there anything we’ve committed to for this sprint that’s in danger of not being completed?”
• “Are there any blockers that are slowing you down?”
• “Are there any resources that you require to keep you moving quickly?”
• “What epiphanies have you experienced that may impact other people’s work in the sprint?”
• “Has anything changed since we planned this sprint that might change what we will deliver to our customer at the next demo?”

These prompts will help reinforce the value delivery mind-set and prevent needless rehashing of work progress. In a standup, the assumption is that all work is going as planned, unless you say otherwise.

Reflect on the big picture

The backlog refinement session provides a great opportunity for the team to reflect on the big picture in a low-pressure environment during the sprint. Early conversations might get hung up on the priority of one task or another as team thinking is still mired in a “build” mind-set. Careful reframing of those conversations can help the team reflect on what they’ve learned and how that learning relates to the customer’s outcomes. Once this begins to happen, the coach or sponsor can ask the team the key question, “How does what we’ve learned help us understand what – and how much – to deliver to our customer?” In that conversation, priority becomes much clearer, and teams begin to see outputs as dynamic milestones to static customer outcomes.

Embrace customer feedback

At demo time, everything comes together – or falls apart. New teams may fail to have a product ready to demo, or a product that doesn’t give much opportunity for customer feedback. Customer comments may fall on deaf ears. Here are two signs the team hasn’t quite connected customer wants to real outcomes:

• “The customer just doesn’t understand what we built!” 
• “We build what they asked for!”

The team retro provides a safe place to reflect on the work and why the customer reacted as they did. Evolving teams will identify the problems and coaches can help them get to the root cause. Then they can figure out how they’ll fix it. Great teams embrace all customer feedback and use it to improve and move forward. They recognize opportunities to do less more often, to learn more and speed the product development process. They talk in terms of stop, pivot and persevere every time they learn something new or get customer feedback.

When research and insights are agile

Research work is a product that begs to be built in an agile process. Your customer needs to accomplish something, and your research product is the bridge that they hope will get them to that outcome. Overbuilding the right thing will confuse your customer and delay or even prevent them from getting value from your product. Building the wrong thing can hurt your reputation and it also wastes precious resources.

Over time, with the right support from a sponsor and coach, the team will change how they think from a product (output) mind-set to an outcome mind-set. When this happens the real fun begins, because their work moves beyond making stuff to solving problems. That mind-set changes people’s personal and professional lives in a profound way and it’s what drives my passion for coaching teams