One common pattern of successful agile teams, is they learn to focus and the right things. They learn to stop spreading themselves too thin. They learn that limiting the amount of their work in progress leads them to more predictable results.
I’ve talked about why keeping your WIP (work in progress) even within a sprint is important. The tool you might use to measure the amount of work in progress is a Kanban board. You might decide that a WIP limit might be #developers – 1 (3-person team selecting a WIP limit of 2). Uh oh… you need to be working together. The big questions that arise are:
· Why is this a difficult premise for many teams?
· How can you overcome this in a software development team?
Why is Working Together Difficult
From the earliest college courses in the topic, we’re taught to break problems down into pieces and solve the pieces independently. As an architect, this means solving problems with
When I introduce limiting “Work in Progress” with a team the first time, it can be awkward. Based on the downsides of multi-tasking, they typically agree to limit their WIP. Shortly thereafter, though, someone is left out, standing without a story of their own.
Learning to Work Together Again
Fortunately, there are a few tactical things that we can do to improve our ability to work together again. Here are a few – in order of my preference:
· Pair Programming. Literally, put two developers together in front of one keyboard and talk about the problem, solve the problem. Developers will sometimes take turns coding and watching often. I’ve seen this work wonderfully, but admittedly it’s scary to adopt if you’ve never done so before. If you’re not ready for this, keep reading.
· Horizontal Slicing. If you must have a 1:1 relationship between your developers and keyboards, then try this strategy. If a user story is a vertical slice of pie, then cut the slice horizontally a few times. In enterprise apps, we typically have the database, the business layer, and the presentation layer. Each layer can be a person’s job. Split them up, and work on them in tandem. Remember that you need to finish at the same time, not necessarily do them in sequence as if you did when you were alone. Establish and challenge each other’s contracts and interfaces with your slide – it might make your solution even better. This is different because you will be forced to come together and make that thing work early and often. I take this as often a decent side effect.
· Micro-Vertical Slice: If a user story represents that sliver of pie – why not divide it up even more and work on it in tandem together. Sometimes stories include both the admin side and front end. Tackle both at the same team, but stay close to each other’s work. This one will require even more conscious effort because it might be easier to separate and do your own thing. Try to avoid that. It’s not as natural as Horizontal slicing and runs the risk again for independent lonely coding again – but with some discipline, I’ve seen this work.
· Rougher-Finisher Pattern: Maybe between a pair of developers, someone is a better sledgehammer person and another is a better pocket knife. Perhaps have that sledgehammer going and have someone coming back in over again to refine. Do this only if you both agree it’s equitable and not an excuse to be sloppy. This isn’t my favorite, but if the other three don’t work for the situation, it might be worth a look.
What If It Still Hurts
Do it more often. In this world, you’re not doing it right unless you’re stepping on toes a little.