When I first join a team as its ScrumMaster, I issue two nonnegotiable rules (which is the most polite and uncontested way to make changes). They are connected to my definition of two types of teams: "ordinary" and self-organized.
Ordinary teams can decide whether they want to be self-organized. If they do decide to self-organize, they observe a special set of rules that dictate what must be done to become a self-organized team, and they get special bonuses because they are working as a self-organized team.
A self-organized team is a new type of team. Self-organized teams are motivated by their environment, goals that were produced in such an environment, and the team itself. For example, the main task for a self-organized team is to follow rules and finish everything in a sprint.
These simple rules are enough to generate awesome results. But to finish everything in a sprint, the team must know:
- How many tasks they can consistently perform during the sprint (velocity)
- Why their velocity is 50, not 500 or 10
- The product and their collective strengths and weaknesses (self-awareness) to plan the sprint effectively; otherwise, they will not complete it successfully
- How to pay more attention to planning and, in the retrospective, to define what went badly and generate a list of lessons learned
These are only a few of the actions, among many, that the team must undertake in order to perform all the tasks in the sprint.
For self-organized teams, I also offer the following bonuses (I recommend reading about Motivation 3.0 in Daniel Pink's book Drive: The Surprising Truth About What Motivates Us
- They are eligible for potential rewards on a quarterly basis.
- Their time is flexible. We do not care about the when (i.e., are they in the office from 9:00 a.m. to 6:00 p.m.?). Instead, we will care about only what they do.
- There will be two additional parking spaces per team (in one company, this was considered highly important).
- There will be dedicated time to work on additional projects of their choosing, but those should be in the company's field of work.
These bonuses can help motivate teams to move forward and do their best.
This approach is recommended when we observe problems with the company environment, wherein more than 60% of the people do not know why they should do something or improve their processes and products. The main goal is to find those who still care about their current state and where they want to be, and with their help start the transformation.
But that’s not all. We must also integrate process-related issues into career levels. For example, a senior developer must not only be a good senior developer but also care about development rules and manage two to three junior developers to ensure that they are moving toward the self-organized team. Career exams must also contain questions regarding process and environment, helping to create an environment that motivates team members.
Integrate the new approach in each sphere of the company's business units. (How well do we track the sprint? How do we check on the team?) This step must be completed in parallel with the previous steps,
We need to sell the new way of working. Companies don't really know what they want until they have seen it, so the most difficult task is to take the first step. Do not expect Scrum Teams and team members to know how to define velocity or run a grooming session, for example, if they haven't seen a working prototype. All of that should be part of the team's and company's transformation process.
Example of a self-organized team
One of the main tasks of a self-organized team is to finish all items in the sprint (and not on Friday evening!).
- To close all items in the sprint you must know your velocity so that you can enter the exact number of items that you can solve; otherwise, you will never solve all the issues in the sprint.
- Once you know your velocity, do your best as a team to try to reach it. Try different approaches, even those that seem unconventional. Try different approaches toward how to work with tasks in the sprint, how to plan correctly, or whether to assign the tasks to someone. The main idea here is do not stop trying. Within three to five sprints, you will have your number. A common mistake is to find an approach, settle with it, and not try new ones. The outcome should be a list of lessons learned.
- To determine your team's velocity, hold events, such as the retrospective and the daily stand-up, and plan effectively. Do not hesitate to discuss what went wrong during the sprint. Remember that one small issue that you missed or did not discuss leads to the point of no return.
- To discuss important issues in the retrospective, you must be open to the idea. Remember the three main Scrum pillars:
- Transparency. All relevant aspects of the process must be visible to those responsible for the outcome (team). This requires a common standard and nomenclature (development rules) among the Scrum Teams.
- Inspection. The Scrum process promotes frequent inspection of the artifacts and progress to identify and correct undesirable variances. Inspection occurs during the sprint planning meeting, Daily Scrum, sprint review, and the sprint retrospective.
- Adaptation. After inspection, make adjustments to the processes and artifacts to minimize further deviation from your target goal.
It's not uncommon for teams to become stuck in the self-organizing phase, because not everyone is open to working in a new type of team, or some are afraid that they'll be fired if they talk about problems. But if members will not discuss issues, then the whole team succumbs to the problems, and I am not sure that such a company can compete in the marketplace.
Each step has substeps, which are the most important in the transformation process. The team should meet with their ScrumMaster to discuss whether they will take this direction and prepare the necessary milestones.
The approach leads to positive results. When we applied this approach in our company, we observed a 300% increase in almost all metrics.