I previously wrote about the meaning of self-management with examples in a Scrum context. The concept of self-managing teams is not just a characteristic of Scrum; it is one of the foundational principles of the Agile Manifesto, where the term “self-organizing teams” is used (note that discussing similarities and differences between self-organising and self-managing is an unnecessary detour in the context of this article). It is my observation that very little guidance on how to actually achieve self-management is provided in the agile space, often leading to the chaotic scenarios or a path back to micro-management as I discussed in the aforementioned article.
The Kanban Method Practice of Make Policies Explicit
The Kanban Method is a management method made up of principles and practices to be applied to whatever process is in place (which could be Scrum). One of the practices is to make policies explicit. Note that this practice is specific to The Kanban Method. You won’t even find it in the Kanban Guide for Scrum Teams or in ProKanban’s Kanban Guide.
Explicit policies can be used to define the boundaries within which teams can work and the level of empowerment they have. They should ideally be defined collaboratively with the team involved so they have a sense of ownership. Also, the people closest to the work are best placed to make suggestions and assess the impact that a change in policies might have. A level of self-determination of policies is also more likely to mean stronger buy-in to follow them. With explicit policies in place, self-management can come alive.
Explicit policies should be created collaboratively between managers and those doing the work, setting expectations on how to act. Team members look to the policies instead of referring to a manager, while managers begin to trust teams to self-manage because they trust the system as described by the policies.
With policies in place and that are followed, management effort can move away from day-to-day tactical actions to working more strategically.
Having explicit policies in place lays the foundation for improvement. Where policies are not explicit or they do not exist at all, the current process may not be understood, making it hard to have a discussion about how things could be better. Making current policies explicit creates a shared understanding of how things actually work so that it is possible to look at the processes in place with rationality and logic. From there, a team can collaborate and frame improvement actions as experimental changes to policies with hypothesised observable outcomes. This is in contrast to a coach or manager far from day-to-day working in the system imposing changes to a system that is poorly understood resulting in unpredictable outcomes.
Example Policies
The Kanban Method only guides teams and organisations to make policies explicit, but it does not prescribe what they should be. It’s up to the team and the organisation to define and evolve their policies in their context.
Let’s take an example where a team agrees on their policies on how they should act when one of the team members finds they have capacity for work, such as when they have completed a task and they are ready to pick up something else. There might be a temptation for managers or coaches to tell team members what to do in this scenario such as asking programmers to help out with testing. However, this approach often leads to resistance and it also takes self-management away from the team.
Instead, the team can be challenged to create their own policies for this scenario, within the constraints of working efficiently, effectively and getting stuff done in a timely manner. They might come up with something like the following.
- If there are any expedited items, see if there anything you can do to help
- Otherwise, if there are any blockers, see if there is anything you can do to help remove them
- Otherwise, if there are any defects raised on items in progress, see if you can help fix them
- Otherwise, if the WIP limit allows, and there are work items waiting, pull and start work on something new for your specialism
- Otherwise, work on an item of outstanding technical debt
- Otherwise, review the latest quality metrics or carry out some exploratory testing to see if there is anything you can do to ensure quality
- Otherwise, see if you can help or shadow on something in progress outside of your own specialism
- Otherwise, use the spare capacity for self-learning
Left to decide on their policies with the set goal in mind, the team might arrive at collaborative behaviours by themselves, such as item number 8 in the list above. If they don’t perhaps they are just not ready.
The above is just one example of one set of policies in one scenario. Another team with the same scenario might come up with a very different set of policies. Some other examples of policies that may need to be agreed by a team and their stakeholders include:
- The order of what to work on next, for example, oldest item first, highest perceived value first, lowest effort first, or cost of delay
- Definition of Done
- Exit criteria (what needs to happen for a work item to be able to move to the next stage)
- How work gets accepted as ready to start
- Definition of different types of work
- Purpose and frequency of meetings
- Stakeholder collaboration
- Approach for setting expectations on delivery times
Scrum already comes with some policies that are already made explicit. There may be some policies that are non-negotiable and are expected to be followed. These could include things like adherence to organisational quality standards or governance processes. When it comes to enabling self-management, policies that are pushed onto the team should be kept to the minimum necessary, with as much empowerment for policy evolution given to the team as possible.
Tips on Creating Explicit Policies
Making policies explicit is a simple but powerful practice, but some teams struggle to get started. Here are my tips:
Put the “Explicit” in Explicit Policies
Policies are no good if they are not known, poorly understood or create confusion. As policies are formed, check or challenge people’s understanding of them. From there, policies should be readily accessible for reference.
Policies should be well-defined with as much ambiguity as possible removed. For example, compare a policy in a team’s Definition of Done of, “Tested”, versus the unequivocal, “Each Increment should be functionally, load, security, and exploratory tested in a production-like environment before release”.
Don’t Have Too Many
Too many policies can be overwhelming and add unnecessary complexity. If policies become too numerous to the extent that people cannot recall them, then they are much less likely to be followed.
Have a Policy for Changing Policies
Policies should remain dynamic as circumstances change. As such, an important policy is for a team and the wider organisation to have policies for reviewing their policies at all levels of the organisation. This could include the provision of meetings with the right attendees at a regular cadence such as team retrospectives, service delivery reviews and operations reviews.
Policies can also be agreed on for how decisions are made. Examples include, majority vote, complete consensus needed, manager decides with consultation, or decision delegated to the team. The decision rule will depend on the nature and risk involved in the policy under review. Either way, clear decision rules bring transparency around how decisions on policies are made, and they enable organisations to control the delegation of policy decisions.
Monitor Application
Making policies explicit is not useful if they are not followed, so efforts should be made to understand how closely policies are being adhered to. If they are not, perhaps that is an indicator that there is a lack of understanding, discipline, or perhaps the policy is not fit for purpose.
Coaches and managers should not jump to conclusions when policies are not followed, instead this can be used as an opportunity to generate discussion and as a self-management opportunity for the team to come to its own conclusions on how they should proceed.
Summary
The practice of make policies explicit is a powerful yet often underlooked practice. By exploring this practice teams and organisations can equip their teams for greater levels of self-management. This has many benefits. It speeds up decision making, allows management effort to focus on more strategic matters, it's great for motivation, and it helps teams and organisations achieve levels of agility that ultimately means better outcomes for themselves and their customers.
Feature image by Sebastian Voortman on Pexels