Enterprise-scale Agile: requires moving from ‘Us versus Them’ to ‘We’

Organisations are increasingly experimenting with ‘agile’ approaches to software development – combining incremental and iterative ¬¬¬approaches in one. To manage the risk of this change, initial experiments are understandably small and focused¬¬, targeting relatively simple solutions with few integration points and co-located teams of five to seven people.

Many of these experiments are showing success, with benefits such as faster time-to-market and more productive teams leading to enterprise-scale adoption. Both custom-developed software as well as customisation of commercial off-the-shelf (COTS) solutions, such as SAP and Oracle, are being implemented in this manner.

However, the use of agile at such a scale is yielding mixed results, despite the emergence of numerous frameworks to address this challenge, such as SAFe (Scaled Agile Framework) and DAD (Disciplined Agile Development). Therefore the solution doesn’t involve merely selecting a method, one of the key challenges with the transition to agile is the culture change, and this is further intensified when looking at enterprise-scale agile.

The ‘enterprise-scale’ environment

An enterprise-scale project environment is characterised by multiple workstreams, sub-projects and numerous teams, often including external members and/or teams that are possibly geographically dispersed. Moving from a traditional waterfall-based approach to an agile approach involves a complex transition that potentially starts with one workstream introducing agile.

Changes in the role of Business creates confusion

Arguably the biggest culture change is that business stakeholders become part of the team, notably in the form of a ‘Product Owner’ role to prioritise features / stories based on business value. While this may be intuitive for an entrepreneurial business stakeholder, such as the leader of an innovation business unit, it becomes much more difficult for senior operational business leaders that need to balance change with significant operational responsibilities. A key business stakeholder that is comfortable with the traditional role of reviewing documented deliverables will now have to play a much more dynamic Product Owner role in an agile environment. They will be called on to make prioritisation decisions much more frequently and without significant documentation to reflect on.

This situation is further complicated when there are multiple teams that are delivering through a combination of agile and traditional waterfall methods. A business stakeholder may be confused by different engagement approaches across teams, one that involves frequent prioritisation based on user stories and another that involves review and approval of all requirements in a formal specification of business requirements. This situation may call for a ‘Product Manager’ role to prioritise among different teams, some of which may be prioritising continuously based on business priorities determined by a Product Owner and others which may not be sequencing development based on business priorities.

Key recommendations:

• Review the existing project organisation structure to assess if it will support agile principles
• Clarify the role of business stakeholders, such as the Product Owner and Product Manager roles

A focus on team success drives a different culture within an agile team

An agile team environment is characterised by a different culture, with one of the main attributes being collaboration rather than individualism. Team performance becomes more important than that of the individual, which necessitates changes in the success measures and behaviours. People handle change differently and, for those new to agile, the adoption of a different way of working takes time and motivation.

Acceptance of change is another key attribute required for successful implementation of enterprise-scale agile. As the business begins to better understand agile solutions, and in response to changing external conditions, so it will adjust the priorities of the project, which will affect the project team.

In addition to the individual changes required, many large enterprises have IT operating models that do not support lean and agile methodologies. Analysis, build, test and production teams are often kept separate with different reporting lines, which can hinder agile processes.

Key recommendations:

• Gain a concession for a team, and the individuals therein, to measure success and performance differently
• Understand the competence fit for team members
• Introduce team effectiveness interventions to create self-awareness and a desire to develop required competencies
• Provide support for the behavioural change, such as through coaching

Coordination across diverse teams creates complexity

When there are multiple teams in a large, complex programme, the challenge is to resolve inevitable conflict when not all teams and stakeholders are incentivised and held accountable for team performance. For example, the integration team may be governed by 6-monthly production release cycles when agile aims to release integrated production software more frequently. If this constraint can’t be overcome, the ‘agile’ team cannot reach its goal of continuous releases of working software and so it will inevitably fall back into an incremental approach. A similar situation was encountered when attempting to scale agile at a major retailer. The integration team wasn’t ready at the end of the build cycle, which lead to a few months delay in the release of the software.

Many enterprise-scale projects employ consulting service providers and contractors. The prevailing culture can be entrenched to the extent that contracts for external service providers measure deliverables rather than working software. This was the situation at a major mobile network operator where the services agreement for an external service provider included payment conditions for the approval of Business Requirements Specification documents and the delivery of software to meet those specifications.

Key recommendations:

• Identify components that will require high business interaction because the focus on business value is a key driver of agile approaches
• Identify components with limited interfaces to other components and limited integration to prove the concept of agile (‘a thin slice of the cake’ so to speak, where the ‘cake’ is the whole solution)
• Include an integration specialist and tester onto an agile team and provide dispensation for releases outside the normal production release cycle
• Assess whether the ultimate team goal of working software can be achieved; if not, re-consider whether the organisation is ready to introduce agile

Don’t forget to leave your comments below.