Moving the Scrum Team from push to pull

User Story

As a <Self-Organizing Scrum Team>

We want to <Move from task being assigned (push) to choosing the task with highest priority (pull)>

So that we can <Predictable deliver product of highest value> in each sprint.

Further description of the story

In some large organizations the team works on multiple projects in parallel. The parallel projects are organization deliverables which is delivered through work done by various teams. And hence currently the Scrum Team have task specific to projects assigned to individuals.

Let’s go with assumption that it is not feasible to build team for each project. And without empirical proof the organization does not want to change the process.

The problem with this approach is

1. Individuals are focused on completing their assigned project. The team members losses focus on team goals. Decisions taken for achieving the goals of particular project might not be in favour overall application design.
2. These silos also means during each opportunity to inspect i.e. daily scrum, planning meeting, and review, rest of the team don’t have enough interest. And as the projects progresses (in time) the rest of the team have less visibility and understanding.
3. Individual project also means that team members become ‘I’ shaped i.e. specialize in their area but limited in knowledge, in-turn contribution, to other areas of the application. What happens if the team member is off due to sickness? The answer is clear, the project stalls.
4. With individual queues, project management requires more effort. To find the status of each project we need inspect each queue and even then it is an individual’s estimation. Re-prioritizing usually means putting in-progress work on hold and switching to a new task. And If we decide to re-assign the task, it requires to balance several queues.

This all goes against scrum values of transparency, inspection and adaption. The team cannot be self-organized and cross functional. In order to transition to being more predictable and control the risk the team can try few things with the goal for delivering highest possible business value while improving the process.

Work on improving the transparency

The first thing the team can start is with the scrum value of “transparency”. In order for team to work as a team, everyone needs to know what the team goal i.e. what are projects and what are the current task for the project. The best way to do this is to have a physical sprint board. Software systems are good for tracking but not very good at encouraging discussions. A card on the physical board speaks louder than rows on the report.

Promoting inspection and adaption

Stop the daily scrum. Yes you read it right, stop the daily scrum. What a team member say’s is not of relevance to other team members. There is no inspection of the daily task by the team. Instead be creative and try something that would increase inspection. Instead of daily scrum, have daily review where one of the team member discusses, demos, review about their work and solicit feedback. Try things that allows to inspect and adapt. Remember don’t try different things at the same time and track the things you are experimenting is benefiting the team.

T shaped team members

In order to promote the team to be cross functional. Encourage individuals to work on task other than their project. For example, In each sprint one task is assigned to each team member which is outside the current expertise. Again team can work out different ways to achieve this. The important thing is team is doing things to promote building cross functional skills.

Balancing projects as sprint goals

With all the projects running in the same sprint it is hard to define the sprint goal, it will just be the list of stories planned for the sprint. Instead of running all the projects in parallel, try to order them sequentially interleaving between the projects in sprints. For example there are 6 projects and 6 team members, do 3 projects with 2 members in one sprint , the remaining 3 projects in the next sprint and repeat. During the sprint where the team is not working on certain projects it can refine the backlog items for those projects with enough details for subsequent sprint. The team can play with number of projects in the sprint, how to schedule etc. This working on smaller set of projects allows you to define sprint goals for the team to focus and team members to self-organize and work on team goal.

Less the number of queues more efficient it would be to manage and process the items on the queue. The ultimate goal of the team should be to have a single queue where team members pull the highest priority task (while considering individuals comfort, time and priority can be a task little lower than the highest).

Originally published on LinkedIn.