Focus On Team Autonomy
One of the main propositions of the agile manifesto is that the team is in the best place to make decisions on what can be achieved and by when. The team therefore requires the autonomy to make these decisions.
Leaders need to be able to assess the team’s ability to manage themselves autonomously, to guide when required and also step back. Organisations also need to understand what supports team autonomy and what constrains it.
In A Nutshell
The Agile Manifesto refers to self-managing teams as the source of “the best architectures, requirements, and designs”. However, according to Viktoria Stray, Nils Brede Moe, and Rashina Hod, the authors of Autonomous agile teams: Challenges and future directions for research, the performance of an autonomous agile team depends not only on the ability of a team to execute its work, but also on “the organizational context provided by management”.
The authors mentioned above organised the first international workshop on autonomous agile teams at XP 2018 (The 19th International Conference on Agile Software Development). The workshop highlighted 5 of the top barriers to autonomous teams:
not having clear and common goals: if there is ambiguity around the organisation’s direction of travel the team will struggle to identify where they fit. This, in turn, is likely to impact their ability to co-ordinate.
lack of trust: this can be between team members and the team and management. Issues such as fixed cost pricing and other externally imposed constraints are likely to fuel divisions.
too many dependencies to others: the constant need to align and coordinate with other teams, managers and stakeholders limits the teams ability to make decisions that positively impact their performance.
lack of coaching and organisational support: teams can struggle to find a sustainable rhythm and managers can lack the training and/or ability to coach the team.
diversity in norms: norms are informal rules that a team adopts. Without guidance, the norms that take hold in a team may not support autonomous team working and may be out of kilter with others teams that they interact with.
It can be seen from the above that leaders at all levels within an organisation have a large role to play in supporting team autonomy.
Leaders close to teams need the rigour and discipline to assess their role and their relationship with the teams. They will need to be able to help the team set their direction of travel. They will need to help the team to adopt, and rigorously adhere to, a set of disciplines that will support their autonomy. They will also need to agree what transparency is required so that the leader doesn’t need to get involved where they are not needed. Whilst considering all these factors, they will need to assess the team’s maturity to self-manage and provide support and guidance in line with this.
Peter Koning in his book, ‘Agile leadership Toolkit’ suggests a simple graph with the X-axis being ‘Maturity’ and the Y-axis being ‘Freedom’. Too much freedom with too little maturity will lead to ‘chaos’. Conversely, a mature team given little freedom will feel like they are held ‘captive’. More details can be found here.
Leaders at an organisational level will also need to play their part. They will need the rigour and discipline to continually remove constraints that may impede team automation. Legislation, reporting lines, safety and security practices, legacy systems and standardisation across the organisation are all likely to impact team autonomy.
Practices
Blameless Post-Mortems are adopted as part Google’s Site Reliability Engineering framework. The concept has existed for sometime as part of traditional Service Operations. Its use within SRE shows its adoption in "DevOps” too. In this context, post-mortems are used to analyse the causes of operational failures and to decide how to improve the situation.
The team or wider organisation may readily identify that there are problems with its current way of working, that it wishes to improve its performance, or change its technology. Understanding the problem is inherently simpler than identifying a solution. Even if a potential solution is evident, we may be uncertain about its effectiveness. We experiment with changes to understand whether they will be effective and, if so, the extent of improvement we can realise.
We review the flow of work through our system, paying attention to the overall rate of flow and to bottlenecks as work flows through our process. Where bottlenecks are identified we seek to understand the root causes of each bottleneck. With this understanding we relieve the constraints by experimenting with changes to our process. Where we see examples of accelerated flow, we look for practices facilitating this acceleration. We experiment to find ways to incorporate these practices into our process.
Sprint Planning is a Scrum event that is held before the start of the sprint to establish the scope and priorities of the coming sprint. Its purpose is for the whole team to establish an agreed sprint goal based on the Product Owner’s view of the value that can be created for the customer. To establish a scope of backlog items that can be got to done. For each backlog item the team decides how done will be achieved.
The Sprint Retrospective is a Scrum event. Its purpose is to allow the team to inspect and adapt its way of working, the functioning of the team, the working context and all other factors which may impact the team’s ability to deliver its goals. Some factors the team have direct control over, other factors will require external influence to change.
Stop the Line is a practice in Kanban. Whenever a defect is detected downstream of the point where it should have been eliminated, the line is stopped. The team take time to identify and explore the reasons for the escape of the defect. They decide what action to take to prevent defects of the same type escaping in the future. Best practice also uses Stop the Line to identify and reinforce modified practice that brings performance benefits to the work of the team.
The Product Backlog is the vehicle by which needs are turned into requirements and requirements are turned into operational features in our product. It is a prioritised list of the work that the team currently intends to deliver in the next period of time. The less imminent a feature is, the less well it will be defined.