Enabling Agile Teams
The efficiency of Agile teams depends on the interrelationship with the rest of the organisation
While the application of Agile ways of working has now 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 organisations 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 min-startups. They have to be gauged on the cost-benefit scale. It means that the management should keep an interest in the fruits of the Agile teams and expect those teams to demonstrate those fruits quite often. Indeed, the most popular Agile framework ‘Scrum’ pertains that the value to the customer has to be delivered on a regular basis – every 1 to 4 weeks. That is as far as the management oversight should reach. The team should demonstrate what value have they 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 are surviving among the command-and-control type of policies – Agile teams are often expected to provide reports on their progress in different governance bodies (e.g. ‘committees’) in a glossed-over format (think – slide decks and charts). While management may have gotten used to this way of communicating – 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 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 a great solution to that – making all the work visible. Most often Agile teams put up and manage all their work visually on Kanban-style boards. All the tasks, their status, characteristics and related communication can be found online on these boards. And the best part is that – they are available to everyone to 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 so. The only requirement again 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. This is followed by the project team struggling to keep up with the original (more often than not – inaccurate) plan. The project budget is approved by the management and expectations are set. Agile teams on the other hand are made to last; the idea is that teams work in Agile ways to gradually build up their performance and efficiency. 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 their running costs and expenses that are ongoing. Those than can be compared to the value and benefits the team’s deliveries are generating. From the accounting perspective, it means budgeting the teams instead of projects. Long-lived Agile teams are quite predictable in terms of 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 simply 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 everying that is being deployed can be taken literally and implemented in a heavy-weight fashion – putting extra burden on the Agile team.
First, it is important for the CISO and the security team to understand the way Agile teams work – the iterative approach to building MVP 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 have to 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, in large organisations, risk management is assumed to be a separate controlling function. Many other processes and policies are subjected to centralised risk management centres of expertise (e.g. Risk management units). This may lead to perceiving risk management as a burden, a mandatory addon that teams have to bear with. 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 prioritised in the same way as all the other tasks in the backlog. High impact/ probability risk will be prioritised 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 recognise 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.
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 – all have the potential to not only slow down Agile teams but also demotivate their members. For this reason, the company’s management needs to embrace new governance and oversight mechanisms concerning 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. In this way, Agile teams are enabled for high performance and their efficiency stays intact.
