Using Agile within Cloud deployments can fail for the following key reasons:
- Culture of the firm is not democratized and does not allow for experimentation, failure, or subject matter expert control over technology components.
- The business organisation is rigid and in silos and does not understand the need to embed IT within business processes. This means that IT can be ‘agile’ but it is in juxtaposition to a business organisation that is fragile with sequential processes.
- Make a stakeholder matrix and make 100% that they are part of your Cloud-team, otherwise, they will establish barriers and areas of guerrilla resistance.
- Project management is based on waterfall, which is the opposite of Agile and iterative methodologies.
- Current state and target models are not comprehensively understood.
- Target models are too comprehensive or complex based on resources and skills available.
- Jira or other platforms to help manage Agile are not used.
- The team or teams are not trained in a particular Agile implementation eg. Scrum and do not understand the main components or artfiacts of Agile.
Some Agile-Cloud adoption mitigations:
- Understand strategic intent: Understand and evaluate the strategic intent of the business. Prepare for the cloud adoption journey by evaluating technology and understanding key adoption practices and the effects of organizational change.
- Understand what is to be moved to the Cloud, why and how. This includes understanding where the code is, the type of code you have, the purpose of the application and making sure all documentation is available and understood.
- Identify strategic opportunities: Identify opportunities to accelerate digital transformation by acknowledging maturity levels across capabilities.
- Ideate and prioritize: Evaluate and prioritize ideas and recommendations; leverage attributes such as feasibility, impact, and cost to prioritize transformation activities.
- Make a plan that is sensible regarding ROI, competitive advantage, IT improvement and process improvement. Importantly, the plan should be incremental, not a huge leap from a mess to a nirvana of complete automation. This is not realistic. An example is to lift and shift, then eventually over time automate.
- Pilot and prove: Test, prove, and pilot the recommendations; identify measurable outcomes, prove capability and validate with end users and against business-driven measurements.
- Scale: Scale while validating with end users; take iterative steps to validate approaches, confirm technical decisions, and begin adoption to cloud models at scale.
- Train the IT staff into understanding what Agile means, what tools are needed and how automation plays a critical role in IT transformation (eg CI/CD, automated testing, POCs).
- Train PMs or install only Technical PMs who can both architect and run the Agile implementation. Most PMs are trained in PMBOK, CMI and other apocrypha, which are heavy on paper, light on results.
- Map your project milestones into the Agile tool to form coherent and relevant sprints and deliverable cycles.
- Lose Waterfall. Please, throw the Gantt charts, the minutiae, the 5-hour meetings into the trash-bin where they belong. This is not World War II and you are not mobilizing the entire width and breadth of society to fight Fascism. IT is iterative by nature. So too is a business process.
- Most importantly: implement a culture of technical proofs of concepts; fast-fail; learning; no-shame and no-blame. Cloud is the great vehicle to embed IT within the Business. But trying to force an Agile IT deployment model, into an ‘un-Agile’ Business structure, will create conflict and likely failure.
Agile can fail, but it is usually the mal-adaption of Agile, the inability of the organisation to understand what Agile can deliver, and a mentality and culture rooted in the top-down ethos of centralized planning, which are to blame – not Agile as a concept.