Caretaker model

This post is part of 101 ideas for agile teams.

1-page description of the caretaker model

Context

Your current development process does not meet the team’s needs regarding flexibility and pace in order to support better continuous delivery of value to your users:

• there is too little feedback that comes too late
• the one process fits all work items approach hinders efficiency and effectiveness

You look for a software development process that is more continuous than a typical Scrum implementation or things alike to increase agility even further.

Action

Change your process to the Caretaker Model — or some variation of it that you optimised for your team.

At the centre of the Caretaker Model are two main ideas: decoupling of process cycles, and even more importantly, empowering each team member to take care of a work item end-to-end.

Decoupling of process cycles

The Caretaker Model decouples the cycles for

• planning
• continuous improvement
• retrospective
• delivery
• feedback

Planning

The planning cycle is short enough to keep everybody working on the most valuable work items and long enough to incorporate feedback that the team gathered since the last planning. The whole team takes part in the planning and plans the next work items to work on together (prioritisation). In case there is no consensus, the Product Owner has the last word on prioritisation.

Milestones help the team to keep the focus on a specific topic over a longer period, instead of working on a loosely coupled bunch of work.

Continuous improvement

Whenever a team member stumbles over an impediment, she or he takes action by consulting other team members (the ones she or he find appropriate) and solves the impediment. Sometimes the Daily Stand-up is a good place to bring the issue into awareness of the team, and sometimes a different approach (messaging app, dedicated workshop, … ) is better regarding speed or involved people.

Retrospective

The Caretaker Model decouples the continuous improvement cycle — for emerging impediments — from the retrospective cycle. In a retrospective, the team takes a step back and reflects on how they deliver value to their customers and users. Hold a retrospective every couple of months. The retrospective should be a whole day event, preferably outside the working space, so that the team is not distracted by the daily business.

When you start with the Caretaker Model, hold a retrospective weekly until the continuous improvement cycle starts working. Then switch to a less frequent reoccurrence.

Delivery

The delivery cycle is continuous. When a work item can be delivered, it is delivered and only when in production, the work item is considered done. Therefore, commonly, there are days when multiple deliveries occur and periods over several days without a delivery. There is no fixed schedule.

In cases that do not allow to delivery directly into production because of regulatory restrictions or not yet ready hardware, try to be as close to production as possible.

Feedback

Feedback is an essential thing in software delivery. Therefore, there are several feedback loops in the Caretaker Model.

During development, the team members pair (aka pair programming, swarming, mob programming) to provide instant feedback on a peer basis. Furthermore, all code has to be reviewed because reviews are the number one method to increase quality (e.g. with a Pull Request review). When a team member needs feedback on an idea or design, she or he calls for a peer challenge session where the idea is discussed and week spots and strengths are identified. The Product Owner provides daily feedback on the progress made since yesterday.

Once deployed, new features can be made accessible only to beta users through feature toggles to get feedback from a small set of real users doing real work before delivering the new feature to the whole user group.

Empowering each team member to take care of a work item end-to-end

The Product Backlog Items in the Caretaker Model are typically problem statements:

• What is the problem? What are its context and its impact?
• Who has this problem? Who would be impacted by a solution?
• What value would a potential solution provide?

Focusing on the problems instead of describing a potential solution gives the team the freedom to find a solution that provides the best trade-offs between the cost of implementation, time to completion, simplicity of the solution (understandability, maintainability) or even try several possible solutions in parallel.

Whenever a team member finishes working on a work item/Product Backlog item, she or he takes care of a new one. The team picks the highest priority work item that she or he can take care of. A team member can only take care of an item that matches mostly his or her skill set, and that triggers a particular interest in being solved to trigger intrinsic motivation.

To take care of a work item — problem statement — means that the caretaker plans how to find a solution to the problem and how to bring the solution to the users. This typically includes the following steps:

• Refinement — better understand the problem, root causes and impacts of the problem
• Feedback loops — think about and design the feedback loops you need to deliver the best possible solution by getting feedback from real users (feasibility, validation) and from your teammates (design, implementation, architecture, risks, …)
• Research — is the problem already solved by someone or some product? What could a potential solution look like?
• Design the solution
• Code and test the solution, and automate tests, deployment, monitoring etc.
• Open a Pull Request — so that others can review the changes before they go live when the Pull Request is completed.

The caretaker is free to define whatever process suits the work item. Whenever needed, the whole team supports the caretaker. Teamwork is the fundament of a working Caretaker Model.

What you gain

The Caretaker Model puts the team even more in control over how software is built. For every work item, a customised approach can be chosen to keep the process as simple as possible and to deliver value as early as possible.

How to strengthen

Make sure that your team shares agile values like simplicity, communication, feedback, respect, courage (XP values).

Retrospectives are essential to optimise your process to match your needs. Do them often and well. If you need more information on retrospectives, read this book by Marc Löffler.

We had a good experience when the Product Owner comes to the team every day after lunch so that the team members can show on what they are currently working and the Product Owner can give feedback.

Risks

Caretakers become lone wolfs because they control the whole process from problem to solution. Work on your team spirit by practising a lot of pairing/pair programming.

The team members have too little domain knowledge. In order to take care of a work item, the team member needs enough domain knowledge, so you should invest in growing domain knowledge inside the team.

Nobody takes care of the highest priority work item. You should clarify the value of the work item with your team. If it provides a high value, then someone should be willing to take care of it. Otherwise, remove it.

Inspiration

This idea describes how we build Timerocket at my customer, Calitime AG.

Discussions with Dominik Berner helped me find words for the description of our approach to software development.

Please help me improve this idea by providing feedback.

More ideas at 101 ideas for agile teams

Many thanks to bbv Software Services for making this blog post possible.