There is much written about the changing roles of Development and Operations staff when organisations undergo agile/devops transformations. But what about the changing role of the Team Leader?
In pre-agile environments, as a Team Lead, your role is one of structure and co-ordination; it is through you that work routes. You know the skills and capacity of your team and are regularly making decisions about what can and can’t be done.
But as your team starts to work in an agile way, the need for you to keep them busy is reduced, as this is now a responsibility of the product owner and agile team itself.
You may find yourself with increased responsibility during this transition, as you may be asked to initially take on the role of the product owner. This first step fits in well with the current structure, But over time, that may change. As the business matures and identifies more appropriate product owners the responsibilities will shift.
You might find yourself asking “Do we need Team Lead’s in an agile/devops culture?”, and if so “What value can I provide?”
You don’t get to be a Team Lead unless you have great people skills, the ability to think broader than others and a drive to get things done. So lets not waste that skill, but repurpose it to lead these new agile teams to deliver value faster and more confidently.
CHALLENGE THE TEAM TO LEARN FROM FAILURE
Be a voice for deeper understanding about what causes issues. As we start to work in a new way, with new responsibilities we are destined to fail. Help the team understand that failure is ok, but only if we learn from it and work hard to not fail the same way again.
As Development teams start taking on more Operations responsibilities, make sure to include everyone in production incidents and post mortem activities. Production issues on newly formed teams can either split a team apart, or pull them together. Make sure to focus on what went wrong, not blaming people for the failure. One way to do this is through holding blameless postmortem sessions after incidents. Use these sessions to challenge the team to identify what the root cause of the problem was and if this issue could have been picked up or mitigated earlier in the workflow.
Champion the learnings and improvements identified in this process be prioritised in the backlog of work for the team.
EMPOWER INCREASED CAPACITY THROUGH AUTOMATION
Just because we have merged our Development and Operations teams doesn’t mean that the rate of change expected from us is going to decrease. Initially you will probably end up with bigger teams, and so the business expectation is that you can do more.
Reality is that this type of transformation actually slows down output for a while, as team members settle into new responsibilities, get to know team members, and technologies they have not been used to.
After the initial Forming and Storming stages of team development, these new teams will be expected to deliver much more value than any of them have expected.
Make sure from day one, that there is a strong focus on identifying what repetitive actions the team is tasked with doing, and put a plan in place to automate these away. By validating where effort is being spent, you will be in a strong position to negotiate with the teams product owner on why the investment in this automation benefits everyone.
Take a look at how long it takes to release changes to production, or perform a regression test. If there is a lot of manual effort in these tasks, then they are probably great candidates to start an automation activity.
DRIVE UNDERSTANDING OF NEW CAREER OPTIONS
As a team leader, one of your key responsibilities is to know your team. What drives them to come to work each day, what challenges would they like to tackle and most importantly where do they see themselves going.
By uniting the Development and Operations capabilities, your team members will have new paths through their future career open, this may even cause strong conflict as they question what their next steps forward are.
Use the skills you have developed as a Team Leader to help your team understand the amazing opportunity this transformation has gifted them. They now have the chance to extend their skills beyond a single role. For some this will be a challenge, but for others it will energise them as they now have the ability to influence areas previously out of reach.
EDUCATE ON THE RESPONSIBILITY OF PRIORITY
From great power comes great responsibility – this is no more true than the role of the product owner in an agile team. The power of the product owner to set priority is one of the critical elements to a successful team. A weak product owner that is constantly being pushed around to change priority causes interruption to the flow of the team, while an overly dominant product owner that sets priority without taking feedback is destined to build the wrong thing.
As a Team Lead, whether you are playing the role of product owner or not, you have a position of influence to ensure that the approach being used to prioritise work into the team is appropriately considered.
With a joint Development and Operations responsibility, your new team has an increasing reliance on good prioritisation.
One way to evolve Agile for Projects into DevOps is to create some prioritisation guidelines. Engage the product owner to assess each of the new demands on the team against this list first to see where they should start the prioritisation discussion.
A starter list might look like:
- Activities that restore a production service that is failing
- Tasks that enable us to learn from recent failures
- New business functionality that has been appropriately groomed and estimated (up to 80% of our capacity)
- Team generated items that will have a direct reduction in regular effort
- Refactoring work to reduce our technical debt
With an agreed starting point with respect to how important new demands on the team are, you should be able to measure and assess if the list is working, and if not alter it until the desired outcome is achieved.
MOST IMPORTANTLY – TREAT THEM LIKE ONE TEAM
To truly embrace a devops transformation we need to start sharing the love and the pain across the whole team. Resist the temptation to have a team of Developers and Operations staff members that sit together, and push hard to enable every one to contribute some value at all stages.
This does not have to mean force your Developers to carry pagers and fix production incidents, or have your Operations staff members learn how to program, but it does mean that there needs to be a healthy respect and understanding of each others skills.
There are also a large number of tasks that fall outside the exclusive domain of Development and Operations, these are the areas that are often the best starting place when it comes to cross-functional teams.
These activities can be:
- Get everyone involved at the design stage of a new feature
- Include all team members in production incident reviews
- Enable all team members to test new functionality
- Ensure everyone has a voice when grooming new features
- Empower everyone to contribute to team ceremony facilitation
Remember you can be a member of the team too, and your experience from leading a team will be invaluable, as long as you are close to the team and have the ability to impart your experience. By understanding the values of devops you can help lead your team through this transition to a place where they feel ownership of their future, trusted to make the right decision and empowered to make things better.
Your changing role is to enable the team to get the work done, not to tell them what to do.
