Diverge Before you Converge: Brainstorming as a Planning Tool

Innovative thinking is the key to building great software—whether it’s a brand new product or the next release of an existing system.   Done well, the agile practice of release planning provides a great opportunity to innovate.   However, many software development teams—even agile software development teams—approach release planning in a way that actually discourages innovation. They are overly focused on figuring out the “right” work breakdown, and strive for an efficient process that merely “translates” requirements into user stories. Other teams get stuck in a kind of agile “analysis paralysis,” refusing to even start discussing stories until someone does sufficient up-front work and presents them with the “correct” product roadmap.

Either way, these teams are squandering a chance to innovate. Underlying both of these situations is an assumption that somebody has already come up with all of the right ideas—or at least that it is someone else’s job to do so. But innovation requires us to think of things that we haven’t yet thought of. And a well-run release planning activity is a perfect setting to focus the whole team on the process of idea generation.

Of course a planning exercise should ultimately produce some decisions. But we will get better decisions and better ultimate results if our planning process allows for and encourages creative, innovative thinking along the way. In other words, before we try to converge on a solution, plan, or set of priorities, we need to allow sufficient time and space to diverge. Teams often forget this step.

Stories as options

The principal tool for divergent thinking during release planning is the user story. A user story represents a small, independent, and testable piece of software. User stories are a useful tool for requirements discussions between technical and non-technical people, since they focus on what a user can do with the software. “Building a user story” means adding a bit of functionality to the product above and beyond what it already does. A release plan typically consists of a list of prioritized user stories, representing what we think we ought to build and in what order.   By chunking the development work into these small user stories, we can build a little then evaluate, then build a little more and get additional feedback.

But user stories are not just a way to chunk work into bite-sized pieces. They are also a great way to generate and explore options. When we sit down to plan a release’s worth of work, we’re actually not looking for the right answer or the perfect schedule. We don’t want convergent thinking. Instead we are looking for options.

The most successful release planning sessions start with the explicit intention to go broad and to encourage divergent thinking. The more options we can generate, the better position we will be in to choose what to do next. And this is where brainstorming comes in.

Running a brainstorming exercise

Here’s one way to do a story brainstorming exercise. Gather a multi-disciplinary team together in a conference room with a big table. (Or gather a distributed team with videoconferencing and a multi-user collaboration tool like Trello.) Ensure that you’ve got people in the group with different styles of thinking and different strengths—both technical and non-technical. List the features under consideration on a whiteboard or a flipchart and discuss them briefly. Divide the group into clusters of 2-3 people, and pass out index cards and pens.

Ask each cluster to take 10 minutes to brainstorm as many stories as they can around a given feature or features. Explain that the goal is quantity and not quality. Don’t ask yourself things like:

“What are the right user stories” “What is the correct way to build the feature” “What SHOULD we build?”

Instead, ask “divergent” questions like

“What COULD we build?” “What are a couple of small stories we could build first around this feature?” “And if we built those, what could we build next?” “What are some other ways to tackle it?” “What other ideas for stories have we not thought of?”

Timeboxing this exercise is very useful for getting people out of an analysis mode and into a brainstorming mode. After the time expires for the initial brainstorming round, take the opportunity as a larger group to share and absorb what was produced. Here’s where the big table comes in handy, as you can collectively spread out and shuffle the index cards in different ways. Then do another round or rounds of brainstorming as desired.

Converge after you diverge

I prefer to see at least five times as many stories than we can possibly build come out of a brainstorming exercise. Because then we have options.   We’re not constrained to one way of thinking about the problem or the solution.

You might be asking yourself, “How could we ever get anything done that way? We only have a limited amount of time to plan.” Starting with diverging doesn’t have to take a lot of time.   You can hold a brainstorming session for 45 minutes and generate 100 stories. Then spend another half hour doing some high-level affinity estimation. In a little more than an hour, you’ve got a great set of raw materials from which to start.

With these raw materials in hand, then we can begin to converge on a solution, a set of priorities, and a plan. But even as we choose one way to start, we will continually remind ourselves that that there is something we haven’t yet thought of. By ensuring that we start our planning with divergent thinking, we’ll open ourselves up to more possibilities, and be more receptive when that next great idea hits.

User Stories are not Requirements

As the agile approach to software development has gained in popularity, the construct of the “User Story” has also been broadly adopted. While people might have looked at you funny ten years ago if you told them you were “working on a user story,” today most of the popular software project management tools have “story” as a first-class entity.

With that uptick in usage, however, has come the inevitable dilution of the original concept. Many people today think of “user stories” as just a special template for writing requirements. They are familiar with the “As a … I can … so that …” structure popularized by Mike Cohn, and believe that any sentence written in that format constitutes a user story. Others use the terms “stories” and “requirements” almost interchangeably.

Blast from the Past: 2005 “Quick Agile Test”

Here’s something I ran across the other day while trolling through my backup files. After four years of adopting an agile (XP-based) approach internally at Digital Focus, we decided to start selling agile coaching and transition services in early 2005.

As a way of defining what we considered “agile,” I put together a little true/false quiz as a marketing blurb. Agile as a thing was still gaining traction, and I was trying to find a quick way to show people quickly both benefits and potential areas for improvement in their adoption of an agile approach.

What Every Meeting Needs

I don’t consider myself an expert meeting organizer or facilitator. But I do know a thing or two about what makes a good meeting. Like many of you, I have probably participated in hundreds of meetings in my professional career. In my work coaching and running software teams, I have definitely facilitated my share of meetings. I’ve even taken a course or two on meeting facilitation, and read some excellent books.

Based on this experience, I have developed a little rubric for myself about the minimum requirements for a successful meeting. And that rubric is this.

Every meeting needs an objective, an agenda, and a facilitator.

This is not revolutionary or rocket science, but it is violated so often that it bears repeating over and over again.  Here’s a breakdown of these three requirements.

Two Minutes to get Back on Track

I’ll admit it. Sometimes I get into a “funk.”  That’s the best word I can think of to describe a state where I just don’t feel like doing anything. And I’m not talking about the regular, end-of-the-day, time-to-take-a-break type feeling. I mean when all of a sudden in what ought to be a productive part of the day, some apparently-complex set of chemical reactions in my brain leaves me feeling blah and unmotivated.

This feeling can come for me at various times. It might hit first thing in the morning on a day where I know I have a lot on my plate. It might come in the early afternoon when all of the “urgent” things have been handled and it’s time to start working/thinking more strategically. I have noticed that it tends to be at times when I’ve just completed something (like a meeting) and a part of me is resisting making the transition to something new.

All I Really Need to Know I Learned from my First XP Team

(With apologies to Robert Fulghum)

I’m now coming up on 14 years of working with agile software development teams—either as a developer, architect, project manager, coach, or supervising executive. The more teams I work with, the more the problems seem to boil themselves down to a few root causes. And I find myself repeatedly reaching back to my memories of working on my very first Extreme Programming (XP) team.

In early 2001, I took charge of a large-ish team that was just starting to build a new and exciting system for a Fortune 50 financial-services client. I had been reading about XP for much of the previous year and had dabbled with some of its practices. But on this effort, we decided (and received management’s blessing) to do “full-on” Extreme Programming. We moved to an unoccupied space on the ground floor of our building where we set up our team area, and we did our best to follow all 12 of the XP practices “by the book.” (Well, we didn’t really try that hard with “Metaphor,” so make that 11 practices.)

Five Good Times for “Aha” Moments on Agile Projects

An “aha” moment is magical. You’re looking at something and all of the sudden an idea or insight hits you. What if we assembled these two elements in a different way? Maybe it would help to generalize these three disparate use cases?  Or perhaps this perceived constraint is not real after all?  Such moments often yield the ideas that will take your product to the next level. They can even be the germ of a real innovation.

Unfortunately, such moments are also hard to predict or to plan for. How do you know when the big idea will hit? Who on the team is most likely to come up with the next design breakthrough? Most importantly, what can you do to increase your chances of having these “aha” moments more frequently?

“Requirements” vs. Needs

We did a design exercise with the leadership team in one of our global centers a little while ago. We had a lot of fun with the hands-on nature of the activity, and learned a lot from our de-brief afterward.

In our ensuing discussions, I noticed that several of our group used the word “requirements” when talking about the interaction they had with their “client” in the exercise. For example, “My user’s principal requirements were . . . ,” or “One of her requirements was that the wallet . . . ”

I pointed out that nowhere in the materials we had used for our exercise did the word “requirements” appear. Rather, it was all about gaining an understanding of user needs. And I challenged the team to think about the difference between “requirements” and “needs.”

This interaction reminded me of why I dislike the word “requirements” so much in software development. A “requirement” sounds so absolute, so dictatorial, so final. You can almost envision the all-powerful customer proclaiming, “I REQUIRE that the system does this.”

Play a Different Game: When “Planning Poker” is not the Answer

Somehow, everyone learned about planning poker. You know, the game where everyone gets a set of cards with different point values on them (usually in a Fibonacci sequence). Then they vote about the size of a story by holding up their cards simultaneously and work to reach consensus.

That’s a fun way to do estimation in a group, and it is appropriate in many situations. But what if you need to estimate 30 or more stories at a time? What if you just held a story brainstorming session and you’d like to get high-level estimates for ALL of the stories you just came up with? In this situation you don’t want to dig into stories one at a time, and get bogged down with discussions of acceptance criteria for each one.