It’s easy to say, “We’re going to be agile.” But in order to fully embrace agile and create an environment where individuals want to work together as a team, then managers—IT managers, specifically—have to be able to step back from the day-to-day workings of the development team.
Historically, IT managers have dictated daily tasks and defined priorities for their teams. As teams move to agile, they look to the product owner for prioritization of the work that needs to be accomplished.
IT managers now should focus on how to remove resource obstacles and ensure that the team has the appropriate hardware, software, and skills necessary for that work. They also can provide direction on their team members’ career and personal goals, such as helping to determine appropriate training and professional development.
Through trust and empowerment, the role of the IT manager on an agile team changes from one of dictation to one of direction and mentorship.
Trust Fosters New Ideas
Here’s a conversation that shows the difference between a manager who dictates and a manager who directs.
After being in his new job for a little more than a year, James ran into his previous manager, Susanne. They got to talking about his new manager and the team he was on.
“Susanne, how have you been?”
“Just fine. How’s your new job?” Susanne asked.
“It’s going well. I couldn’t be happier in my new role,” James responded. “I’ve got a great team and manager that look out for me as well as challenge me. I’ve had the opportunity to work on a new project that uses end-user feedback to design and implement new features. My manager continually encourages us to try new things, and it really pays off.”
Susanne sighed. “I really wish we could have that sort of environment here. How does your manager motivate people? We have people on this team who work hard, but they never go beyond the status quo. There’s no innovation.”
“It wasn’t always that way for my team,” James said. “There was a manager, Mattie, who saw the issues the team was facing by following the same old process. It was all about self-preservation and blaming other people. It left the team frustrated and unable to manage the large volume of work expected of them.
“Mattie is very headstrong. She has no problem calling out issues for what they are, which did make some people upset!
“She worked to implement a new system for the team to follow. In the past they had done typical waterfall development, and Mattie wanted to implement agile principles.
“Mattie started presenting the team with ideas for improvement and allowed the team to decide which ideas to experiment with. They tried new things, like tracking all work with paper on a wall, and pair programming. They consistently had retrospective meetings to discuss issues and implement ideas they thought would resolve them.
“Most importantly, Mattie stopped dictating our daily work to us and let the team decide how we wanted to accomplish our work. She started talking with team members about what their career goals were and suggesting training.”
“How did she get everyone on board with the plan?” asked Susanne.
James smiled. “Well, it’s not what you might think,” he said. “I mean, sure, Mattie did move the team out of waterfall and into agile, but that’s not why the team is on board with all the changes. We believe in those changes because of trust. Everyone on my team trusts each other to do their job. Management trusts team members to do their work, innovate, and try new things. It’s that trust that makes all the difference. It’s just so refreshing to work at a place that allows you to fail.”
“Fail?” asked Susanne. “How is that good?”
“Our manager and our product owner trust us to innovate, and with that innovation often comes failure as we are learning. We are trusted to fail quickly and loudly. For example, if I try something new and it doesn’t work out, my manager trusts me to come to her and be transparent about the failure. I have trust that their response is not to chastise me, but instead to ask how I plan to resolve the issue. That’s the key to our success,” James explained.
Susanne thought about this for a minute. “We often have an issue here where team members resist change and don’t want to try something new. I would like to have a team that is constantly innovating, but I’m not even sure where to start.”
“Why not start small?” James replied. “Two or three people could try it out. Maybe pick one new thing to try for a week or two. Encourage discussion and working closely together. Then talk as a team about how it worked. If they like the new way, keep doing it, and a pick new thing to try for the next couple of weeks. If they don’t like it, scrap it and try something new. But don’t stop trying.”
“That’s a great idea,” Susanne said. “I’m looking forward to trying this out.”
Create the Environment Your Team Needs
James’s conversation with Susanne demonstrates one of the Agile Manifesto’s principles: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Mattie built trust and empowered her team by taking the following actions:
- Mattie stopped dictating work and encouraged the team to solve problems on their own. When they failed, she would ask them, “How are you going to fix this?”
- Mattie suggested new ideas and let the team decide what they wanted to implement. If something wasn’t working for the team, they could change it.
- Mattie worked with team members to identify their passions and found ways to align their work and career development to those passions.
Because Mattie trusts each of her team members, they feel empowered to self-organize. The team has a strong desire to do the best they can on their projects, and, because the team owns their processes, they want to make their overall working environment as enjoyable as possible. Team members have the freedom to try new things and to fail without being afraid of putting their careers at risk.
Freedom to fail is also freedom to be wildly successful. Managers who focus on helping the team succeed create an environment of empowerment, thereby encouraging a motivated, self-organizing team that succeeds at agile.
