Disclaimer

This is a little experiment we’ve been running with my current team that has worked out pretty well. It might be common sense to people, but we’ve been stuck in a broken sprint cadence for a while. This approach helped us to close issues and deliver.

Accidentally into Kanban 🛹

Most software organizations start messy, but the steps they all you go through are the same:

A team of engineers and experts deliver a valuable product.
Over time, the organization grows, and a need for structure arises.
- Knowledge coagulates into a few risky individuals’ heads.
- Security policies and access control measures need to be auditable.
- You need to measure progress.
- You need to make a roadmap.
- You need to have [estimates*]( Software engineering estimates are garbage | InfoWorld ).
More often, growing organizations adopt some Agile situation.
Someone inevitably makes a Kanban board and it’s downhill from there.
One way or another, you find yourself running in a team planning a two-week sprint.

The Sprint Cycle ⌛

The sprint cycle is a significant compromise. It’s molded to each organization, but its principles rhyme everywhere:

Pick one of the existing static teams with a vague shared responsibility
Take a set of tasks from a backlog and estimate their effort and duration
Negotiate on priority, risk, and some other properties with other stakeholders
Schedule time for a design session, kick-off, and retrospective
Dedicate work items to fill the sprint based on estimates

Sprints are great 🏃🏻

They protect the team from in-betweeners.
They force you to cut up work into small pieces.
You engage with stakeholders.
They let you iterate over projects and make quick turns.
Create an excellent rhythm for the organization to sync around

Except… 😬

You kind of need someone to run them who cares.
- Result-driven people don’t care about calendars
- Neither do real solutions
You end up slicing projects into arbitrary parts.
- Only to get distracted next sprint
Sprints more often get fluffed with a mish-mash of unrelated tasks.
- Because the dirty work has to get done
No one can agree on a definition of done.
- or the different disciplines in a team have different definitions
- or the team as a whole has a generic and vague definition of done
“We will dedicate this sprint to clearing technical debt”

So instead of planning a sprint, plan a patrol! 😀

What’s a patrol? 🧭

Wikipedia: 📖

Patrolling is a tactic. Small groups or individual units are deployed from a larger formation to achieve a specific objective and then return.
[snip]
The duration of a patrol will vary from a few hours to several weeks, depending on the nature of the objective and the type of units involved.

Characteristics of a patrol mission

A starting point 🚀

This is where you need to be able to start the mission. You can see this as the ‘definition or ready’ but more practical and tailored for this mission.

An objective 🏆

What problem are you trying to solve, and for whom? How will you confirm that you solved the problem?

A finish line 🏁

This is where you achieve the objective, and there is nothing else for the team to do. This is the point of the ‘definition of done. At this point, you can disband the patrol team and assign the members to other projects.

A landscape 🗺️

The environment that you will be working on.

Questions to Ask when examining the landscape:

Whats the worst thing that could happen on patrol?
Do you have to deal with a ton of legacy?
Is there undocumented but observed behavior?
Is it a green field without any references?
Are there other projects you can look at to measure against?

Landmarks 🏔️

Milestones or critical points at which you can stop, reassess and reorient. These can be critical deliverables:

MVPs
design stages
mock-ups
wireframes
build artifacts
demo days
other tangible assets.

Make sure to work towards the next landmark. You will reach the finish line if each landmark brings you closer to the objective. Take time at a landmark to reorient. Plan out the next landmark and draw a leg towards it.

‘Legs’ between the starting point, objectives, landmarks, and the finish line 🦵🏻

These are the concrete tasks that need to be executed. Leg is never speculative, if a executing a task fails or doesn’t bring you closed to the next landmark, then you start again at the last landmark.

Basically, patrols are like sprits:

Select a set of tasks around an objective
Negotiate requirements
Estimate effort
Plan for design, kick-off, and retrospectives

Except:

Create a mission
- take time to define the landscape of the mission
- agree on a starting point, objective, and finish line
- Map out the landmarks and the best ways to get there
- Think about what and who you would need to cover the terrain and complete the objective.
Pick your patrol team
- Make sure that each task taken on patrol can be completed by one or more members of the patrol team
- Pick people from all disciplines: Legal, Finance, Sales, QA, Support, IT, etc.
Schedule a recurring feedback session to chat with stakeholders
- make the space to expand the mission on the fly.
- provide the opportunity for the mission to abort gracefully
Accept that the patrol team is ‘out on patrol’. Team members are not available to pick up any tasks outside the scope of their mission. Even if they seem unoccupied, their mindset and knowledge are essential to the rest of the patrol team.
- Under no circumstances may you allow in-betweeners to dilute the mission.

Sometimes, a patrol team member needs to ’evacuate’. This can be due to an emergency or a sharp change of plans. In this case, it would be best to take them out of the patrol altogether. Removing a member from a team is difficult, and you should avoid it. But, to bring them back in after a sudden context switch is costly. It’s demoralizing for the evacuee and will slow the rest of the team to bring them back up to speed. This effect increases the longer someone is out of the running.

Attention ⚠️

Don’t bind yourself to a time-boxed period
Don’t try to make it work with an existing team with vaguely-related responsibilities
Don’t assign tasks unrelated to the mission to people ‘out on patrol’.

But why tho?

Team composition varies

Some missions require many iterations and close contact with partners and end-users. To finish some missions, you need everyone:

Engineering 👷🏻
QA 🔨
Product ✏️
Finance 💰
Legal ⚖️
IT 💻
Catering. 🥪

Others, you can finish by locking two specific people in a room.

The definition of done varies

Some missions need you to:

build and test a new product
deliver some technical and functional documentation
setup acceptance-, regression-, smoke- and load-tests
complete all dependent releases
make a backward-compatible release with a rollback button
rehearse the rollback
inform the users of the upcoming release
confirm the end-user is happy with the results.

While other missions are done when the automatic build runs again.

Not all missions fit into a neat time-box of an existing static team.

Patrols allow you to:

Stop opening issues and start closing them

Cutting projects up in time boxes often leads to a bad situation. Someone adopts the MVP and puts the team on a new project before it can mature. The MVP needs support and development anyway. However, the team has already opened up another project. Cutting it up in milestones focuses on reaching maturity instead of taking shortcuts.

Avoid the overhead of context switching

A sprint more often than not ends up with a bunch of small cruft items that need fixing:

micro-stories
acute bugs (that )
long-running detective issues.

These force the devs to switch contexts a lot. Mentally unloading information and reloading a bunch of unrelated information is costly. Context-switching is inefficient and invites a lot of errors. .

Fix root causes
Be flexible with team compositions

Extension and extraction

Stakeholders will expand requirements. That’s as sure as death and taxes. Stakeholders can only do that with hindsight, never with foresight. The great innovation of scrum and agile is that it allows for iteration. Stakeholders should have the space to let the team ‘dig a bit further’. This enables the team to kill the root cause of an issue or realize the core solution to a problem.

Additionally, stakeholders should always be able to pull the plug on a patrol. The team has ‘dug too deep’ if the costs start outweighing the benefits. Stakeholders may need to readjust the mission or even abort.

At this point, you hold a retrospective, dissolve the team and reassign the members. To achieve this, there needs to be a regular moment to chat with stakeholders. This would be time to discuss progress and obstacles.

But wait, that sounds like a sprint all over again!

Yeah, you can embed sprints into patrols and gain those benefits. The point is to avoid time-boxing and to cherry-pick your teams. Instead, accept the size of the task at face value and vow to keep the focus on that task. Working in sprints alone very quickly dilutes any mission the organization has.

You don’t need to go all in!

Most of you are probably doing something like this already. For everyone else stuck in this situation: try it with a small band of specialists. Pick a complex problem, dedicate time and effort outside the sprint cycle and solve it.

If it works, you can continually expand the patrol pool by taking more people out of the sprint cycle and running starting multiple patrols. Or put people back in the sprint cycle when they are needed.

Patrols: an extention to Sprints