Ship It! LIVEShip It! LIVE
home about services writing contact

We develop, test, and create fine software products, and design creative solutions to your problems.
The development of software is an intrinsically creative process. We are dedicated to improving our mastery of the art.
Links · RSS Feed
Popular Pages

Ship It! is part manual of best practices, part software methodologies book and part a distillation of ideas and experiences of good and bad projects that the authors have been involved in. It migh...
-Tech Book Report
If your shop has trouble shipping quality software on time -- and let's face it, most do -- then this book is for you. If you're a manager, I'd say that doubly so.
-Ernest Friedman-Hill "JavaRanch Sheriff"
That's got to be one of the *best* choice of title since the Mythical Man Month!!
-Kenneth Sizer

Do You Organize Your Work for Yourself? Or Your Team? (Mar 16)

We tackle our work in the way that seems right to us. We look ahead at the work on our plate and do our best to get it done. I often say that everyone makes great choices... given their own context and point of view. Unfortunately, that point of view sometimes leads us to a local optimization, where things look efficient until we step back and take a look at the bigger picture. Then we realize our local optimization wasn't nearly as efficient as we thought.
This often takes shape in how we break out our team's work. Some times we break everything down into layers (horizontal slicing) while others slice the work into smaller, but working, bits of functionality (vertical slicing).

Horizontal feels more efficient because it lets different product area specialists (like SQL or UI gurus or server-side code jockeys) work quickly and knock out a lot of stories. It lets your specialists work alone, and doesn't force them to engage with the other team members. This leads to bursts of productivity, with people in the zone, with their heads down and distractions banished.

The result is a large number of "completed" stories, and, of course, correspondingly impressive high velocities. There's lots of UX work done. Lots of db work done. Lots of server work done. But there's nothing to demo yet, because the work hasn't been integrated. Nothing's actually working or done, except for your stories.

You'll notice this happening when you have to add in "integration stories". These are stories for integrating various layers of work. This is when you discover that the db work isn't exactly what the mid-tier team was expecting. Or the UI team didn't quite understand what the server people put in place. Integration hell is the technical term... you end up spending excessive amounts of time doing frustrating work. Nerves are frayed and tensions run high. Fingers are pointed as people's expectations are dashed again and again.

The alternative is work more "slowly" and tackle vertical slices of work. With a verticle slice, we focus on one story, but we make it work end to end. This means that the UI gurus work alongside the server team, who are working with the database gurus, to get one story completely working. No one can be "done" until the story is working.

What's the advantage? On the surface, we're working more slowly. We're pulling people out of their specialties, forcing them to talk to non-specialist team members. It feels more cumbersome and it feels like you're making less progress. But those feelings are deceiving. We're doing three key things that provide enormous productivity gains.

  1. We're focusing on smaller amounts of work. The thin slices that we complete force us to break down the big stories, then complete and potentially deploy a story before the business changes their mind about our priorities and changes our direction.
  2. We're building a solid team. Forcing conversation and removing and entire category of interpersonal and inter team conflict. Instead of leaving a series of almost working stories, we're discussing those integration points during the iteration and resolving confusion before the code is written. When people do move in different directions, it'll be for a small amount of work instead a series of dozens of stories.
  3. We're removing the integration stories by integrating as we go. No story can be marked as "Done" until it's functional. This is a very different approach and it eliminates the need for integration stories or integration sprints. At any point, the code can be deployed.

This is one of the great secrets of many successful agile teams. They say the work can be deployed at any time, but many struggling teams never quite understand how this works. This is how. By focusing on small slices of work, and implementing it with cross functional teams, the work is added in small, incremental slices. This changes the discussion with business about when to ship new features. It prevents large slides of almost-done code from piling up in chunks of DB work, server work, or UI updates.

I strongly suggest you try this practice for a few iterations. It will certainly feel different, even awkward, at first. It'll be cumbersome as you learn how to work with team members you've only interacted with in frustration. But, as you build up your team wide "muscle memory", you'll find it becomes second nature and you'll wonder why you wasted so much time working any other way.

Category: Agile

© 2007 Agile Artisans.