On leading a new team, I’m definitely trying to be as open to trying new practices particularly as I feel it is an important part of The Beginner’s Mind (topic to be talked about at InfoQ). One of the new practices we tried last week was swarming work on a user story.
Normally, our natural work in progress limit for development is limited by the number of pairs we have on the team (although not all tasks need pair programming). This time, I’m the odd one out, acting as tech lead and needing to do a handful of other activities including working to maintain constant flow between our BA and QA functions and guiding the development in the right direction. In a different world, I would have started a story and with other duties, probably be quite interrupted in flow to completion.
This time, we broke down a story into as many tiny tasks as possible, discussing those that needed some design elements, or identifying those tasks that could be taken in solo (such as knowledge gathering with report back) and the three of us worked on the same story. The result was a very minimal work in progress limit and actually, we made a lot of progress in a rich environment where we are learning about not only the constraints of the current build and development systems, but working out the best ways to implement what we need and deliver value.
I’m quite happy to report that I’m really liking the swarming on stories. It helps me feel involved in the way that things are going, rather than keeping on top of too many ongoing threads. I do wonder how many people it would be to scale to, but for now, it’s working for us. Inspect and amplify, or inspect and adapt!
Picture kindly borrowed from Max xx’s Flickr stream under the Creative Commons licence.
Cool idea!
I think there is a need for a bit of discipline in the approach you describe to ensure that you only do what the tiny task says and don’t go off and do more than that.
We tried something similar a few months ago where we split up a story in a more coarse grained way – one pair worked on the backend side of it and one the frontend – and it ended up that the backend pair wrote the code for the backend of the next 5 stories instead of focusing on just the one story we were doing.
It took like 5 days until we were able to show any end to end progress at all.
It sounds like the tiny tasks are a better way of handling that problem though, neat.