Agile Team Efficiency And Its Dependency On The Rest Of The Organization
Introduction
While the application of Agile ways of working has become synonymous with high performance and efficiency, several organizational (anti) patterns may kill the efficiency of Agile teams. Management overhead, unclear ways to sponsor Agile teams, security constraints, and misunderstandings about risk management may inhibit or prohibit the efficient working of Agile teams. This can often be observed in larger, more traditional organizations that limit the Agile transformation to isolated parts of the company and maintain the old ways of working everywhere else.
Management oversight
Agile teams should be treated as mini-startups. They have to be gauged on the cost-benefit scale. It means that the management should keep an interest in the Agile teams' work products and expect them to demonstrate their deliveries often. Indeed, the most popular Agile framework, 'Scrum,' states that the value to the customer must be delivered regularly - every 1 to 4 weeks.
Short-time iterations allow Agile teams to deliver value quicker, align better, and limit potential waste by investing in the wrong direction without course correction through feedback. 1-4 weeks is as far as the management oversight should reach. The team should demonstrate what value they have delivered to the customers and what impact it makes. Such demos are embedded in the DNA of Agile teams and don't clash with their operating principles.
In contrast, in more traditional environments, where Agile teams survive among the command-and-control type of policies - Agile teams are often expected to report progress in different governance bodies (e.g., 'committees') in a glossed-over format (think long slide decks). While management may have gotten used to this communication, it is not the most suitable way to judge the quality of work products. Professional knowledge workers, over time, can get very good at compiling shiny-looking slide decks that do not communicate the outcomes and impact on the customer. Instead of weekly/ monthly/ quarterly project reports - management should learn to visit the team on their 'demo days' and enquire about the customer value that has been delivered.
Sometimes, management oversight stretches into micro-management territory (potentially a symptom of the lack of trust). Micro-managing the work of Agile teams will slow them down because team members will have to report and explain every single move they make. Agile teams have an excellent solution for this - making all the work visible. Agile teams often put up and manage all their work visually on Kanban-style boards.
All tasks, statuses, characteristics, and related communication are visible online on these boards. And the best part is that everyone can preview at any time of the day. In this way, Agile teams do not have to spend time reporting their day-to-day activities because managers can simply log into the team's board and follow up on the progress of the tasks if they prefer. The only requirement is for the management to change their governance approach.
Finance
In the traditional setup, large companies usually decide on the strategic projects to pursue and try to guesstimate their scope and costs. Following this, the project teams often need help to keep up with the original (more often than not - inaccurate) plan. The management approves the project budget, and expectations are set.
On the other hand, Agile teams are made to last and take an investment to bootstrap - Agile teams build up their performance and efficiency gradually. It does not make sense to dismantle a team after it has gone through the forming, storming, and norming phases of team dynamics and has, at last, achieved a high-performance level. It is better to give this team another project to handle if they have completed the first one.
The finance and budgeting of Agile teams, therefore, must also change. The teams should be funded as groups of people with ongoing running costs and expenses. The funds can be compared to the value and benefit the team's deliveries generate for the benefit of ROI. From the accounting perspective, it means budgeting the teams instead of projects. Long-lived Agile teams are entirely predictable regarding their performance, capacity, and speed. This data can be used to estimate how much time they will need to deliver certain types of projects. Therefore, the financial planning should consider the ongoing running costs of the Agile teams and the costs of adding more teams if extra bandwidth is required for more projects.
Security
Sometimes, bringing in more security measures means slowing down the Agile teams. For example, requirements such as 3 or 4 code reviews and security reviews of everything deployed can be taken literally and implemented in a heavy-weight fashion - putting extra burden on the Agile team.
First, the CISO and the security team need to understand how Agile teams work - the iterative approach to building MVP (Minimum Viable Product) and the frequency of deployments. It requires a certain attitude - respecting these principles of Agile teams and trying to gear the security practices in a way that does not impede their success.
Second, the security by design approach has to be taken towards Agile teams.
The vulnerabilities must be reduced by continuous testing, authentication safeguards, adherence to the best security practices, automated vulnerability background scans, access level controls, and similar. Improving security without reducing the speed is the balancing act that the security team will have to play with Agile teams.
Risk management
Traditionally, risk management is assumed to be a separate controlling function in large organizations. Many other processes and policies are subjected to centralized risk management centers of expertise (e.g., Risk management units). This may lead to perceiving risk management as a burden, a mandatory addon that teams must bear. Often risk management is reduced to a formality at the beginning of projects and conveniently forgotten during the project. That is neither good for the company nor for the risk management reputation.
In Agile teams, risk management is a continuous process. Risks are uncovered during the process and immediately added to the team's backlog. They are assessed and prioritized the same way as all the other tasks in the backlog. High impact/ probability risk will be prioritized because its mitigation is paramount for the team. However, low impact/ likelihood risks will be demoted to the bottom of the backlog and may never be resolved, considering that other tasks will take priority over them.
Risk management experts in the company should recognize the difference in how Agile teams tackle risks and embrace this approach because it puts risk management at the heart of the team's day-to-day activities and makes risk mitigation an everyday practice in the team.
Conclusion
Agile teams are famous for their speed and efficiency. However, the processes, attitudes, and perceptions elsewhere in the company may become impediments and blockers for Agile teams. The burden of micro-management, confusing budgeting, security restrictions, and risk management overhead can slow down Agile teams and demotivate their members.
For this reason, the company's management needs to be open to new governance and oversight for Agile teams. The budgeting of Agile teams has to be revised, security practices have to be embedded by design, and risk management has to be entrusted to be integrated into the Agile team's workflow. This enables Agile teams to perform highly, and their efficiency stays intact.
About the Author
Jānis Dirveiks spent four years in management consulting and assurance, followed by ten years building tech products and sustainable product development processes in the fintech industry. As a practitioner at RingStone, he works with private equity firms globally in an advisory capacity. Before RingStone, Jānis facilitated Agile transformation programs in some of the biggest Nordic banks and helped build Agile product development processes in early startups. He has consulted process transformation efforts in various private and public sector companies and is an avid public speaker and proponent of Agile ways of working. Jānis holds an MSc in Global Politics from the London School of Economics and Political Science and a BA in Media & Communications from Goldsmiths, University of London. Contact Jānis at Janis.Dirveiks@ringstonetech.com.