Today’s post is from one of our Certified Scrum Trainers: Julie Chickering. I’ve known Julie for 15 years. I always love hearing or reading her views on Scrum and agile. With Mountain Goat Software, she delivers both our CSM and CSPO courses. Interested in Training with Julie? Click here to see her upcoming certified Scrum course dates. --Mike
Frameworks like Scrum are fantastic for solving business problems, and companies continue to transition to agile to achieve objectives. But problems can occur if they forget that agile is just a methodology—a means to achieve a goal—not the goal itself.
Scott Dunn wrote a great article about the pitfalls (and dread) associated with a management decision to suddenly ‘go agile’. It reflects the delusion that it’s a simple implementation—like switching stationery suppliers—rather than a framework that requires a significant change in mindset.
“Amazon is doing it."
These are both good indicators that the business hasn’t clearly defined why they want to use agile, and “why?” is one of the first questions I ask when working with a company transitioning to agile, or when teaching a certified Scrum class.
I often get answers such as:
- We want to adapt quickly to change
- We want to make continuous improvements
- We want to ship more regularly
On the surface, these sound like great goals and they align with the outcomes we expect from an agile methodology.
But even noble-sounding goals can cause problems and frustrations when you pursue them without defining them properly.
How do you know you’ve chosen the right goal?
Let's say my friend tells me he wants to make an additional $100,000 in the next 12 months. I would probably encourage him to pressure-test this goal to see if it is what he actually wants.
The Five Whys is a well-known approach to discovering an underlying root cause of a problem and it also works well to discover underlying motivations for pursuing a goal.
If I ask my friend why he wants the $100,000 he may respond that it’s to improve his status, or perhaps he says he wants to completely remodel his home.
If we apply another why, we may uncover a deeper layer of what is important to him about these things. He might then say that status is important to him, to prove to his parents that he’s successful. Or he wants to remodel so that he’s excited to come home at the end of the day.
As you continue to push through why something is important, you can start to review the original goal and ask: Is it the right one, and is it defined clearly enough?
For example, maybe my friend doesn’t need $100,000 to prove to his parents that he’s successful, maybe he just needs some life-coaching to realize that he’s good enough. And perhaps all he needs to enjoy coming home at the end of the day is a best friend to greet him.
A Good Goal also Needs Good Guidelines
After a bit of discussion, my friend decides that he definitely wants the cold, hard cash.
How should he achieve this?
He could rob a bank. Or acquire the money through a Ponzi-style cryptocurrency scam.
Should he consider those options?
Well, since my friend isn’t a criminal mastermind, there’s a good chance he’ll get caught and lose his liberty. He’s also a really decent person, so the idea of committing a crime would likely be upsetting to him.
So probably not.
Clearly, we recognize that in addition to choosing the right goal, he also needs guidelines on how to achieve that goal (e.g. not breaking the law) and not compromising things that are important to him such as his freedom and his values.
When You Have the Right Goal, But the Wrong Execution
I knew a senior vice president who wanted to use Scrum to improve collaboration.
That’s a perfect goal for this kind of agile framework. However, he also believed that collaboration could only be achieved if the team physically worked together. As a result, he moved everyone into a small, cramped room, and insisted that all work and discussions happen there, with the entire team involved.
This wasn’t just uncomfortable; it also meant that one member who had previously spent a few days working from home now had a daily three-hour round trip commute.
Morale and the quality of work began to suffer. When I came in to see why agile wasn’t working for them, I started by asking why he wanted to improve collaboration.
He told me that he wanted team members to:
- Understand what other people were working on, identify gaps, or see where members were overworked so they could help one another
- Confidently and quickly discuss solutions to problems
- Communicate with each other in a way that was simple and clear
And we realized that none of those things actually required anyone physically sitting next to someone else.
Looking at the situation again, the VP realized that “collaboration” didn’t mean proximity—and we were able to reexamine different ways they could work to achieve the real goals.
When You Forget the Why, It’s Easy to Become Divided
I worked with a Scrum Master who was new to a team. When she discovered they had modified some of the rules, in her eyes they weren’t doing Scrum properly. As Scrum Master, she felt it was her role to correct the team, and ensure everyone was doing Scrum in the right way.
To do this, she doubled down on the rules, highlighting the team’s mistakes and advising what they should do instead. But the more she pushed, the more people pushed back, and it became a toxic environment of endless disagreements.
I asked her why it was so important to enforce those ways of working. She replied:
“Because that’s how I used to work with my previous team and we were really successful.”
I asked her to describe what it was like to be on that team, and to share why she thought they worked so well together.
“We clicked. We were cheerleaders for each other even when we made mistakes. We knew each other’s strengths, we never worried about stepping on toes, we really felt free to go in and do our best work”
At no point did she say:
“Because they followed the Scrum framework perfectly.”
When we took a step back, we saw that her strictness about the rules was causing tension, mistrust, and decreased productivity. Her overarching goal was to be a high-performing agile team, but her short-term actions were directly in conflict with it.
Instead of focusing on the things her team did differently, she began to look at the goal they all shared—to be that great agile team—and she decided to focus on what was working well and build rapport, rather than trying to fix everything she thought was broken.
If you want to try to avoid similar agile problems, here are my recommendations:
Pressure-Test the Goals and Make Sure the Guidelines Are Clear
If your organization is transitioning to agile, encourage managers to pressure-test those goals where possible. Be inquisitive: find out what’s really important. Strip ambiguity away from that which you want to achieve as a team, so that you can be creative with your approach rather than boxed in by arbitrary rules.
And consider the cost you’re willing to pay, as well as where you won’t be compromised. Is team morale important? Is it better to attract fewer clients with realistic promises, to deliver more reliably and build more repeat business?
Pursue the goal at the team level
One of my favorite non-agile books is The Culture Code by Daniel Coyle. In it, he examines what makes certain groups successful and shows leaders how to build a cohesive, motivated culture. With sports teams he found that success was often related to the many selfless passes made by team members, to how individuals put the team’s success above individual glory.
I see the same thing happening with successful agile teams. One team I worked with was delivering on time, but it became apparent the designer was overworked. Instead of considering their own individual capacity when planning and picking tasks, members started to think about team capacity. They decided that if one person was struggling, they were all struggling. A developer dropped some of her own backlog items to spend some time learning design and trying to help. The team decreased velocity short-term, but in the long term they began delivering more, since they had more broadly developed skills. If they had simply focused on delivering as many features as possible in each iteration, this long-term progress may never have happened.
Is Agile Helping You Reach Your Goals?
I’d love to hear about your experience. Are goals clearly defined and understood? Or have you ever felt you were following a business plan built on buzz words? What have you found works well when using Scrum and agile to solve a business problem or achieve an objective?
