How to mandate agility in software development, operations, and data science

Even when leaders proclaim in their townhalls that your organization needs to be more agile and nimble, they can’t mandate it. Your CIO and IT leaders may standardize on practices, metrics, and responsibilities that they describe as agile methodology standards, but they can’t dictate that everyone adopts agile cultures and mindsets.

You can select agile tools, automate more with devops practices, and enable citizen data science programs, but you can’t force adoption and demand employee happiness. IT operations may operate a hybrid multicloud architecture, but that doesn’t necessarily mean that costs are optimized or that infrastructure can scale up and down auto-magically.

So, if you were looking to quickly standardize your agile processes, or to miraculously address technical debt by shifting to agile architectures, or to instantly transform into an agile way of working, then I am sorry to disappoint you. Agility doesn’t come free, cheap, or easily. You can’t manage it on a Gantt chart with fixed timelines.

And while I believe that agility is largely a bottom-up transformation, that doesn’t mean that developers, engineers, testers, scrum masters, and other IT team members can drive agility independently. The team must work collaboratively, acknowledge tradeoffs, and define agile operating principles where there is consensus on the benefits.

So if agility can’t be mandated and requires everyone’s contributions, how do organizations become more agile? In the spirit of agile methodologies, data-driven practices, and adopting a devops culture, here are some ways everyone in the IT organization can drive agility collaboratively.

Make the case for agile methodologies 

Chapter 2 of my book, Driving Digital, is all about going from basic scrum practices to a more comprehensive agile planning process that includes assigning roles and responsibilities, planning multi-sprint backlogs, and standardizing estimating practices. When I work with teams trying to adopt agile mindsets and cultures, we establish release management disciplines, architectural standards, agile principles, and other guidelines for driving agility.

But this is not rolled out prescriptively. Different organizations have different business strategies, organizational structures, organizational cultures, talents, compliance requirements, and mixes of legacy and modernized architectures. These contexts are incredibly important when considering when and where to apply different agile practices.

For example, a large organization may have teams working on APIs for mobile applications that leaders want rapidly developed and released to employees. A second group may be working to transition a complex legacy system central to the operations of a regulated, audited, and global business.

Copyright © 2020 IDG Communications, Inc.

Source Article

Author: [email protected]_84