Selling Agile to the Team
How does middle or upper management sell doing Agile to a team that may not be too excited about being told to change how they work?
In most Agile transformations the biggest hurdle is the people who are not on board. When Agile is pushed down on existing teams, those teams can become that hurdle. What starts as a plan to improve customer value, delivery cycles, and employee satisfaction turns into a fight between management and employees. This is not a new problem. Martin Fowler, one of the original 17 creators of the Agile Manifesto, said in a blog post on October 2, 2006:
Drifting around the web I’ve heard a few comments about agile methods being imposed on a development team by upper management. Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception.
http://martinfowler.com/
Basically, Agile pushed in a prescriptive manner misses the point. The problem is companies all over are seeing real value from Agile transitions. On top of that, team satisfaction in Agile environments is generally higher than satisfaction at your company. The real question now is how do you bring your teams on board?
The most important thing to do first – figure out why you are pushing this transition on the team. Is it being mandated to you? Are you seeking higher performance? Are you chasing the latest trend? Are you trying to deliver more value? This is important. This will form the basis of everything that comes next. That’s because Agile is not a specific set of processes, tools, and techniques that the teams must follow. It is a way of approaching work that values people, collaboration, flexibility, and results over strict plans and tools. Use the reason and Agile Manifesto values to create a vision that you can sell to the teams.
With the knowledge of why you are pushing this transition you must know how important the specifics you initially proposed are. If you’re lucky they aren’t important but instead are flexible. If you aren’t lucky you are being forced to push a specific set of tools and practices down. You can work with either of these.
The next step is to realize that Agile requires a different kind of leadership than you might be used to. Instead of directing everything the Agile leader sets a goal, or a vision at higher levels, and empowers their teams for success. Take attempting to release to production more often as an example. In a classic leadership model, leadership is going to decide that the latest release of the development environment enables shorter cycle times and then dictate that everyone now must move to it. Maybe they read about it in a white paper or heard from a colleague. In an Agile environment, leadership is going to tell the team that there is a goal for more frequent production releases. The teams will come up with solutions. They may or may not include the latest development environment. They may not even be the same across the teams. Leadership is going to work with the teams to make these solutions a reality, inspect the results, and adapt as necessary.
With our goal in mind, and knowledge that Agile requires a different approach we now have other issues to address. You might be pushing a specific methodology because your management has dictated it. This needs to be part of bringing it to the teams. Assuming this methodology is a true Agile one then also bring to the teams the idea of continuous improvement. This may lead to a realization that the teams just don’t understand Agile.
Most often this can be seen in corporations where the project managers all get sent out to learn scrum. They take a two-day class, a test, and then come back chomping at the bit to put their new knowledge to work. If they have a lot of energy and the personality to back it this can force change, for about a month. It will also cost them trust afterwords. Everyone involved needs at least some training in what is happening for it to work, scrum or not. You may not need to send the entire team to get certified, but at the very least they should be given resources to learn the basics of the Agile Manifesto and how the chosen methodology fits in.
If training alone leaves the teams still wary, then applying some of the same logic Mike Cohn suggests for selling Agile to bosses can help them see a bigger picture.
Let’s return to your attempt to convince your boss to let your team use Scrum. Imagine you had focused on the benefits of Scrum rather than its features. You told your boss how using Scrum would lead to more successful products, more productive teams, higher quality software, more satisfied stakeholders, happier teams, and so on.
http://www.mountaingoatsoftware.com/ – January 20, 2015.
i.e. – Instead of just telling them to have daily stand-ups, tell them how daily stand-ups will benefit them.
After all of this, the most important thing is trust. The teams have to trust that leadership will not get in the way of the Agile transition. Leadership has to trust that the teams will work the system instead of going through the motions. As the leader looking for change you must show that you trust the team before the team will trust you. Without trust, the Agile Transition will be long and difficult.
