All-hands-on-deck
Teams should do one user story at a time
Teams should do one user story at a time
It is impossible to deliver quality/value without sharing information. And it is inefficient to share information without collaboration.
The best kind of collaboration is real-time collaboration. If real-time collaboration is for whatever reason not possible, the quality of shared information quickly deteriorates. Having to stop what we’re doing and wait for the needed information to be shared sometime in the future is not only slowing everything down, it is also degrading the quality of work.
For that reason, I strongly recommend working in real time, face-to-face with team members, on delivering expected value/quality.
All-hands-on-deck
We often hear a phrase “all hands on deck” when a situation emerges that needs urgent attention. In a nutshell, all-hands-on-deck is a technique for sharing information in real time. Consider system outage: our service is down and our customers cannot complete their tasks. There is a sense of urgency that is reinforced by the importance attached to fixing the outage as soon as possible. Regardless of how many staff members we need to pull in, nothing at that point is more important than solving the burning problem.
But we don’t have to reserve this all-hands-on-deck approach only for the ‘burning platform’ emergencies. It is very useful to apply that approach to our daily work. After all, what is more important in our job than delivering value to the customers as soon as possible?
So, instead of swarming around the backlog and assigning individual tasks/tickets to individual team members to work on, we pull the most important story from the backlog and then swarm on the story. Swarm as the Whole Team (including non-technical SMEs). Throwing all our resources and humans at the same story at the same time.
The nice thing about this approach is that it is as useful as the classical, emergency driven all-hands-on-deck approach, minus the panic element. We’re not dealing with severity one outage; we are merely dealing with the importance of our daily jobs — meeting and exceeding customers’ needs.
One thing to note, however — the important aspect of all-hands-on-deck is that no one on the team works on any other story until the story that was first pulled from the backlog gets done. Rinse, repeat.
Why do all-hands-on-deck?
Most people observe a systemic issue with projects they work on: typically 100% of the stories often tend to get 80% done. We’re quite good at starting new things, but overall not that great at finishing them. Goes without saying that everyone would much rather prefer 80% of the stories 100% done. That arrangement gives us much higher betting average.
So, how to do it? Try all-hands-on-deck. With all-hands-on-deck approach, we directly benefit from better knowledge transfer. The problems we work on are large. Usually larger than our individual capabilities to hold such large problem space in our heads at once. All-hands-on-deck approach puts us all in the same mental space, in real time. We’re in the same room (or virtual room), working together at the same time. That arrangement greatly increases our mutual comprehension. And that results in higher completion rates.
Another reason why all-hands-on-deck approach is so successful is because it drastically decreases/eliminates hand-offs. When working together in the same room at the same time, the most skilled and the least skilled among us interactively adjust the plan as the development proceeds. Everyone feels safe, useful, a valuable contributing member of the team. Trust quickly gets established and then cemented. We feel that we belong together.
That improves energy and morale. All-hands-on-deck way of working gives us plenty of small wins. One-story-per-person feels pedestrian and tedious after we try all-hands-on-deck. In all-hands-on-deck, every completed story is a win for everyone who worked on it. Which is the whole team. Shared wins tend to produce more creative ‘juice’ than solo wins.
Conversely, shared losses don’t reduce creative juices nearly as much as individual losses do.
Objections to all-hands-on-deck
Let’s examine some argumentation against doing all-hands-on-deck:
Collaboration is hard
Work spaces have traditionally not been designed for collaboration. People are used to isolating and focusing on their job; no one is encouraged to walk around, engage, and collaborate.
Rebuttal: Such structure works well for jobs that are similar to brick laying. We are knowledge workers, and we’re not doing anything remotely resembling the activity of brick laying. We are problem solvers, and the best way to solve problems is to collaborate. We must restructure our work environment to facilitate real time collaboration.
We have no way of evaluating individual performance when doing all-hands-on-deck
If the whole team works on a single story and delivers it, it is hard to know who contributed what and how much and in which way.
Rebuttal: All-hands-on-deck is shown to heighten and enhance individual performance. But the important point is that value delivery is only possible as a team activity. It is team performance that matters.
It seems wasteful to deploy the entire team to work on a single user story
We have employed highly experienced, valuable staff members who are paid for their performance. It seems more reasonable to get each member to work on a different problem, instead of having them all working on a single problem.
Rebuttal: Optimizing for utilization does seem to be the most reasonable approach when managing a team of highly paid experts. However, when it comes to optimizing for value delivery, the math starts to look differently. And value delivery tends to be of more importance than merely making sure all the people on our payroll are constantly busy and fully utilized.
For illustration, imagine a basketball team consisting of superstar players, who are expected to play the major league game. To optimize for highest degree of utilization (i.e., those superstar players are charging a lot of money per game), we give each player their own basketball. That way we make sure each player is 100% utilized, as they are constantly dribbling their ball.
Utilization goal brilliantly fulfilled, and yet the team cannot possibly win the game that way.
We have no experience in pair or mob programming
All-hands-on-deck requires everyone working together, but our staff is only familiar with working in isolation.
Rebuttal: All-hands-on-deck has nothing to do with pair or mob programming. Of course, teams that do regular mobbing are already doing all-hands-on-deck, but mobbing/pairing is not a prerequisite for all-hands-on-deck.
It is possible to be effective at all-hands-on-deck even when soloing. What is mandatory in that case is not starting anything new before we finish what we’re working on.
How does all-hands-on-deck work in our daily job?
As already mentioned, the fact that we are modelling our approach to daily work by emulating the approach the organization takes during those stressful severity one outages, doesn’t mean that all-hands-on-deck implies having to face stressful, unnerving challenges. Simply put, at any point during our workaday activities, there is something that is more important than other things that are vying for our attention. Abandoning the multitasking approach is always recommended, and the team should gather forces to tackle the most important challenge. What is also important is that, once the work on solving the challenge starts, it should not be interrupted by starting something else. Instead, the team focuses on getting the work done, and only after the work is complete should the team tackle the next important challenge.
That way, a smooth flow gets established by the team, and the small wins create an effective and joyful process.
How to start with all-hands-on-deck?
All that’s needed is direct conversation (face-to-face) between collaborators about what’s going on. No gated phases allowed. No hand-offs, no waiting for some resource to become available for the face-to-face next day/week. Everything happens in real time.
Focus on learning by doing. Adopt bias for action. Focus on evolutionary development.
Keep in mind: multi-person teams often do open heart surgery, and they do it many times better than a one-person team could ever do.
Conclusion
Collaboration is the key to success. When collaborating, teams deliver value while at the same time they establish a high degree of trust and confidence. The best way to establish the flow is to collaborate by following the all-hands-on-deck model. Rather than diluting the focus, teams should start together, work together, and finish together. By doing that, teams will eliminate all waste associated with hand-offs, synchronization points, wait states, and other unnecessary artifacts.