I'm working with a team that have (as do we all) a tendency when under stress to fall back upon what they are comfortable with—in particular, to serialising their activities. "We can't x because they haven't finished y because they're waiting for z..."To help them remember that this isn't the best move they can make, I've devised this symbol to display in the team area. You are welcome to use it yourself.
No Serialised Activities by Keith Braithwaite is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.0 UK: England & Wales License.
Based on a work at 1.bp.blogspot.com.
8 comments:
Fantastic!
Eh? What's the alternative?
Collaborate, work in parallel, and deliver value earlier. Integrate earlier. Start tracking to those you depend on before they reach their finish line. Simultaneous phasing, not serial.
@Mike,
The alternative is to run as many kinds of activity interleaved and in parallel as possible (while having as few discrete items of work in progress as possible).
On the one hand we could say (in the context of a Scrum-like process) "we can't commit because we haven't finished estimating because they haven't finished the acceptance criteria because those other folks haven't finished writing the stories". On the other, we could say "these stories have been written this much so we can have these conversations to explore these criteria well enough to commit to this" And off we go making progress.
@keithb
So with (1) the activities are still serialized but there are multiple streams with different offsets, so there's always something to do.
And with (2) the activities are still serialized but you break them down into smaller pieces so that the developers can start work after only part of the analysis has been completed.
Is that correct?
@Mike,
I'm not sure to what your (1) and (2) refer.
I'm also not sure we agree on what "serialised" means. I think it means "one comes after the other". The mode of working that I want to encourage is exactly as John described.
(1) and (2) referred to your paragraphs in the reply above mine.
I agree with your definition of serialized. For example, releasing into production comes after development. Trying to ban serialization doesn't make any sense. It's a natural part of development.
What you appear to be suggesting is that we parallelize multiple serial activities.
And that we should try to reduce the amount of serialization within those tasks and choose a more collaborative approach - less "over the wall" and more conversation.
Is that a correct interpretation?
@Mike,
It's true that we cannot release into production a feature that has not yet been developed, so in that sense deployment comes after development. What I'd like to discourage is thinking that a large amount of development has to be complete before any deployment occurs, as we often see on project plans that have a lengthy "develop" activity followed by a "deploy" activity. There are organisations mature enough to deploy pretty much feature-by-feature, and features may be deployed when partially "complete" and redeployed later with more scope.
Similarly, one developer can physically only do one thing at a time, so in some sense writing a test and coding to it are serialised in that the coding comes chronologically after the test writing. And that at the level of an hour, or a day, and across a mulit-person team, so much of each kind of activity (and many others) goes on in various orders that it doesn't make sense to talk about, plan or track, a test-writing activity and a coding activity separately.
Post a Comment