The Keystone Habit: Thin Vertical Slices

What's a keystone habit?

A keystone habit is a practice that can make-or-break an organizational change. In a real archway, pictured right, if you forget to add a keystone, or if you remove the keystone, everything else comes toppling down. Culture hackers learn to recognize keystone habits and focus their energies on doing the simplest thing possible. Often this means focusing on just one change at a time.  If we've taught people what to do in times of stress, the new habit is more likely to stick. For example, if our project is running behind schedule, instead of doing mandatory overtime, do thin vertical slicing!  Photo Credit.

What's a Thin Vertical Slice?

The biggest difference between plan-driven requirements and agile user stories is in the way we break up the work, as illustrated for this sample web shopping cart application, below. Plan-driven approaches divide the work by skill, for example, UX designers focus on the presentation layer, software developers focus on the application layer, architects focus on the services layer, database administrators focus on the data layer. Kick-start a project in a plan-driven fashion, and because of dependencies in the work, the only people that actually start working are business analysts, database administrators and architects (and maybe UX designers). Developers and QA staff sit waiting for the back-end systems to mature.
In contrast, agile teams break up the work by business value. As illustrated in the shopping cart example below, we could ask the whole team to focus on the Search Products part of our application. Initially teams will follow their old habits, and only the analysts & back-end folk will start working. No worries, since this is a keystone habit! Since our focus is narrow, we finish soon, and developers/QA get involved immediately. Inevitably someone discovers a design flaw--and while the system is still fresh in everyone's minds, we re-design it to fix the flaw.

A Rose by Any Other Name

Synonyms: Story Splitting, Who-What-Why, As-a / I want / So That, INVEST
This past week when I ran a workshop for Agile Philly on Thin Vertical Slices, several people told me they were familiar with the idea but not by this name. They also never really understood it until they played the Story Splitting game (ask me, I'll be happy to run it for you). What I've found is that  people get overwhelmed with the canonical story template:

As a fitness enthusiast
I want to buy my favorite style of footwear for my workout
So that I can save time & money as compared to retail store shopping

Instead of trying to answer all three parts of the story template above, I coach clients to focus on the what, or the title of the user story.  The title should be 1-3 words, so sticking with the example above, the story's title is buy favorite footwear.

Assumptions

• Vertical slices must be INVEST-worthy: Independent, Negotiable, Valuable, Estimable, Small, and Testable. The focus on business value tends to lead us to good slices, but if this acronym is new to you read more about INVEST-worthy stories. 
• We believe the design is never really done until customer's problems are solved, so we optimize for validated learning--for end-to-end delivery of business value. If you know for certain that the market is wiling to pay for your next feature set, and there is no risk in implementing it, don't slice--just go!
• Slicing is a form of planning, and it takes time (1-2 hours per week for the whole team). We only want this overhead if it reduces our risk or doubt, that is if we can validate our learning by deploying & trialing working solutions.
• Slicing depends on automated regression testing. Short of regression tests, we can't afford the re-work costs of updating the design as we move from one slice to another. Note: test automation may not be what you think. See James Shore's Customer Tests.

The Essence in Just One Slice

Given a big scary idea, a vision statement, or an epic user story--what is its core value--the essence? Focus on the WHAT. What could we do in the next hour to learn whether our solution is better than doing nothing? Of course we can't validate the entire solution in an hour--but if every hour we're validating some part of the next most valuable feature or risky assumption, then we're learning very quickly, and we'll deliver sooner. When we deliver sooner, we're agile. When we build upon everything we learned, we increment towards a full solution. I'd rather have something that works for a limited set of customers, than something that doesn't work at all. Now that we've pushed our thinking to an extreme, let's think bigger--what could we learn in a week? Could we make a product increment that we could demo to a friendly customer or business leader?

Why Slice So Thin?

Want greater productivity? A good slice helps us deliver less, better. Why less? In surveying a cross-section of the industry, the Standish group reported in 2002 that 64% of software features are rarely or never used--see a summary of the report here. If only we knew in advance what that 64% was, we'd more than double our productivity! Wait a second--there is a way to find out sooner... Thin Vertical Slices! It's the keystone habit to agility!

What's a Good Slice?

• focus on the WHAT. A good slice is the next most risky or valuable piece of our epic / vision / business ask / solution. (see Essence, above).
• slice only what we need to understand next, that is, we're doing progressive elaboration. If we have external dependencies, vendor contracts, or long feedback cycles, we'll have to do some big slices up-front--just don't go thinner than necessary to coordinate with the plan-driven folk.
• after you know WHAT to make, cross-check it: ask WHO cares about it. The WHO should be a paying customer, or someone outside the building. Even batch jobs and admin tools deliver value to the paying customer--they reduce the cost of ownership. Sometimes a story/slice is so granular the paying customer has no idea it exists--in which case I normally go up a level or so to be sure they care about a parent story/slice. The WHO of a parent is often the same for all children, and I may not go to the formality of tracking WHO for all children.
• after we know WHO we're trying to satisfy, empathize!  WHY is the seed for innovation--this is a huge difference between "requirements" and "stories". We're supposed to understand why the customer wants the WHAT, and look for a better way. As Henry Ford said, if you asked people WHAT they wanted, they'd just say "a faster horse". Asking WHY helps us understand that getting from point A to point B faster is something people would pay for, and leaves room to innovate on how to accomplish the goal.
• a good slice is INVEST-worthy (see above)

The Keystone Habit of Agility: Thin Vertical Slices

If you get thin vertical slicing right, everything else agile comes along for the ride. When I was still learning how to explain this idea I asserted the following on twitter:

Minimalist Agile: thin, vertical slices + WIP limits + progressive elaboration (what's missing that won't be induced by these?)

@RonJeffries responded by asking about priority, tech practices and teamwork. My response today: Thin vertical slicing, as defined above, only slices off the next most important thing--that's value priority and progressive elaboration. As we push towards infinitesimally thinner stories, people are coerced into working on the same thing at the same time--both limiting WIP and forcing them to work together. Practically speaking, there may still be hand-offs, but it's still teamwork when everyone is focused on the same goal of completing a slice. I admit our whole archway will topple if we don't have a good foundation on technical practices. I've listed that as an assumption above.

The Keystone Habit At Scale

The beauty of simple truths is they apply at varying levels of hierarchy. While we get benefit from thin vertical slices at the team level, their true impact is realized with strategic & program level planning. Thin Vertical Slices are named in a language business leaders understand--and as Alistair Cockburn notes, this creates a Cooperative Game. Business leaders see the slices, and ruthlessly prioritize them--which is exactly what we need to build less, better. At some point, as Jim Highsmith reports in Agile Project Management, the business stops picking slices under a given epic--and they move on to slices under another epic.
Since slices are INVEST-worthy, we can schedule them in any order, making the Cooperative Game of prioritization easier--simple rules bring complex behavior. Business leaders start trading turns or pooling their budgets to get slices of mutual benefit. Vertical slices also help the businesses move to a SAFe (Scaled Agile Framework) mindset of release trains--if the features aren't in this release, they can be on the next one or the next one--we release early and often. Thin/small slices give us rapid feedback in terms of integration, customer reaction, and other learning.
At scale, I've personally coached a few customers with 300-400 developers who coordinate their work with Thin Vertical Slices. Executives like it since it promotes visibility, developers like it because it promotes autonomy and creativity.

A Keystone Habits is Just the Beginning 

A keystone habit is not a panacea. It is just what we must hold on to in times of stress. We need plenty of agile practices to successfully launch a productive agile culture. If we stay focused on thin slicing, though, and use thin slicing to reduce our stress, I'm convinced we'll keep our agile culture alive and well.

Acknowledgements

Thanks to Bob Gower for giving me a name for this idea--his talk at CULTUREcon Philly, "Kicking the Habit", will be summarized on this blog soon.   Similar thinking can be found in Charles Duhigg's The Power of Habit, and Martin Seligman's focus on well-being instead of pathology. Michael Margolis also teaches us that our new story must be grounded in the old--we can't simply abandon or ignore the old ways of thinking. Instead, when we want to change an old habit, or a culture, we seek to understand the keystone habits that exist, and build from that foundation as we replace the keystone with something new. Thanks also go to my colleagues at Rally Software who have helped me think out loud as I've been testing and formalizing this idea--Mark Kilby, Yvonne Kish, Longda Yin, Ben Carey, Chris Browne, Ann Konkler, and others!