Agile—What’s in It for the Teams?

Dec 5, 2019

As a coach who helps implement Agile and the Scaled Agile Framework® (SAFe), I’ve encountered many organizations where the product development teams (software and otherwise) are not immediately sold on Agile change. Agile tends to appeal more to the business side, less so to the ones doing the work. Why is this?

Agile—What's in It for the Teams?

The first two principles of the Agile Manifesto offer clarity. The first principle states, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Both management and development teams can agree that this is a good goal. So what’s the problem—what makes teams wary?

It’s the second principle that draws their skepticism. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

While everyone can get on board with satisfying customers, the second principle goes against everything that teams have ever learned in traditional software development, or any work being done, for that matter. Welcome changes late in development? “A sure-fire way to cause delays,” rationalizes the traditional mindset. “Late changes mean long hours and working weekends. Cancelling vacations and not being with the family. Forget leisure time!”

In the beginning, it’s typical for teams to conclude that Agile is not their friend. So what can you do to change their minds? How do you convince teams that Agile is not just another way of squeezing the last drop of work out of the staff?

In this article, I will reference Agile Principle #5 as the key to fostering healthy, productive Agile teams. I’ll walk you through it step by step while offering suggestions based on the practical application of this principle. The goal is to create a win-win for everyone, including business leaders, the organization, the coaches, the customers, and—most importantly—the teams.

 

How do you get Agile Teams to care? See Principle #5.

Agile Principle #5 states: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Let’s unpack this. The first sentence refers to “motivated individuals.” You may be wondering where you are going to find these “motivated individuals” so you can replace all the disgruntled malcontents that are currently on the team.

Remember, these people were interviewed and hired by leadership based on their background and experience. They must have held at least a sliver of promise, because out of all other candidates, they were the ones chosen. If they weren’t competent, then they would’ve been dealt with before now. All they need is for someone or something to unlock their intrinsic motivation. You could be the one to help with this.

Now that we assume that no new staffing is required, let’s look at the next sentence. “Give [teams] the environment and support they need, and trust them to get the job done.”

Agile Principle 5

This sentence contains the three areas that you must address to get the teams to care:

  1. Environment
  2. Support
  3. Trust

The more you focus on improving these areas, the more excited your teams will be to work, not to mention more willing to make changes late in development. Let’s dive into each area—what can you do to get the teams to care?

 

1. Provide an Environment of Experimentation and Continuous Learning

The team has the experience and background to best serve your needs. You can’t find a group of people more ready to do the work. So how do you provide an environment that is innovative but fun?

Start by creating an environment where experimentation is encouraged and praised. Remember that the team you have is the most qualified to determine how they should approach the work—not management, not the business owners. After all, the team is the closest to the work and the problems. If you allow them the freedom to experiment with new ideas and new solutions, then they will likely increase product value.

The team might get discouraged when a new idea does not turn out to be an improvement. Compliment them for trying. Point out that they’ve learned something to enhance their judgement going forward, even if that idea was a bust. An environment of learning and experimenting is the key to innovation. The team will occasionally get it wrong, but more often they will get it right, because they are the experts closest to the work.

When something does go wrong, please don’t fire them! Once, at a former client, I was attending a team’s morning standup when the Product Owner solemnly said, “Bob will no longer be part of the team. He made a terrible mistake yesterday while rehosting a virtual server. His mistake lost some customer data.”

The team fell silent, and the PO said, “Let that be a lesson to us all.”

I am positive that each team member took away a lesson from that standup, but was it the right one? Death of experimentation and therefore innovation? Fear became the first consideration for every team member. You do not want to support this kind of environment.

General George S. Patton said, “Don’t tell people how to do things, tell them what to do and let them surprise you with their results.” Quite a sentiment coming from one of the most successful generals in World War II!

 

2. Offer Support Using Empathy, Encouragement, and Feedback

Next, provide the team with support. Listening to them is first and foremost. Ask them:

  • What struggles are you facing?
  • Can I help by removing impediments?
  • Can I support you in your dealings with other parts of the organization?

When you give them your undivided attention and then act on what they’re telling you, they become much more willing to go out on a limb for you.

Encouragement

The other way to support the team is to provide them with prioritized work and quick feedback. This enables the team to do work that is truly valuable to their stakeholders and customers. Attention from stakeholders fires up the team and inspires them like nothing else. They feel that their work is valuable to the organization, because they hear it directly from the company leaders.

 

3. Trust the Team to Get the Job Done

Trust is the glue that holds everything together. The team needs to feel the organization’s confidence in their capability to do the work. This goes back to environment. Do you have a strong command and control culture where no one is trusted, and everyone is micromanaged? If so, then the team will be uneager to try something new and innovative. They will stick to the tried and true, what is expected and nothing more. They will minimize any risk of being punished, or worse. On the other hand, if teams are trusted and given freedom, then they become active employees who are motivated to create incredible products.

I coached an insurance company for almost a year. The teams had to upgrade the entire organization’s personal computers (65,000+ PCs) from Windows 7 to Windows 10. In the past, a similar task had taken a year to complete. Major problems had occurred, causing outages for users. This time around, with new Agile management, the team felt the freedom to do things better. They explored different possible solutions, came up with a plan, and completed the entire upgrade in three months with no hiccups. I started hearing from senior leadership. They asked, “How was this possible? What happened to the teams?”

Do you know what happened? Leadership started displaying trust in their teams.

 

Conclusion

Agile environment

If you’re a leader struggling to gain a more successful approach to helping your team be successful beyond your wildest expectations, please understand that the price you pay for changing in these three areas is well worth the business results. As you develop into a lean-agile leader, your team, your customers, and you will be happier for it.

Written by Jim Camden

 

Jim has over 35 years helping large and small companies solve painful problems in technical and organizational areas. His early career was in software for large and complex mission-critical systems. He was a developer, designer, architect, and business analyst. Jim has been intrigued by the human side of technology success for the last 20 years, which led him to Agile and SAFe. He is motivated by observing successful SAFe Transformations in organizations that benefit in tangible ways from their efforts. As a coach, he has seen the organizations he works with gain clarity in what matters and what doesn’t, and then concentrate on the former. These principles are so powerful that they work when adopted in any organization—in every sub-group, in any industry, at every level, whether co-located or distributed—despite the current level of Agile maturity within the organization and regardless of the current structure. The key is to have a coach that can make them real to you and your people.