Is Agile the Right Answer? Depends On the Tech Project
The Leading Edge
Research-led advisory programs helping senior leaders accelerate their business outcomes of technology-enabled change
"Unlocking Next-Level Enterprise Strategies with Kevin Cunningham ."?
Let’s not kid ourselves; any sizable organization’s path to Agile nirvana is paved with potholes. ?Even our modern organizations grapple with outdated systems, processes, and red tape. Post the dot-com bubble burst, the gurus touted Agile as the antithesis to stifling and inflexible development environments.
Now, Agile is often seen as the go-to approach; considered the perfect match for the rising demand for product innovation and enhanced digital customer experiences. Its strength lies in promoting adaptability and swift iteration. And it’s impossible to ignore the successes of Agile development in today’s software-defined world. ??
Yet, the past few months have brought client comments sharing frustration with the method. Agile teams can find themselves underdelivering – or slowing down results when a situation isn’t well suited to?“run fast and break things, rinse and repeat.”?This prompts the question: Are we always applying Agile in contexts where it works best?
To help us solve this dilemma – let’s use?Wardley Mapping. ?A Wardley map places components within a value chain and anchors them by user need. ?The horizontal axis traces an evolution, from genesis to commodity. ?The vertical axis showcases the visibility to a user. ?For example, here is a simple view of a Wardley Map for a tea shop:
Understanding this methodology, we can apply this to an entire systems landscape of a typical organization. ? ?
In reviewing an organization’s tech estate, a landscape emerges with applications, solutions, and technologies in this hypothetical situation. ?We see where there is higher visibility to customers’ and engineers’ needs, but also which components are further along in their paths to becoming commoditized. That said, this horizontal axis begins to beg the question: [Insert William Shakespeare’s Hamlet voice]?
“To agile, or not to agile?”
Certain areas of the map may benefit from traditional development approaches. There are areas that require extreme levels of integration, millions of lines of code testing, security and disaster recovery thresholds. ?Components where a high degree of methodological work is required may see the larger benefits of traditional approaches. Nuances also exist; there is a case to be made for implementing smaller batch sizes and increasing the number of tests in an agile fashion to reduce the overall risk of the implementation.?
Conversely, we can also begin to align components to where agile methodology makes the?most?sense. ?Let’s say you’re working for a major insurance company and you’ve got a new approach to underwriting that utilizes machine learning to curate risk profiles for your customers. ?There’s a strategic competitive advantage if you can iterate at full speed on that ML model. ?This is where Agile is a clear winner.?
One could even make the argument that between those two options is the scenario where an organization should consider?“buying”?instead of?“building”?with a focus on reducing resource spend. ?These are occasions where deeply skilled vendors with hardened platforms and ecosystems can obtain an organizational advantage of focusing on managing the business, not the IT.
Utilizing these spectrums enables a debate about dev methods, and even build versus buy. ?The essence of Agile is its flexibility. ?But let’s not forget that the very functions that make Agile so appealing can, in certain contexts, become its Achilles heel. ?
DXC is known for delivering mission-critical,?dependency-rich tech projects embedded across many core systems. We understand that sometimes iterating through agile methods might also be risky and inefficient.? There are places to leverage off-the-shelf versus scratch builds. There are places where we need to go fast and iterate, and places where breaking things is just too risky. There are places where an ever-changing tech landscape can meet challenging customer expectations. If we choose well, this creates environments where many dev methods thrive; fostering collaboration and open communication. ?
With that said, if I handed you a map and corresponding legend…how would you plot your tech estate?
Discover more https://dxc.com/leadingedge
Engage with our researchers Bill Murray , Simon Wardley , Bjorn Lundin
?
Agile Org Coach ?Agile Supervisor ?Author of AO | Founder @ #play14
10 个月This statement holds true when considering agile as solely a development method or tool, disregarding its origins in organizational design, business, and manufacturing. It is possible to be in a monopolistic position where understanding the market or external factors is unnecessary, and where the product lifecycle is indefinite. In such cases, the agile approach may not be needed. Similarly, if a manager seeks quick wins without the need to build for the future, agile may not be necessary. However, it's important to note that agile also encompasses aspects such as cash flow management, focusing on immediate returns rather than long-term capital expenditures (CAPEX). Agile represents a paradigm shift that encourages the emergence of adaptive patterns. While your demonstration may be valid for defined patterns, it may not account for the empirical nature of agile. From a non-agilist perspective, your point of view is correct.
Data & Analytics Account Delivery Lead and Master Technologist at DXC Technology
10 个月I fully agree with the core message: Carefully consider the appropriate strategy for implementing your project (or, as some might say, developing your product).? This initial decision could be a pivotal factor determining success or failure. However, I no longer view it as a matter of choosing between Agile and Waterfall. Both approaches have mutually influenced each other: People involved in Waterfall projects now embrace a more Agile mindset, and within Agile, a product vision and team commitment to the Program Increment (PI) plan remain essential. Beyond the chosen framework, the level of agility introduced versus adherence to a rigid plan is truly in the hands of the Project Manager or Product Owner.
Strategy, Offering Mgt & Marketing - thought leadership that makes the "new" understandable, Cohost of "Retail Done Right" Podcast
10 个月It's always interesting to brush against the grain but I think you're right here. I've heard clients say that mission critical systems are the biggest Agile challenge. It's the "break things" part of the phrase... when you can't afford to break things - where resilience is measured not in 1% but in fractions of 1%, you need to give thought to making progress while minimizing disruption. Well said. Well thought. -c-