Business Analysts see how everyone in an organization from the top to the bottom handles agile transformation. This unique perspective gives us insight into unique challenges faced by managers and executives that impact those who report to them. Though some of these pain points may be tough to read, we share them to help you objectively know what lies ahead so you can succeed with agile.
1. Executives’ Lack of Knowledge and Understanding
Agile is no longer a buzzword or a fad – it’s here to stay, and it’s a fundamentally different way of working. The teams doing the work need to be trained on agile, and executives need training, too. You cannot successfully support an agile transformation if you don’t understand what you are directing.
Walking the Walk
The transition to agile requires a significant mindset shift from leadership. The traditional methodology that was developed in the first industrial revolution was fine when applied to repeatable, mechanical types of projects, but it just doesn’t work for the kinds of complex, complicated technology solutions we build today.
Agile is a Completely Opposite Way of Thinking and Operating
An academic understanding and acceptance of agile is a good place to start, but executives need to truly understand what it means to be agile and be able to model it. You need to walk the walk, not just talk the talk. This is difficult. However, agile teams that try to operate without support from executive leadership will have a much harder time getting the agile process to succeed.
Measure Success Differently
You also need to be careful of what measurements and metrics you expect from your agile teams. It will be tempting to look at things like agile velocity on a team and think you can compare one team to another.
Most experienced agile practitioners and leaders know this is not something you can do. That number is merely a historical representation of the work that the team was able to do and can’t really be used to measure one team against another.
So, you will want to look for different metrics to see how well the transformation is succeeding. Some options for that include customer satisfaction, employee happiness, business value delivered, and things like that. An experienced agile team (or one that has read both of my eBooks) may try to assemble these types of metrics for you without prompting. As an executive or manager, you can also support those teams by digging into what agile metrics really mean.
2. Managers Fear Loss of Control
Another challenge in agile is that managers are going to fear the loss of control. This is because, in many ways, you are losing control. Agile teams are really meant to be self-organized, and in many respects, self-managing. Managers need to adjust to the change in the organization and maybe take on a different role.
Many of you reading this are managers, and we know how hard it can be to let go of what’s comfortable. Still, embracing agile can have plenty of rewards, and you can transition into equally valuable roles focused on servant leadership.
Servant Leadership
Leaders must adopt servant leadership. This is a significant change if you’re coming from an old-school command-and-control world where you are used to directing and controlling the work for your team. You really have to let go of that, and let the teams self-organize.
Career Guide and Coach
As you transition from an IT manager (or some other kind of manager) into an agile environment, your role is going to change. Your role will become more of a career guide or a coach. You will be there to help with training, providing tools, and being a sounding board for your team members as they work through their role on an agile team.
Leadership in Agile Roles
In many cases, we’ve seen Project Managers or IT Managers transition to become Scrum Masters, Subject Matter Experts, or even Tech Leads, depending on how they came up in the organization.
There are some cautions there: managers need to let go of the command-and-control and take on the role of servant leader, or they won’t be able to successfully transition into one of those roles. But we have seen it successfully done many times. Again, you just need to remember to let the team self-organize and self-manage. Step back and let go of control.
3. Separate Roles from Titles
This one is hard for people to do, especially if they’ve worked their way up in an organization and have a title like “Senior Architect” or “Senior IT Manager” (or whatever it might be). Many people feel like this is their identity, and it’s hard to leave this behind.
But when you join an Agile/Scrum team, you really need to leave your title and your ego at the door. If you don’t do that, then there will probably be a lot of infighting and tension, and you don’t want that on your team. You want everybody at all levels coming together to get to “done”.
The Only “Official” Scrum Roles
As you probably know already, there are only three “official” roles in Scrum: Product Owner, Development Team, and Scrum Master. There are many skills that are needed on the team. Your development team could be comprised of technical leaders, business analysts, quality assurance, database administrators, user experience, programmers, etc.
You might have any or all these skills, or maybe others like security or designers. Your team needs to have all the skills to get to “done”. If you have skills you can leverage that aren’t your key competency, you can bring those to the team.
In agile, it’s no longer about the individual – instead, it’s about the team. You won’t have any superheroes on your team – everyone should be doing everything they can to get to “done”. The team needs to work together, collaboratively and in concert to deliver on their sprint goal each iteration.
This can be a challenging transition for people at all levels, but ultimately agile can deliver top value for your organization.
