The more the industry moves Agile toward a fixed set of methods, certifications, and standardized models, the more it loses the characteristics of real agility. Without active effort, Agile will continue to transition from a collaborative approach into a standardized, top-down, control-driven process.
Agility doesn’t come from frameworks, it comes from taking a more hands-on, DIY approach. Your workflow should be built using the same principles the Agile Manifesto promotes to build software: collaboration, simplicity, trust, and continuous learning.
It’s important to notice when an organization’s approach to Agile no longer aligns with agile values and principles, and to know why that matters. One way we can start is by asking: “How much of our process is actually ours?”
Build Your Process Incrementally and Iteratively
Agile processes should be developed locally and incrementally. Start by identifying your immediate goals, then introduce the minimum structure and process necessary to achieve them. Resist the urge to over-specify roles, tools, and methods.
- Start where you are now
- Implement an experiment
- Evaluate fitness
Taking an evolutionary approach reduces the cognitive burden and disruption that comes from enterprise agile transformations. Instead of designing an agile process upfront, let it develop through experimentation and feedback loops.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” — Principles behind the Agile Manifesto(opens in a new tab)
Build Your Process Collaboratively
How a team works shouldn’t be installed from above. The Agile Manifesto says that “the best architectures, requirements, and designs emerge from self-organizing teams.” The same should apply to your process.
“The best architectures, requirements, and designs emerge from self-organizing teams” — Principles behind the Agile Manifesto(opens in a new tab)
Team-level agile practices should emerge from the daily work of a self-organization team, and from the collaboration between designers, developers, and stakeholders.
A team shouldn’t need management approval or the permission to address friction points in how they work. The people closest to the work should be the ones deciding how to do it.
Take a Hypothesis-Driven Approach
Workflows shouldn’t be beliefs-based; they should be based on evidence. Instead of declaring, “We need a new governance meeting,” start by re-framing it as a question: “Do we need a new governance meeting?”
From there, form a testable hypothesis:
“We believe adding a 15-minute sync on Tuesdays will reduce our deployment blockers. We will know we are right if our blocker count drops by 20% over the next two weeks.”
Even decisions that worked in the past might need to be re-evaluated. Use feedback to inform your next step. Approach new ideas with, small, low-risk experiments. If a change is small, easy to understand, and reversible, you can test it to see if it helps. If it doesn’t, then just roll it back and try something else.
It’s okay to try things.
Treat Process as a Side Project
Teams don’t deliver valuable by adopting frameworks or collecting certifications. Value is delivered by people. Sometimes the distinction is lost and people start to confuse agile process adoption as the goal.
For this DIY mindset to work, you need the right environment: one that supports, trusts the people involved, and tolerates failures on the path to improvement.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” — Principles behind the Agile Manifesto(opens in a new tab)
A team’s process should be a snapshot of their current best understanding of how to deliver value. Process is not just an input, it’s a product of the team’s learning and experience.
For Agile Coaches, guidance shouldn’t start with what a team’s process should be, it should be to build the engine: start with collaboration, start with reflection, start by taking actions to make things better.
