Ways of working (WoW)

Ways of working (WoW) is a broad term for the methods, processes, practices, tools, and conventions that a team or organization adopts to coordinate and deliver work effectively. It encompasses everything from high-level delivery processes – how work is planned, prioritized, and tracked – through to day-to-day conventions – branching and merging strategies, code review norms, meeting cadences, on-call practices, communication channels, and so on.

The term was popularized by the book Choose Your WoW!, written by Scott Ambler and Mark Lines, which is the primary reference for the Disciplined Agile Delivery (DAD) toolkit. DAD is the software delivery portion of the wider Disciplined Agile Toolkit, now stewarded by the Project Management Institute (PMI), which acquired Disciplined Agile in 2019. The term is now widely used in the software industry to refer to the specific approach a team takes to software development, including how they plan, execute, and review their work.

A hybrid, goal-driven approach

Ways of working vary widely, since few teams follow a single off-the-shelf process framework to the letter. Most teams assemble their own approach – drawing on Scrum, Kanban, Extreme Programming, and other sources – and adapt it continuously in response to what they learn works best for them. The right ways of working for any given team depend on their size, distribution, level of experience and expertise, domain, regulatory context, and organizational culture. The SEMAT Essence kernel is one attempt to give teams a shared vocabulary for describing and composing such practices into a coherent method.

DAD treats this assembly as an explicit, first-class activity rather than something left to chance. It is a hybrid toolkit that pre-combines proven strategies from Scrum, Extreme Programming, agile modeling, the Unified Process, Kanban, lean, and the Spotify model, so that a team need not reinvent those combinations from scratch. It is goal-driven rather than prescriptive: rather than mandating a single lifecycle or set of ceremonies, it presents a collection of process goals – such as form a team, explore scope, prove the architecture early, or deploy the solution – and for each goal catalogs the viable techniques, their trade-offs, and the contexts in which each works best. DAD supports several lifecycles (agile, lean, continuous delivery, exploratory, and a program lifecycle for coordinating a team of teams), reflecting its premise that no single process fits all situations.

Evolving ways of working

A defining claim of the WoW framing is that ways of working are not chosen once and frozen. They are revised repeatedly as the team, the product, and the context change. DAD elevates this to an explicit process goal, Evolve Ways of Working (WoW), which sits alongside the delivery goals and is revisited throughout the lifecycle rather than only at a project’s end. The mechanism is familiar from agile retrospectives and the lean practice of kaizen: inspect what is and is not working, run small experiments with alternative practices, and adopt what survives. The Disciplined Agile Toolkit formalizes this as guided continuous improvement, in which a team’s WoW evolves through deliberate, context-aware experimentation rather than through imitation of another team’s playbook.

Ways of working are often captured in a working agreement – sometimes called a team charter or social contract – a short, team-authored document that records the conventions the team has agreed to follow. Working agreements make implicit norms explicit, which makes them discussable and revisable. They typically cover meeting cadences, core hours and response-time expectations, definitions of ready and done, branch and merge conventions, code review expectations, and how the team handles on-call and incident response. Because the agreement is owned by the team, updating it is the natural home for the experiments that continuous improvement produces.

Shaping forces

Several forces shape which ways of working will succeed for a given team. Conway’s law is one: the communication structure of the organization constrains the practices that can take hold, because practices that cut across team boundaries are harder to sustain than practices that fall within them. Team composition is another. A cross-functional team that owns an outcome end to end can adopt continuous deployment and shared on-call in ways that a functionally siloed team cannot. The broader DevOps culture of shared ownership is itself a coherent set of ways of working, and it presupposes the team structure that makes it viable. Regulatory and compliance context can dictate practices directly – required audit trails, separation of duties, or change-approval boards – while domain and technology maturity shape how much experimentation a team can safely absorb.

Measuring ways of working

Because ways of working are adapted rather than adopted whole, teams need ways to tell whether a change is an improvement. The Capability Maturity Model and its successor CMMI assess the maturity of an organization’s ways of working for software development against a scale of institutionalized practices. Delivery metrics offer a more empirical signal: the DORA "four keys" – deployment frequency, lead time for changes, change failure rate, and recovery time – link specific delivery practices to organizational performance, giving a team evidence for whether its WoW is actually delivering flow and reliability improvements. The two are complementary. Maturity models describe how institutionalized a practice is, while outcome metrics describe what it produces.

References

Ambler, Scott, and Lines, Mark (2019). Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. Disciplined Agile, Project Management Institute.