Ways of Working: Fixing the Friction in How Your Team Operates

A team that has proven capable can still struggle to move work through the business efficiently. Decisions take longer than expected. Work waits between functions. A process that looked sensible on paper creates unnecessary steps in practice. New technology gets added, yet the underlying friction remains.

In my experience, these problems are rarely solved by asking people to work harder. I first look at the operating choices surrounding the work. How is work prioritized? Where does responsibility change hands? Which decisions require approval? Which tools support the process? Most importantly, do those choices still fit the context the team is operating in?

That is where a deliberate set of Ways of Working (WoW) becomes useful. Rather than forcing every team into one prescribed methodology, WoW gives teams a structured way to choose practices that fit their circumstances and evolve those choices as the situation changes.

All You Need to Know About Ways of Working

• A Way of Working (WoW) is the context-specific set of practices a team uses to get work done.
• WoW is not a fixed methodology; it should reflect the team’s actual operating context.
• The best WoW starts with real friction, not with a preferred framework.
• Teams can combine practices from different approaches when those practices fit the work.
• Implementation begins by mapping how work currently flows before changing it.
• Changes are easier to evaluate when they are introduced in focused, manageable steps.
• A WoW should be tested and refined based on operational evidence and team feedback.
• Activity data can add context, but it should not be treated as proof of productivity.

What Is Ways of Working?

A Way of Working (WoW) is the context-specific combination of practices and processes a team uses to accomplish its work. It covers how the team organizes its activities and makes process-related decisions. It also includes how the team collaborates and which tools support that work.

The concept is closely associated with Disciplined Agile. PMI describes Disciplined Agile teams as choosing a fit-for-purpose WoW rather than following a single prescribed method. Teams are then expected to evolve that WoW as they learn or as their operating environment changes.

That distinction matters. Why? Well, WoW is not another name for Scrum. Nor does adopting Kanban automatically give a team a complete WoW. Disciplined Agile explicitly allows teams to draw from Agile approaches as well as Lean practices and traditional strategies when those choices make sense in context.

I therefore think of WoW as a set of deliberate operating choices rather than a methodology that a team installs.

A team’s choices might determine:

• how work enters the team;
• how priorities are decided;
• how responsibility moves through a process;
• how decisions are made;
• how progress becomes visible;
• how problems trigger improvement.

The important question is therefore not, “Which methodology is best?” It is, “Which combination of practices gives this team an effective way to achieve its outcomes in its current context?”

What Shapes an Effective Ways of Working Framework?

An effective WoW starts with choice, but that choice needs structure. Without it, teams can end up combining practices simply because they are familiar or fashionable.

I prefer to begin with the problem the team is trying to solve. From there, you can assess the operating context and select practices that address the problem without introducing disproportionate complexity.

Team Context

Context determines whether a practice is appropriate.

A small team working closely together can coordinate through relatively lightweight mechanisms. A distributed team may need more explicit documentation because people cannot rely on informal conversations. A team operating in a regulated environment may need controls that would add little value elsewhere.

So, before setting ways to work, I usually figure out:

• What outcomes is the team accountable for?
• Where does the team depend on other functions?
• What constraints cannot simply be removed?
• How predictable is incoming work?
• How much variation does the work contain?

This prevents a common transformation mistake: solving the process you wish you had rather than the one the business actually operates.

In my operations and transformation work, I’ve seen two teams inside the same business need very different WoWs because the nature of their work was different. One operational team handled a steady flow of repeatable requests, so it benefited from a visible queue, clear service levels, and tightly defined handoffs. 

Another team dealt with less predictable improvement projects, where the work required more judgment and cross-functional coordination. Applying the same process controls to both would have created unnecessary friction. 

Sources of Operational Friction

Once I understand the context, I look for friction.

Friction is any recurring feature of the process that makes value harder to deliver without producing a proportionate benefit. However, you have to be very careful here, since not every additional step is a waste. A review may exist because regulation requires it. An approval may protect the business from material financial risk.

The objective is therefore not to make every process shorter. It is to understand why each element exists and whether it still earns its place.

In one operations review, I examined a workflow where a routine request took roughly 12 business days to move from intake to completion, even though the team spent only about 7 hours actively processing it. 

Most of the elapsed time sat between stages while work waited for information, approval, or the next available resource. That distinction mattered because the obvious response of asking people to work faster would not have addressed the real constraint. The larger opportunity was to reduce the waiting and rework built into the flow.

That changes the intervention.

I would hence examine what happens between those tasks. Perhaps reviews are batched, information arrives incomplete, or responsibility for exceptions is unclear.

This is one reason flow matters so much in WoW. 

Practices That Fit the Work

After locating the friction, consider practices within your ways of working framework that address it.

This is where WoW differs from simply standardizing on a framework. 

A team dealing with unpredictable service requests might use a pull-based flow model. On the other hand, a project team working toward staged deliverables may need a different lifecycle. 

There are many possible ways of work, but the practice should always be tied to the problem.

That relationship should be explicit:

Problem → proposed practice → expected effect → evidence

Coordination, Decision-Making, and Tools

A WoW also has to explain how people coordinate around the work.

That includes decisions that affect flow. If nobody knows who can resolve an exception, the process may stop even though every individual task is well defined.

I usually look for three forms of clarity:

• Coordination clarity: people know how work moves between contributors.
• Decision clarity: the appropriate person can make a decision without unnecessary escalation.
• System clarity: people know which tool or record holds the authoritative information.

The third point becomes increasingly important during digital transformation. Adding software can improve visibility or automate a manual step. However, a tool should support the WoW rather than silently dictate it.

I have seen organizations focus heavily on software configuration while leaving the underlying decision process untouched. The result is often a digitized version of the same bottleneck. If five approvals were unnecessary before automation, making those five approvals digital does not automatically make the process better.

Disciplined Agile reflects this broader view by treating tooling as one of the decisions teams consider while evolving their WoW.

Get TimeBee to See Where Your Team’s Work Is Really Slowing Down

Learn More

How to Implement Ways of Working?

Now that you know what ways of working is, it’s time to see how to apply them. Implementation should begin with the current system rather than an ideal-state diagram. Once you can see how work really happens, you can make focused changes and learn from the results.

1. Map the Current Way Work Gets Done

The foremost step is to start by tracing a real piece of work from entry to outcome.

For this purpose, it isn’t ideal to rely solely on a policy document. Ask the people doing the work what actually happens when information is missing or priorities conflict. Those exceptions often reveal more about the current workflow than the standard process does.

I would map:

• where work enters;
• when ownership changes;
• where decisions occur;
• where work waits;
• where systems are updated.

The aim is to have enough visibility to see where the actual flow differs from the intended one.

Once, I looked at a team processing around 280 service requests in a month. Seventy-four of those requests were returned at least once because information was incomplete, which gave the process a rework rate of about 26%. That told me far more than a simple measure of how busy the team appeared.

The more useful question was why the work kept coming back. In that case, the issue pointed to a weakness in the intake process rather than a lack of effort from the people doing the work.

2. Prioritize the Changes That Matter Most

Once several problems are visible, you need to resist the temptation to redesign everything simultaneously.

The best approach to go by is to start with the constraint that has the strongest relationship with the desired outcome.

If the team’s main issue is delayed client delivery, a bottleneck that adds three days of waiting deserves more attention than a minor administrative irritation that costs five minutes per week.

This also makes cause and effect easier to interpret. If you change too many elements at once, you may see improvement without knowing which intervention produced it.

In my work, I therefore prefer a small improvement backlog rather than a complete process overhaul. Each proposed change should have a reason and an expected result.

3. Document the Agreed Way of Working

Once the team agrees on its initial ways to work, capture it.

However, that does not mean producing a large manual. 

The documentation should answer the questions people genuinely need answered. For example:

• How does work enter the team?
• Who can change priorities?
• Who owns exceptions?
• What must be documented?
• When should an issue be escalated?

The document is useful only when it reflects the real process. If the team repeatedly works around it, either the practice is wrong, or the documentation has stopped reflecting reality.

4. Introduce Changes in Manageable Steps

Implementation should create learning without disrupting the entire operation at once.

If you are changing how work enters a team, for example, you might introduce the new intake process within one function or workflow before extending it across the business. This gives people time to understand the new practice while allowing managers to resolve practical issues early.

The same principle applies to broader WoW changes. Rather than changing prioritization, handoffs, decision rights, and reporting at the same time, introduce the most important changes in a logical sequence. Each step should be stable enough to support the next one.

Small rollouts also allow teams to discover unintended consequences before those consequences spread.

5. Support Adoption Through Change Management

A technically sound WoW can still fail if people do not understand why the change matters or what they are expected to do differently.

This is where change management becomes part of implementation rather than an activity that happens after design.

As for me, I focus on three practical questions:

• Do people understand the problem being solved?
• Do they know what behavior must change?
• Can managers reinforce the new practice consistently?

Transformation requires active support through mechanisms such as training and coaching. It also emphasizes engaging the people affected by the change.

Ownership also matters here. A new process without an accountable owner tends to degrade quietly because nobody is responsible for resolving ambiguity or deciding when the process needs to change.

6. Test and Refine the WoW in Practice

Your initial design is a hypothesis. You will only know whether it works after the team uses it.

This is fundamental to WoW. Disciplined Agile treats improvement as an ongoing process. Teams identify an issue and experiment with a potential improvement before assessing the result and deciding what to retain.

In one of my projects, I worked with a team whose intake process was generating frequent follow-ups because requests often arrived without the information needed to begin work. 

In an initial sample of 45 requests, 18 required additional clarification before processing could continue. We introduced a more structured intake practice and tested it on the same type of work. During the next review period, only 8 of 45 requests required the same follow-up.

That improvement was encouraging, but it did not automatically mean the new practice should be adopted unchanged. We also needed to check whether the additional intake requirements had slowed request submission or shifted administrative work elsewhere in the process. 

Testing a WoW change means looking for both the intended improvement and any new friction it creates.

That is why implementation should include an explicit review point. If a new review practice reduces defects but doubles cycle time, you need to understand the trade-off. Likewise, if a new planning routine improves predictability without adding meaningful overhead, it may be worth retaining.

These ways of work should therefore remain open to evidence. The objective is not to defend the process you designed. It is to improve the team’s ability to produce the intended outcome.

Ways of Working Examples for Different Teams

The easiest way to understand WoW is to see how the choices change with context. The following ways of working examples show why similar principles can produce different operating arrangements.

Small Cross-Functional Team

Imagine a seven-person product team whose members already have the skills needed to move work from idea to release.

Its WoW may remain relatively lightweight.

New work enters one prioritized backlog. The product owner determines priority while specialists decide how the work should be completed. The team limits work in progress so that unfinished items do not accumulate.

Decisions that affect the product direction are documented. Routine implementation decisions stay with the people closest to the work.

Because the team is small, additional approval layers would probably slow flow without adding much control.

Operations Team Handling Continuous Requests

Operations teams often need a different WoW because work does not arrive in neat project cycles. Requests can enter continuously, while urgency and complexity vary from one item to the next.

In my operations work, I have seen teams struggle when every incoming request was treated as equally urgent. Work was started quickly, but priorities shifted so often that older requests remained open and employees were repeatedly pulled between tasks. The problem was not effort. The team lacked a clear system for deciding what should move first.

A more effective WoW introduced a visible queue with defined priority rules. Genuine urgent work followed an agreed escalation route, while routine requests moved through the normal flow. The team could then review blocked work regularly and adjust capacity when one category of demand began to build up.

That changed the focus from keeping everyone constantly occupied to keeping work moving through the system. For a team handling continuous demand, that distinction is important because the WoW needs to support flow and responsiveness rather than revolve around a fixed project milestone.

Remote or Hybrid Team

A distributed team needs to design around reduced informal visibility.

Its WoW may therefore place greater emphasis on durable information. Decisions should be recorded somewhere accessible rather than remaining inside private messages or meetings.

Routine status communication can happen asynchronously. Live meetings can then be reserved for work that genuinely benefits from real-time interaction.

The goal is not to eliminate synchronous communication. It is to ensure that location does not determine who has access to important context.

How to Know Whether Your WoW Is Working

A WoW should ultimately improve outcomes. That requires more than asking whether people like the new process or whether everyone is following it.

I evaluate it from several angles because no single measure tells the whole story.

1. Measure Flow, Quality, and Business Outcomes

The most useful measures are usually tied to the problem the WoW was intended to address.

When slow delivery is the issue, elapsed time can show whether work is moving through the process more efficiently. Where rework is the concern, return rates can indicate whether work is being completed correctly the first time. Quality problems may require defect rates or other measures linked to the output itself.

Operational measures become more meaningful when they are viewed alongside business outcomes.

In one operations improvement project, I reviewed a process where turnaround time had become a recurring concern. Before changes were introduced, average completion time was around 9.4 days, approximately 22% of requests were returned because information was incomplete, and 81% were completed within the expected timeframe. After the WoW was adjusted, turnaround fell to roughly 7.1 days, return rates dropped to 11%, and on-time completion increased to 91%.

No single number explained the result. Together, however, the measures suggested that the revised process was improving flow while also reducing avoidable rework.

That is the value of outcome-based measurement in WoW. It does not exist to prove that a new process was correct. It helps show whether the intended improvement is actually appearing in the operation.

2. Interpret Work Pattern Data

Work-pattern data adds another layer of evidence because it shows how time and activity are distributed across the process.

TimeBee is one example of such a system that provides this type of visibility. Its feature set includes automatic time capture and online timesheets. Time can also be associated with specific projects or tasks. In addition, the system reports website and application usage while providing activity data through screenshots and activity-level records.

Within a WoW review, this type of information can help reveal whether work patterns changed after a process adjustment.

For example, if a revised workflow is intended to reduce administrative effort, project-linked time data can show whether less time is actually being spent on that part of the process. Similarly, application-usage reports may reveal that employees are moving repeatedly between several systems to complete what appears to be a single task.

That pattern can be operationally significant. In my work, I have seen apparently simple processes require repeated movement between systems because information was fragmented across different platforms. The visible activity was high, but the underlying issue was process design rather than employee effort.

TimeBee also allows websites and applications to be categorized for reporting purposes. That can provide additional context when examining how work is distributed across tools.

However, the data becomes more useful when interpreted alongside process outcomes, workload context, and the nature of the work itself.

3. Collect Team and Stakeholder Feedback

Quantitative evidence can show that something changed. Feedback often explains why.

In operational reviews, I have found that process data and employee experience frequently reveal different parts of the same problem. A dashboard may show that turnaround time improved, while the team explains that one specialist is now absorbing more exception handling than before.

That distinction matters because an apparently successful process change may simply have moved friction elsewhere.

Specific feedback tends to be more useful than general sentiment. Questions about whether ownership is clearer, whether decisions happen faster, or whether stakeholders receive what they need without repeated follow-up usually produce more actionable insight than asking whether people simply prefer the new process.

Stakeholder feedback also provides an external perspective on the WoW. A team may believe a handoff has improved, for example, while the receiving function continues to experience missing information or unclear responsibility.

For that reason, qualitative feedback is most useful when it is considered alongside operational measures rather than treated as a substitute for them.

4. Compare Results Against the Targeted Problems

The final test is whether the original source of friction has actually changed.

If long review queues triggered the WoW change, reduced waiting time provides relevant evidence. If handoffs were generating rework, a lower return rate shows whether the revised process is addressing that issue. Where unstable priorities disrupted delivery, greater consistency in planned work can indicate that the new approach is having the intended effect.

In my experience, this comparison is what prevents teams from confusing process compliance with process improvement. A team can follow a newly documented WoW perfectly and still fail to solve the problem that justified the change.

The stronger question is therefore whether the operational outcome improved without creating a more serious constraint elsewhere.

A WoW is most useful when it remains responsive to that evidence. When results move in the intended direction, the team has a stronger basis for retaining the practice. When they do not, the outcome provides information for the next adjustment rather than evidence that the team simply needs to comply more closely.

FAQs

Who should define a team’s WoW?

A team should define its WoW collaboratively within the constraints of the wider organization. Team members contribute practical knowledge of how work actually happens, while leaders set boundaries around governance and business requirements. The result is a WoW that reflects operational reality without ignoring enterprise-level needs.

Can a team combine practices from different frameworks?

Yes. A team can combine practices from Agile, Lean, Scrum, Kanban, traditional project management, or other approaches when those practices fit the team’s context. The goal is not to follow one framework rigidly, but to assemble a coherent set of practices that supports the work and solves specific operational problems.

How often should a WoW be reviewed?

A WoW should be reviewed whenever the team’s context changes materially or when evidence shows that current practices are creating friction. Periodic reviews can also help prevent outdated processes from becoming permanent habits. The appropriate cadence depends on how quickly the team’s workload, technology, responsibilities, or operating environment changes.

What is the difference between a WoW and a working agreement?

A WoW is the broader system of practices, processes, decision rules, tools, and coordination methods a team uses to deliver its work. A working agreement documents selected expectations within that system, such as communication norms, responsibilities, escalation rules, or collaboration practices. In short, the agreement records parts of the WoW rather than replacing it.

How do you know when a WoW needs to change?

A WoW needs to change when it no longer fits the team’s context or produces the outcomes it was designed to support. Rising delays, repeated rework, unclear ownership, frequent workarounds, or worsening stakeholder outcomes can all indicate that existing practices need adjustment. The strongest signal is persistent friction traceable to the current operating approach.

TimeBee: Find the Friction Between Activity and Outcomes

Try TimeBee