The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 227 , trackbacks - 0

My Links



Post Categories

Get into the flow with Spinning

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.

Print | posted on Friday, December 23, 2011 1:55 PM | Filed Under [ Thinking outside of the box Spinning ]



# re: Get into the flow with Spinning

Another question.

What is the scope of this methodology? I can see how you could create 1 day feedback cycle for projects with GUI like web-projects or client applications.

But what about infrastructure projects? What about drivers and services? It's sometime very hard to notice the change. Let's say it takes 3 days to found out some naughty not-determenistic error. What would you show customer in that situation - that is while developers are trying to localize the problem? There are problems that take several days before you could see any progress in them.
12/23/2011 11:53 PM | FallenGameR

# re: Get into the flow with Spinning

@FallenGameR: This is an interesting question because it points at the purpose of Spinning. Why and when is Spinning needed? It´s needed when requirements are uncertain. This is the default. That´s why Spinning defaults to 1 day cycles.

But if requirements are perfectly clear, Acceptance frequency can be lowered. (Just don´t overestimate the quality of requirements :-)

There´s one case, though, where requirements are very, very clear: with bugs. If a program crashes, then the requirement is obvious: change the program in a way so it won´t crash anymore. That´s it.

That´s one part of your scenario at least. So for bugs it´s ok, if fixing takes longer than a day without feedback from the customer. The developer knows very well if he´s fulfilled the requirement.

Infrastructure in general, though, does not make a difference. Whether someone wants an invoicing application or some ETL process really should not concern development. In both cases requirements are fuzzy. But even more importantly in both cases you want to give the customer the chance to change his mind any day.

If it´s hard to notice a change, then why invest in the change at all? If the investment is needed, then the change should be obvious (at least to the trained eye of the customer). If the final change is obvious there are certainly intermediate levels of completion, which can be discerned. It´s these levels Spinning is aiming at every day. This works for infrastructure like for GUI projects.
12/24/2011 1:11 AM | Ralf Westphal

# re: Get into the flow with Spinning

I'm thinking about this concept and having several problems/questions:

1. Let's say you have a team of 4 developers. Do you think all 4 developers should work on a single slice?

2. Don't you think that swarming sounds interesting in theory, but extremely hard to apply on practice?

3. Can you give some concrete examples of slices for GUI application? And describe how to swarm on them?
1/12/2012 2:25 PM | Michael Dubakov

# re: Get into the flow with Spinning


ad 1: Yes, put as many devs on a feature or feature slice as makes sense in terms of what has to done. Only have 1 feature/feature slice on your team´s plate. Limit work-in-progress to 1 (WIP=1). Only that way features get implemented as quickly as possible. Only that way feedback can be generated as quickly as possible. Speed up the learning cycle.

If need be, keep a dev out of feature implementation for emergencies.

ad 2: No. "Swarming" is not difficult. It´s just different. You need to learn it. You need to learn to design, you need to split code into components to work on concurrently. "Swarming" is not difficult in terms of technology, tools or method. It´s a cultural thing. But it´s worthwhile to do: team cohesion increases, speed increases, flexibility increases, stress decreases.

ad 3: You question is a bit abstract. But I´ll try anyway:

Think of a Tic Tac Toe game: a window with a game board. Click into cells on the board to place crosses/circles.

2 interactions: start a new game, click into cell to make move.

3 features: start new game, make move, check for winning constellation.

Which feature to tackle first? You choose :-) Any is possible. Let´s go for "make move".

What kind of functional units do you need? I don´t want to go into design issues here. So let´s assume we´re talking about frontend and domain logic.

For each "concern" create a component which means create a contract first, then send off 2 developers to work on the frontend component and the logic component respectively - and concurrently.

Once they finished their work and tested their components you integrate. Done.

Think of doing it differently: assign the feature to a single developer. He´ll need the combined time. So it´ll take longer. Likely you´ll assign the other dev to a second feature. He´ll have to work (at least in part) on the same code as the first dev. Conflicts are likely to arise.

So I´m recommending assigning the whole team to a single feature. Higher speed, less conflicts.
1/12/2012 3:23 PM | Ralf Westphal

# re: Get into the flow with Spinning

WIP = 1 sounds too extreme to me. It is an ideal case. If you have a large team with 12 people, clearly swarming on small features will be inefficient. It is not so easy to parallel work for 6 pairs. Let's say you want to create simple feature "login using Twitter account". How many people should work on this? I doubt that more than 4 makes sense.
1/13/2012 2:07 PM | Michael Dubakov

# re: Get into the flow with Spinning

@Michael: As I said: as many devs as is reasonable for a feature. If that´s 4 out of 12, then thats fine with me. Put the rest to good use on other features or bug fixing or whatever. Sure.

But do it this way is different from starting with "a pair for each feature". That´s maximizing WIP.

Also: for all devs on all features concurrently under development the goal is to deliver at the end of the day.

Whether 12 devs can be a team or how the application is designed (bounded contexts, partitions) I don´t want to start discussing here. That´s different topics altogether.
1/13/2012 2:50 PM | Ralf Westphal
Post A Comment

Powered by: