The Core Idea of Agile
Zone Leader Rick Freedman reviews the core idea of agile and why simplicity and adaptiveness is important to software development.
Join the DZone community and get the full member experience.
Join For FreeI often wish that the agile community had adopted Jim Highsmith’s language instead of the term ‘agile’. Highsmith uses the word ‘adaptive’ both in his software methodology work from back in his Cutter Consortium days, and in his thought-leadership articles at Thoughtworks.
The idea of adaptiveness appeals to me for a lot of reasons. From a methodological standpoint, it acknowledges what I’ve observed; every agile instance is unique. Agile is a set of values open to wide interpretation. No matter how ardently teams claim to be doing pure scrum, every team adapts even the most disciplined process according to their personalities, skills, interactions, and histories. Each agile team, and each agile enterprise, is agile in its own way, as they should be.
Adaptiveness is clearly the core sentiment underlying the agile movement. We adapt to change in our client’s vision, we adapt to disruptions in the market, we adapt to shifting priorities, we adapt the product based on testing, inspection, and collaboration, and, through reflection, we adapt our practices as we go.
Outside the dev world, agile is associated in the public mind more with iterativeness, which is tactical, than with adaptiveness, which is strategic. When we shift the focus from the tactical iterative practice to the strategic imperative of adaptiveness, the business meaning of agile emerges more clearly. The ultimate enterprise goal is to develop the ability to adapt to changes in the market and environment in real-time. Real-time responsiveness is a stretch goal, but it illustrates the ideal; an enterprise that can execute data-driven, real-world pivots to meet changing conditions across their value chain.
Senior leaders face significant challenges in evolving to an adaptive business model. Publicly traded companies face regulatory requirements that make iterative, adaptive planning and budgeting daunting. The typical strategic planning process is a predictive model, looking out three to five years and trying to plan for developments “over the horizon”, where no-one can see and predictions are usually wrong. The process is exclusive, pejoratively known as “a bunch of managers in a closed room”. It is, of course, political, with factions vying for resources. Evolving from the status quo in the executive suite requires migrating to an inclusive, client focused, iterative strategic process, focused less on predicting the unknowable future and more on analyzing the potential opportunities, and possible disruptive threats, in the current market. Many strategic business thinkers, like Clay Christensen and Larry Downes, think that building a “disruption prediction” engine into the strategic process is a key to competitiveness.
Adaptiveness is a tightrope at the dev team level. Taken too far, adaptiveness becomes the undisciplined cowboy coding the traditionalists warned us about, where the team adapts to every personality quirk, preference, or management dictat by ‘adapting’ the methodology. Applied thoughtfully, adaptiveness has a mantra-like Zen quality for me. No matter what the obstacles, the technical difficulties, the differences of opinion in the team, we can adapt. With methods like pair programming, we can gently coach rookie teammates and instill standards of quality and form. Through reasoned dialog with an informed product owner, we can adapt to the business’ emergent needs without compromising agility or function. When technical solutions blow up, we can fail fast enough to uncover the underlying inefficiencies or technical debt we need to address.
When, as an agile advisor, my client is tormenting me and my team with their inability to escape traditional, project concepts, I repeat my mantra of adaptiveness. Some teams utilize the idea of ‘adapters’, instruments of translation that bridge the divide between the PMO, SDLC world and the agile team. I’ve seen this theory of adapters, proposed by Michael Sahota, in action. Agile teams I’ve led, in the early days, were forced to create parallel project plans and gantt charts regularly to inform the PMO, who had no idea how to interpret a burndown chart or other typical agile information source. While clearly not sustainable (I had a client who paid a technical writer to create traditional project artifacts just to satisfy an SDLC requirement), adapters are another element of the evolutionary, adaptive approach to agile transition I favor.
My brain functions by boiling things down. Simplicity, I find, in communication, teamwork, workflow, function, and theory all help me successfully approach the problem. In its simplest terms, to me, agile is about adaptiveness, from the strategic to the tactical, and even to the personal. Agile advisors that reflect on adaptiveness to the culture, history, legacy, personality and skills of the team, and on the ultimate strategic goal of adapting to the competitive world as it is, whether coaches or scrummasters, can’t go far wrong.
Opinions expressed by DZone contributors are their own.
Trending
-
Use Golang for Data Processing With Amazon SNS and AWS Lambda
-
5 Best Java Frameworks for Web Development in 2023
-
Knowledge Graph With ChatGPT
-
Integrating Customer 360 Systems With GPT APIs: A Technical Architecture Perspective
Comments