Spinning as described in my previous article is all about flow. Its premise is: flow can emerge when work is partitioned in small, evenly sized chunks processed in a smooth manner.
There is a constant input of requests to the development team. A backlog is filled with strategically important requirements, support is reporting bugs, feedback requires changes, management wants to see ideas realized on short notice. Under these circumstances any plan becomes obsolete within a day or two. Or a lot of effort needs to be invested to stick to the plan.
Spinning is different. It does away with planning. So there is no plan anymore that can become obsolete. Instead each day the team decides what to accomplish, which means how to deliver a small value increment to the customer at the end of the day.
A value increment is…
- …at least whatever a customer can give feedback on. In some form or another it demonstrates the team´s understanding of the requirements. This is of course done best with…
- …working software the customer can Accept and actually use.
Value is generated whenever the customer´s trust is deepened. This happens when she feels to be understood. “Those guys really know what I mean! Yeah, they can relate to my problems. They home in on a solution. I can see it.” Working software is the best way to build trust. But sometimes less will do, too.
Software development is a communication process. That means messages have to go back and forth between customer and team. Spinning is setting a minimum frequency for this: every day the customer has to give feedback and tell the team what to do next (request), every day the team creates something valuable (response) to elicit feedback from the customer. Whatever is necessary to sustain this frequency should be done. Whatever stands in the way to obtain this frequency needs to be cut away.
Constantly moving closer to satisfaction is the purpose of Spinning. The basic means for that is to satisfy constantly – even if just a little bit. Satisfaction and trust are not built milestone by milestone or sprint by sprint, but day by day.
Whatever requests are fired at the team get processed day sized chunks:
The team is viewed as a “request processor” running in preemptive multitasking mode. There are several tasks to accomplish: a backlog needs to be burned down, bugs need fixing, operations need to be helped… A team not only needs to decrease latency, but also to hide latency.
With Spinning the ideal is to assign all developers to a single request per day (WIP=1). See the first three days in this picture:
On day 1 a request gets finished, on day 2 work starts at the next request. It continues on day 3.
But this ideal cannot be held up every single day. Sometimes developers need to attend to emergencies. If triage can schedule processing them for the next day, all´s well. Then developers just get allocated during daily work organization to more than one request.
But Spinning always reminds the team: the more developers are assigned to a single request, the better. More developers working on a request lead to faster implementation. Yes, producing a feature can be “industrialized” by distributing work. That´s at the core of Spinning; that´s why planning is so important before implementation. It´s all about speed to get feedback on working software.
On the other hand is illusionary to assume a team can focus on a single feature for several days. Support, operations, the boss´whims always cause disruption. Therefore the focus horizon is just one day. Most sudden requests can be postponed until the next day to be sliced, analyzed, organized, and implemented in an orderly way.
Sometimes however requests really require immediate attention. Such interruption of scheduled request increment implementation needs to be avoided. Hence it might be necessary to allocate one or two team members to be on standy-by for such work. If nothing happens they can work on a learning project or maybe a non time critical spike solution. But if an emergency calls for attendance, they are there – and the rest of the team can still quitely progress until the end of the day.
What´s the difference between Spinning and most teams? Most teams work like this, don´t they? They try to find a balance between progress and emergency handling. Yes, true. But they do so less systematically. And they constantly feel bad about it. They are working under the impression, software development should be different. They should be able to focus more. They should be able to keep the boss out of the team room for a couple of days. They should not be available for support.
Well, true, that would be much better – but unfortunately that´s not what the current culture of most projects allows. Spinning tries to take the burden of feeling bad off the backs of developers. It makes interruption the norm. Because every day the team is starting with a fresh view on what´s in the request queue.
Sure, teams doing Scrum and Kanban can organize themselves in a way to follow a process, and at the same time cater to emergencies. And they do. Every day. But this is outside of the process. The process is about focus. (Scrum more than Kanban.) To deal with different levels of urgency the process has to be tweaked.
Not so with Spinning. Spinning embraces imponderability. It´s defining a basic process mode
- Focus on delivering customer value at the end of every day
- Understand, plan, implement, check software in a systematic way in small increments
- Understand, plan, check software as a team to reap the collective intelligence of the team members, and disemminate information in a natural way
- Keep the Work-in-Progress at 1 – which can be different 1 each day
This helps to achieve two seemingly opposing goals:
- React to changing priorities: Spinning satisfies the needs of different stakeholders (customer, support, manager) by daily allocating developers to requests according to what seems to be a valuable increment.
- High speed development: Spinning satisfies the need for quick feedback by producing value every day with as many developers assigned to as few requests as possible.
Think of Spinning as a software production machine taking in raw material of very different size, shredding it into thin slices, and then transforming these slices into a steady flow of small increments of working software.
Spinning is true to the values of the Agile manifesto:
- Individuals and interactions are highly valued. That´s why the team is supposed to work on understanding, planning, and checking collaboratively. This of course includes the customer. Also on the next level of abstraction the very frequency with which to elicit feedback from the customer during Acceptance is a testimony to this. Delivering working software and receiving feedback are interactions.
- Working software is at the core of Spinning. Every day a working software increment has to be delivered. That´s also why Acceptance is so important to Spinning. When working on small increments on short notice, documentation loses value. Even a backlog loses value.
- Customer collaboration is the very reason for Spinning. Acceptance by the customer is the most important activity during software development. Only in order to satisfy the customers strict Acceptance rhythm specifications need to be given. Specification follows from Acceptance, not the other way around. Also the high frequency of Spinning make contracts with concrete scope definitions and delivery plans obsolete, since the customer is supposed to steer the project on a daily basis.
- Responding to change is the second reason for daily completion of requirement slices. No work in progress should be on a shelf at the end of the day. That ways the team is open to respond to any change the next day.
Through an orchestrated effort of individuals Spinning creates a constant flow of working software in close collaboration with the customer by responding to change at any time.