Becoming an agile organization takes time, thought, and a lot of conversation. With a million articles, certifications, and opinions in the market, knowing where to start and what to try first can be a challenge.
By understanding the nature of your work and the maturity of your product, you can frame the discussions your team will have to organize around a framework. Agile implementations can and should change over time as the team and product evolve.
Let’s examine the types of work and product phases and how they impact team dynamics.
Defining Terms
Before discussing alignment and implementations, let’s define the core terms that we use throughout this article.
Agile means a lot of things to a lot of people depending on their experiences and environments. Agile, as defined in the agile manifesto, values interactions, working software, collaboration, and response to change.
In that spirit, many frameworks attempt to implement agile values through repeatable patterns. Frameworks offer descriptions and reasoning, showing how a repeatable pattern can lead to the desired outcome.
On the other hand, models offer prescriptions in an attempt to achieve agile values. The distinction between frameworks and models becomes important when an organization mandates a model rather than recommending a framework. Frameworks allow teams to adapt and fill in gaps as needed, whereas models require adherence to a strict pattern. With that in mind, everything recommended here is a framework, not a model.
Many people have designed plenty of agile frameworks in the two decades since the manifesto was signed. Some have been popularized more than others: Scrum, Kanban, eXtreme Programming (XP), and Lean principles tend to dominate the current market.
Paralleling these frameworks, common scaling frameworks and models include SAFe, LeSS, and Nexus. Each has its place, and each lends itself to different markets and company structures. The challenge is to determine the right framework for your organization and context.
Understanding Work
In order to pick the appropriate framework, first consider the type of work and circumstances of the product.
Software development contains a wide swath of tasks, ranging from novel architectural engineering to repeatable maintenance operations. To help contextualize types of complexity, David Snowden developed the Cynefin framework.
This diagram breaks work into quadrants to explain both the types of work and the thought behind the approach to that work:
Image Source: The Cynefin Co.
Let’s take a closer look at each quadrant -
-
Chaotic - The bottom left quadrant describes development in the unknown. Novel practice thrives when product direction is still unplanned. Disorder allows for “shot-in-the-dark” efforts, followed by analysis and adaptation. This follows the pattern of “Act → Sense → Respond”. These efforts have minimal predictable milestones and require significant flexibility to progress.
-
Complex - The upper left quadrant adds constraints and some level of roadmapping, and depicts complex work. This type of development lends itself to discovery-led engineering with multiple dependencies and significant unknowns. Following the “Probe → Sense → Respond” pattern, iterative learning and delivery produce these interconnected solutions. Exaptive practice discovers solutions while in progress, making the road by walking it.
-
Complicated - Moving to the upper right quadrant and adding detailed specifications, complicated work follows good practice. Most items, though they are difficult, have singular solutions. Through the “Sense → Analyze → Respond” pattern, analyzed tasks follow a priority and developers work the list.
-
Clear - Filling out the bottom right quadrant, clear work contains known and repetitive items. Individuals work these independently and follow the same repeated steps, categorizing tasks into buckets by similarity. Best practice dictates a single correct way to work each task.
Visualizing your team’s work through this lens gives insight into what framework addresses your context. Both the makeup of your project backlog and the lifecycle stage of your product add additional insight.
Knowing Your Product
Products tend to follow a natural progression over time as they break into and establish a market.
In the initial stages, the market itself is unknown, causing the product to pivot from one thread to another until the right distinguishing factor sets it apart.
After selecting a direction, the product grows and fills out, addressing a widening band of use cases and functionality.
Eventually, this slows down, and the platform transitions into a comfortably mature phase. Minor enhancements generally comprise the efforts here, sustaining a steady place in the market.
Lastly, as the product approaches end of life, the decline stage sees a retraction of funding, minimal new features, and a general “keep the lights on” attitude.
Image Source: The Street
Each phase has some overlap but also has principally distinct types of engineering work.
-
Introduction - Intrepid discovery-led work develops new features for an unknown market with an undetermined product goal. Green field development.
-
Growth - Major features and additions to a burgeoning product. Scaling, infrastructure, and stability become more important as this phase progresses.
-
Maturity - Smaller enhancements, focused on stability. Reconciling foregone technical debt on the established product. Fewer new features as integration replaces breakthroughs.
-
Decline - Keeping the application functional as it slowly ages out of relevance. Rebalancing efforts to a newly growing product, while work on the declining product emphasizes user support over any new functionality.
Understanding your product, the current and next phases, and the development angle in each allows you to better advocate for a framework within the current context.
Putting It Together
With an analyzed product and workload, you can begin assembling the pieces. Understanding the type of work, the phase of your product, and the practice through which that work gets done allows you to lean in to frameworks designed for that context.
Oftentimes, these frameworks overlap or interplay with one another, allowing for the team to implement hybrids as needed.
Chaotic discovery needs the flexibility that unformed lean methods offer. Complex interdependent work needs iterative implementation, as addressed by Scrum and eXtreme Programming. Complicated enhancements can be done in isolation but require strict prioritization, an attribute addressed by the core of the Kanban framework. Clear, predictable, and repetitive decline phase work lends itself to similarly Kanban-esque frameworks, with notably different needs than a team on a maturing product.
Getting Started
In the spirit of agile values, seek to value individuals and interactions over processes or tools. This means working with the team to narrow in on the optimal work pattern.
Familiarity with the nature of development to be done and the experiences of the team working on the project will always provide insight into how engineers perform those tasks and stories.
Agile emphasizes response to change over following a plan. This applies not only to the product roadmap but also to the agile framework in use. To quote the agile manifesto, “we are uncovering better ways of developing software by doing it.”
Holding the framework of choice with an open hand, open to change and adaptation remains of paramount importance as the product progresses through various iterations and lifecycle stages.
Frameworks present tools to encourage agility, not rigid limitations that prevent adaptation. Understanding interactions over unmalleable process models makes it clear that agility is a mindset to retain, not a destination to reach.
None of this should be taken as prescriptive. These use cases cover common implementations and situations, but by no means mandate strict adherence.
Understanding your situation, phase, and team set the context for a discussion about which framework fits your team’s needs. Get your group together, set the stage, explain your thought process, and allow the group to discuss!
As a team, find the right tool for your current conditions.
