When the goal (direction) of agile is wrong

Time:2021-2-4

Frameworks like scrum are great for solving business problems, and companies are constantly transitioning to agile to achieve their goals. However, if they forget that agile is just a methodology (a means to achieve a goal) rather than the goal itself, there will be problems.

Scott Dunn wrote a great article about working withManagement’s decision to suddenly “become agile”About the pitfalls (and fears). It reflects the illusion that it is a simple way of implementation (such as changing suppliers), rather than a framework that requires significant conceptual change.

“Amazon is doing that. “

These are good indicators to show that the enterprise has not yet clearly defined why to use agile, and “why? “Working with companies to transition to agile or teachingCertified scrum coursesThis is one of the first questions I want to raise.

I often get answers like:

  • We want to adapt quickly to change
  • We need to keep improving
  • We want to deliver more regularly

On the surface, these sound like great goals, and are consistent with what we expect from agile methodology.

But even if you don’t clearly define goals, even goals that sound good can cause problems and frustration.

How do you know you’ve chosen the right goal?

Suppose my friend tells me that he wants to make another $100000 in the next 12 months. I might encourage him to stress test this goal to see if it’s what he really wants.

Five whys“It is a well-known method to find the root cause of the problem, and it can also find the fundamental motivation to pursue the goal.

If I asked my friend why he wanted the $100000, he might reply that it was to improve his status, or that he wanted to completely rebuild his house.

If we add a “why”, we may find something deeper about these things that are important to him. Then he may say that status is important to him to prove his success to his parents. Or he wants to reinvent himself so that he will be happy to be home at the end of the day.

As you continue to explore why something is important, you can start to review the original goal and ask: is this the right goal and clearly defined?

For example, maybe my friend doesn’t need $100000 to prove his success to his parents, maybe he just needs some life guidance to realize that he is good enough. Maybe everything he needs to go home at the end of the dayGreeting his best friend

A good goal also needs good guidelines

After some discussion, my friend decided that what he absolutely wanted was cash.

How should he achieve it?

He can rob the bank. Or get money through Ponzi style cryptocurrency scams.

Should he consider those options?

Well, since my friend is not a crime planner, he is likely to be caught and lose his freedom. He is also a very respectable person, so the idea of crime may make him unhappy.

Probably not.

Obviously, we realize that, in addition to choosing the right goal, he needs to think about guidelines on how to achieve that goal (such as not breaking the law) and not damaging things that are important to him (such as his freedom and values).

When you have the right goal, but the execution is wrong

I know a senior vice president who wants to use scrum to improve collaboration.

This is a perfect goal for this agile framework. However, he also believes that collaboration can only be achieved if the team actually works together. As a result, he moved everyone into a small, narrow room and insisted that all the work and discussions were there, with the whole team involved.

This is not only uncomfortable; it also means that a member who used to work at home for a few days now has to commute three hours a day.

Morale and the quality of work began to suffer. When I came in to see why agile didn’t work for them, I first asked him why he wanted to improve collaboration.

He told me that he wanted team members to:

  • Understand what others are doing, identify gaps, or see where members overwork so that they can help each other
  • Discuss solutions to problems confidently and quickly
  • Communicate with each other in a simple and clear way

And we realize that none of these things actually require anyone to sit next to someone else.

The vice presidents looked at the situation again and realized that “collaboration” does not mean that they have to sit together, and we were able to re-examine the different ways they might take to achieve their actual goals.

When you forget the reason, it’s easy to be split

I work with a scrum master who just joined the team. When she found out that they had changed some rules, in her eyes, they didn’t execute scrum correctly. As a scrum master, she felt that it was her responsibility to correct the team and ensure that everyone did scrum in the right way.

To this end, she studied the rules carefully, highlighted the team’s mistakes and suggested what they should do. But the more she pushed, the more people she knocked down, which became a harmful environment of endless disagreement.

I asked her why it was so important to force them. She replied:

“Because that’s the way I used to work with previous teams, so we were really successful. “

I asked her to describe the team and share why she thought they were doing well together.

“We did. Even if we make mistakes, we are each other’s cheerleaders. We know each other’s strengths, we never worry about stepping on our feet, we are really happy to go in and do our best. “

When we stepped back, we found that her strictness of the rules caused tension, distrust and decreased productivity. Her overall goal is to become an efficient agile team, but her short-term actions directly conflict with it.

If you want to avoid similar agile problems, please refer to the following suggestions:

Stress test objectives and make sure they are clear

If your organization is transiting to agility, encourage managers to stress test these goals where possible. Keep curious: find out what’s really important. Disambiguation and the fuzziness of teamwork, so that you can be creative in your own way, instead of being bound by arbitrary rules.

Think about what you’re willing to pay and where you won’t be harmed. Is team morale important? Is it better to attract fewer customers to fulfill commitments, provide more reliable services and build more repeat businesses?

Pursue goals at the team level

One of my favorite non agile books is by Daniel CoyleCultural code. Among them, he studied the factors that made certain groups successful, and showed leaders how to build a cohesive and aggressive culture. In sports teams, he found that success is usually related to many unselfish passes made by team members, and how individuals put team success above personal glory.

I think the same thing happens to successful agile teams. A team I work with delivers on time, but obviously the designers work overtime every day. When members plan and select tasks, they don’t consider their own personal ability, but start to consider the team ability. They think that if a person is struggling, they will all feel bad. Developers give up some of their backlog, spend some time learning design and try to help. The team slowed down in the short term, but in the long run, because they have a wider range of skills, they start to offer more. If they just focus on providing as much functionality as possible in each iteration, this long-term progress may never happen.

Is agile helping you achieve your goals?

I want to know about your experience. Are goals clearly defined and understood? Or did you ever feel like you were following a catchword based business plan? When using scrum and agile to solve business problems or achieve goals, what do you find to work well?

What about all your Agility? Is there a focus on the ultimate goal? What puzzles do you have in the process of agile transformation?

Welcome to discuss

This article first appeared inBob Jiang’s blogFor reprint, please contactBob Jiang