Sketchnotes of Agile Immersion

Here are the sketchnotes from my November Agile Immersion workshop.

These sketchnotes were done by a business partner of mine, Jenny Trautman of evenview. Sketchnotes aren't the main thing evenview does -- sketchnotes are an artifact. What evenview does is help people bring innovative strategies into focus. They lead fun, high-energy meetings using interactive visuals that draw a team together. With their support, groups collaborate to develop a shared vision, create a plan for action, and implement their ideas. Use them for your next strategy meeting or kickoff.

By the way, this workshop is designed for everyone. No agile experience or programming skills required. All types of roles have found it benefical: product managers, marketers, managers, office managers, business development executives, developers, testers, CFOs, and etc. Check out this interesting blog post from a recent non-developer attendee.

Personal Kanban Retrospectives

At the end of each week I do a quick retrospective on my use of Personal Kanban, the tasks I've completed, and the week in general. I don't do anything elaborate or time consuming. Just a simple evaluation of how I'm doing.

I use two particular approaches to my personal kanban retrospectives more than any other.

+s and Δs

With Pluses and Deltas I think more about what worked well and what I want to change going forwards. Sometimes I use 'Regrets' instead of 'Deltas'. I do look at the tasks I accomplished, but with this approach my mind considers more than the tasks. For example, some of my notes from prior retros include things like: relaxed, haven't been inbox-zero for a while, did I forget to plan?, someone important linked to my blog post, got a great lead from someone, so-and-so is unreliable, such-and-such didn't pan out, well prepared for next course, successful partnership with so and so, good blogging this week, etc. I use index cards for this style retrospective.

Most Successful / Least Successful

The other approach I use lots is to simply arrange my completed tasks by how I feel about them. Some I feel really good about. Some weren't so successful. Maybe some are neutral.

I'll take notes, again on an index card, on these high points and low points.

Not a Commitment

What I don't do is compare my actual achievement against a plan. I do "plan" my week, but it's not a commitment to specific tasks. It's more of a re-prioritizing of the backlog and preparation for the days ahead. I use that time to make sure I don't miss any commitments or fail to prepare appropriately.

I hope you found this useful. What kind of Personal Kanban Retrospectives do you do?

---

Register now for my 11/5/12 Agile Immersion Workshop. This low cost day-long hands-on workshop will guide you through an agile project, from inception through the first couple iterations. Through this immersion, you'll understand agile 1st hand. Lunch is included.

What I Discovered About Personal Kanban and Getting Things Done

Not long ago I wrote about some changes I made to my personal kanban. Today I'm writing about why I do this. Much has been written about the benefits of using Personal Kanban and Getting Things Done (GTD) so I'm going to stick to what I personally get out of it.

I get uneasy when I have lots of unfinished projects around the house, half-read books languishing, things I've started and have forgotten about. ADD runs in the family so I'm likely an undiagnosed sufferer. When I rediscover something I once thought was important and have since forgotten, I remember why I thought it was important and feel bad for having not finished it. I feel stressed about needing to put one thing aside and finish the newly rediscovered badger. It's a little stressful. Not "I can't take it anymore!" stressful. Just a nagging background stress. There are plenty of stressors in my life so I don't want to add more if I can help it. And I can help it.

When I first started using them, GTD and Personal Kanban made matters worse. And better. It made me feel worse because now everything is visible -- all the half finished projects and incomplete initiatives. Yet it made me feel better, knowing that I won't forget anything. It also helped me prioritize my work explicitly and stick with that prioritization for as long as that prioritization made sense. My kanban helps me remember why things are in the state they are in, being intentional about what I choose to do.

After a while, GTD and kanban helped me reduce the backlog of partially completed work. It helps me focus on work already started. It helps me not start new activities that are of equal or lower priority -- or things that have a lower Cost of Delay. Seeing how much I have in process helps me to stop starting new work and to start finishing what I've already got going on.

I also discovered how much longer it takes me to finish tasks than I thought. Oh, yeah, "blog post"; I'll just typety type, a little proof reading, maybe a picture and I'll be done in half an hour. Heh. No, not really. Takes me a bit longer than that for the type of posts I do and the care I put into them. And there are all the other things: tweet it, email it to the person who requested I write about it, put a notice about it on some appropriate LinkedIn group, get interrupted for dinner, go to an Agile Atlanta meetup, decide to finish it tomorrow after work, and ultimately edit this post again because I thought of something else that should go in, like this paragraph. Anyway, kanban helps me understand that I'm an overly optimistic estimator. Understanding that helps me put stuff in the backlog instead of just starting it.

Now I feel much better. Sure, there are new things that come along that are Important, Urgent or have a High Cost of Delay, and I'll increase my WIP for a while. And that can be stressful. But it's a different kind of stress. No more is it "I have all this work and it's out of control". Now it's "I have some important work to do, but I know what it is, what state it's in, where it is stored, when it's due, and I feel in control." I still have a lot I want to do. But I'm in control.

Sprint "Commitments" are an Amortized Death March

Matt's tweet is provocative: Sprint "commitments" are an amortized death march.

If sprint commitments lead to a death march, something is wrong in your organization. Sprint commitments could be used by poor managers to browbeat the team.

Hey, you guys committed to this. I expect it to be done!

Not good.

The risk of a death march, however, is not the reason to not have a strong sprint commitment. You can (possibly) fix that problem. You can (possibly) have good, enlightened managers. Besides, there are many ways to use Scrum poorly. Should we throw out every misused practice?

No. But sprint commitments are dubious.

It's not the sprint commitment we are after. It's not what we really want in the end. It has no value on its own. What we're after is that thing we hope to get from having the sprint commitment. What we hope to get is a team that is committed to each other, working together to finish what they set out to do. We hope everyone works on what we agree to work on rather than whatever darn thing anyone wants to do. We hope to not have unfinished work at the end of the sprint.

Sprint commitments → no unfinished work at the end

Too bad this is a fallacy. The fallacy is that for each desired outcome B there must exist a cause A.

A → B

In complex adaptive systems it doesn't always work out that way. I might even say it rarely works that way. Whether the sprint goes well or poorly, there are side effects of such policies. But this post isn't about the side effects. For the manager, though, when the sprint goes poorly the best possible outcome is...

Darn, this is harder than anticipated. But I committed to getting it done. Guess I'll put in some overtime.

If what is committed to is generally kept low (appropriate), pace should be sustainable over the long run even with some rare overtime. When appropriate overtime does happen:

That stunk! Not doing that again. Let's commit to less and plan better.

In this way, sprint commitment should drive careful planning.

But is careful planning in batch necessary or is it waste? It can be useful in some contexts, but bogus in others. What's the point of a sprint commitment if you are committing to something very small, knowing that you are going to add more work to the sprint? If we plan less work to meet a strong sprint commitment, and also plan to add more work to the sprint later, then we are approaching continuous planning and might as well make the jump to iteration-less flow (e.g. and use Kanban).

We want a stable velocity. We want teams to be predictable. But requiring a strong sprint commitment is neither necessary nor sufficient. It's other stuff that makes us predictable, namely: finishing sprints cleanly every time; good backlog grooming practices; good story estimation practices (if using Scrum); limiting WIP; not starting work you can't finish in time; the "keep it working" principle; refactoring and SOLID design principles; good release planning and intelligent use of spikes; and so forth.

Just work directly on that stuff.

Truthfully, I've used sprint commitments and have also gone without them. They are useful in certain context, and dangerous in others. I consider the leadership, the managers and scrum masters, the team's agile experience, and how much time I'll have to coach the team before making the call on sprint commitments.

Related Articles:

Matt Barcomb wrote a nice article on good and bad commitments. Go read that and the very thoughtful comments posted in reply.

I briefly touched on sprint commitments in my post on unstable velocity.

Space Theories

I once created an agile space that my teams could choose to use. They had decent cubes they could also use. (Decent cubes -- an oxymoron?) Anyway, when the space was created it got used lots. Over time, it got used less. Late one night I pondered why and came up these thoughts. I'm posting it just for fun. Consider your space in light of these thoughts.

The Distance Theory

The likelihood of a team voluntarily using an agile space...

• is indirectly proportional to their proximity to each other.

Teammates are unlikely to use the shared space if their cubes are only three steps apart.

• is directly proportional to the sum of the distances between the cubes of the team members.

The more scattered the members are, the more likely they are to meet in a common location. Therefore, the likelihood of a team using the space may be proportional to the team size. This rule holds as long as that aforementioned sum of the distances is greater than the sum of the distances from the cubes to the agile space.

• is directly proportional to their proximity to it relative to their proximity to each other.

No one will use an agile space that is much further away than whichever cube is most central.

The Equipment Theory

The likelihood of an individual voluntarily using an agile space...

• is directly proportional to the computer speed and display size of the team computers relative to that of the computers in their cubes.

Equip the agile space with the most powerful PCs and beautiful monitors, and keep it that way.

The People Theory

The likelihood of a team voluntarily using an agile space...

• is directly proportional to likelihood that the team-lead (or some core, key individual(s)) can usually be found the lab.

Social aspects and the exchange of info/ideas matter.

• is directly proportional to the cohesiveness of their tasks.

Programmers working on disjoint tasks are less likely to use a shared space.

• is indirectly proportional to the number of teams using that space.

I can easily listen in or tune out discussions between my team members. Discussions between members of other teams are not easily tuned out. (Cognitive dissonance.)

The Environment Theory

The likelihood of an individual voluntarily using an agile space...

• is directly proportional to the positiveness of daylight.

Daylight is a positive and negative factor.

• Daylight good.
• Glare bad.
• Looking at distant objects good. Reduces eye strain.
• Heat bad.
• Working shades are good.
• Dysfunctional shades are bad.

Standup Around Innovative BVCs -- The CNN Agile Tour

At the CNN Agile Tour put on last week through Agile Atlanta I noticed a couple Big Visible Charts (BVCs) of a sort I don't think I had ever seen before. One of them is a list of tasks that need to be done pertaining to delegating some responsibility and moving some permissions to other people. Multiple teams have a standup around this board. It looks nothing like a card wall. Other than the fact that it doesn't look like a card wall, what it looks like doesn't matter. So I'm not including a picture. No one should try to do what they did.

The point here is that they were innovative in coming up with a BVC that radiates status and helps them communicate. Too many teams get stuck in a rut, using the same old ineffective ways of doing their standup. And often abandon the practice altogether.

The Tours

It was neat to see the Kanban being used by one of the teams and to talk about how they were using it and what they were getting out of it. It was cool to talk about their facilities and compromises they made and how the layout impacts pairing and team size. And we had good discussions about estimating tasks and stories. And other stuff too.

We've had prior tours as well and in each the host has had surprising candor, discussing the honest state of their agile practice including their current struggles.

Alex Kell wrote a nice post about the earlier Agile Tour @ Allure.

And the RedPrairie Agile Tour was neat because we got to sit in on an end of iteration innovation demo, a kind of a technical show and tell across several teams of some neat new technologies they've experimented with or put into place.

I'm planning other tours as well. Follow me on twitter and subscribe to the Agile Atlanta yahoo group to make sure you don't miss the next one.

Each company that has hosted a tour has gotten something out of these tours as well. Let's set one up at your company. Give me a call or drop me an email today.

Backlog Completion Date a Kanban Hazard

I've attempted to write this article in the inverted pyramid style common in newspaper articles. (Most important info first. Least important last. Quit reading wherever you wish.) Don't know if I succeeded. What do you think? How badly does this stink?

A mistake I've seen is to use lead time metrics, derived from the development of small, well-split stories, to figure out how long it will take to complete a backlog full of raw unsplit stories. Apples and oranges. Don't do that.

Writings about the Kanban Method eschew story estimation as being both waste and inaccurate. Even relative estimation. So instead, they recommend understanding your system well and gathering the metrics on average lead time. With that data you can compute how long it would take to complete a backlog of work. Even some Scrum teams are beginning to use this approach. I like this method.

But to use this approach you must truly understand your system. I'm talking about understanding the behavior of the system and in particular the actors in the system.

For example, it's common to split stories once they get higher in priority and closer to development. That's a good thing and it happens in Scrum and in Kanban. This refinement may happen many times to a story during it's lifetime. I guess that most teams are completely unaware of just how many times stories are split along the way. Often I see stories indirectly split; Setting out to rewrite a set of stories, the set will be thrown away and a new set written, with no one noticing that there are more, and finer grained, stories in the new set.

A similar effect happens in Scrum when teams estimate defects and include those points in their velocity. They most often have no estimate for defects that have yet to be discovered (neither in quantity nor magnitude of effort). If a significant number of new defects are coming in all the time, then such teams are inflating their velocity and underestimating the magnitude of their backlog. This is a recipe for disaster. Such teams wonder why they never hit their dates. Others blame it on a quality problem.

As an aside, any commitments regarding the completion of the backlog have to be in concert with the stability of the backlog. You need to compute a new end date whenever the backlog changes. But that's the same whether you are using lead time or relative estimates with velocity.

Changes to My Personal Kanban

I thought you might be interested in some improvements I made to my personal kanban wall this week. I know these aren't the best pictures, but below you'll see a before and after view.

FLOW
First, I reversed the board to flow right to left. This feels more like pull to me. I'm pulling work from the right rather than pushing work to the right. I think this will feel more like pull whenever the board is directly in front of me, or a little off to the right. If I could position the board out to the left of my desk, moving stickies left to right might feel like pull.

HEADERS
I prettied up the headers. The others were ugly. I was tired of looking at a sloppy wall. I don't mind the transient stuff to be sloppy, but I wanted the headers to be a little more neat. I could have done a decent job if I took my time, but I decided to ask my awesome wife, Laura, to make new headers for me.

As part of that, I cut the header stickies down to about a third of the size of the stickie. This, plus writing them with a sharpie, makes them look more like headers and also not take up so much space. This allowed me to feel free to move the header below the window muntin. When I first put the headers above the muntin I thought the muntin would feel like a heavy underline separating the header row from the other rows in a table. I think the muntin was too big for that to look right. Didn't achieve the desired effect.

Before

After

IMPORTANT/URGENT
I used to have "This Week" and "Today" columns. I really liked the "Today" column. I have been making a fair attempt to plan a day and a good attempt to do today's stuff today. But "Today" didn't always mean today. Sometimes it means "today or tomorrow but don't wait until the end of the week". Really, it meant something more like "Important and/or Urgent, don't let it slide".

Compared to how I planned and executed my days, I have been making a better attempt to plan a week but I didn't stick to the plan as much as I thought I would. For the most part, that's okay. I adapted as priorities shifted and as opportunities presented themselves. But I also let important stuff slide. "This Week" really meant something more like "Important and it might become Urgent if you let it slide".

Not sure how it will turn out, but I've now got Important, Urgent, and Important-and-Urgent columns. I can already see that I have lots of Important stuff. I couldn't really see that before. At least I'm not buried in Urgent stuff.

NOT READY
I also used to have lots of todos stuck over on the window stile. It was clear that I needed more room for my backlog. In addition to the stuff I had planned for Today and This-Week, I had all kinds of other stuff that I thought I should make a stickie for. There was stuff I wanted to do, but I just wasn't ready to do them. There was stuff that wasn't ripe; the timing wasn't right or there was another task to do first. All these things aren't exactly the same as Waiting. For me, Waiting is waiting for someone else. So I created the "Not Ready" column.

I had been putting recurring tasks above the header. That's stuff I wanted to do each week. I may still do that.

MAYBE
The new Maybe column is for stuff that is ready to pull but that isn't quite that Important yet. These tasks are things I can do if the mood strikes me. If I have the energy and focus to do a Maybe task but not the energy and focus to do something Important, then why not pull a Maybe task? This is a concept from Getting Things Done (GTD). There is a lot of overlap between GTD and personal kanban:

Get stuff out of your head and onto a system you can trust to free up your mind and then do the most important next-action that you have both the time and energy to do, taking advantage of opportunity and location.

I have an additional pile of Maybe next-actions in the front of my GTD card file on my desk. Here is a photo of that:

DONE
I've been stacking my Done stickies starting at the BOTTOM of the Done column, each one slightly higher than the one below it. This keeps the sticky part of the stickie on the glass so they don't fall off, but takes up less room on my kanban wall. This obscures the title of the done tasks underneath the top one, but that hasn't bothered me.

I clean off my done column each week, record my velocity (which I haven't really done anything with yet), have a retrospective, recycle the old stickies, plan my next week, and plan my day. I didn't make any changes to that.

DID YOU GET ANY IDEAS?
I hope you got some good ideas from this post for improving your own GTD or Personal Kanban. Would love to hear about any changes you plan to make after having read this. Before you go away, please post your immediate thoughts in the comments.

Use Physical Story Cards

Sometimes you want to use an electronic Agile Application Life Cycle Management (ALM) tool for managing your user stories. There are benefits to using a tool. They have some really nice features, some of which can't be done in the physical realm. And sometimes you've just got to go electronic; you have no choice. But even if you've gone virtual, there are still benefits for having physical cards as well.

I like having my user stories on physical cards. Conversations are richer, and shorter, when you can point and ask "What's the difference between these two stories?" and the answer is "THIS story is about… but THAT story is for…".

Planning poker is great, but the Team Estimation approach is often better, especially if you have a dozen stories or more. I love it when someone can tell the team "I think THIS story is smaller than THAT one and larger than THIS one" and everyone immediately understand which stories he's talking about.

Relative prioritization is easier when you can slide around some physical cards, especially if you need to prioritize collaboratively. "I'm okay with what we've laid out here, but if you think THAT story is THAT high a priority, you are nuts!"

I recommend having a pre-planning meeting to help make iteration planning will go well. That first pre-planning before a team's first iteration planning meeting is particularly difficult. You don't know what your velocity is. You don't know how much you can get done. You may be unsure of dependencies. All this agile stuff is new. And you need to get several people to feel confident that the 1st sprint planning will go well. You have this large backlog of stories and you want to be sure everyone understands what we're sure we're putting in, what we're considering to put in, and what we're not putting in. So lay it out on the table. I love being able to slide cards around on a table and to be able to literally put something aside for now if it's giving us grief. It's not off the table, it's not out of sight, it doesn't look like it's still in the list, but it won't be forgotten. "Let's come back to THIS one later."

Story mapping just has to be physical until we get inexpensive wall-size touch-screen monitors and story mapping software.

I've worked with clients that were very happy with their ALM tool and large monitors. I was impressed with their dedication to making agile work, their open space, and these monitors for each team. But as big as the monitors were, it still just seemed easier to me to manipulate and read fat sharpie on index card. And I can write SPLIT on a card faster than I can tag it as too big in an ALM tool.

Sketches are interesting. A picture is worth a thousand words. Would be harder to do this on anything other than paper.

But using an ALM tool doesn't mean you can't have physical cards too. It's pretty easy to write the story title and estimate on an index card. You can write the story's ID number from the ALM tool on the card. You can also print story cards from some of the tools. VersionOne has always had a printing solution, but the version coming out in August 2012 will have the ability to print directly from the tool.

I've heard of other tools that make it easy to print, but I can't name them off hand. If you'd like to mention your tool in the comments, please do.

Lots could be written about keeping physical cards and an ALM tool in sync. I'm going to ignore keeping a Scrum card wall in sync in order to keep this post on the short-side, but I will add the following. If you are using physical cards for a prioritization or sizing exercise then just enter the updates back into the ALM tool and discard the cards -- or hang on to them for some other purpose if you want. The point is, the cards served their purpose, they are transient, update the tool and you are done. I could also approve of doing a story map at the start of a small release, then leave it on the wall as is as a historical vision document while the ALM tool becomes the plan of record. I also recommend sticking with physical cards through Iteration Zero and Iteration One. What's cool in I0 and I1 is using the same cards for socializing, estimating, prioritization, pre-planning, and finally planning and the daily standup, then seeing a gold star put on that sucker once it's done.

Bottom line: Keep using physical cards. I promise it will be worth it.

Consider Stories at Multiple Levels

I often work with teams adding new large features to existing applications. It is common for teams like this who are new to agile to go into too much detail too soon. It seems that those accustomed to waterfall believe you've only got one shot to discuss any requirement, so they must discuss it in detail.

In agile you get many looks at each user story (requirement), preferably from many different angles and ultimately getting progressively more detailed as you go. I like to explain it with these four levels.

VISUALIZE -- The Concept

We typically start with a project name or enhancement name, don't we? It's the handle by which we call this thing. From there we hope to have the vision, a short narrative for what we're after. Perhaps we have the name of a few super-epics. Refine that into some epics. Begin to understand the minimal marketable features (MMFs). Metaphorically, this may be an aerial view of the forest, or maybe the planet. Keep the vision in front of the team throughout the project.

PRIORITIZE, ORGANIZE and SOCIALIZE -- The Forest

By prioritize and organize, I mean use any approach to help the team see how the stories fit into the vision and understand the minimal marketable feature set. An example technique is Story Mapping. Understand your epics. Metaphorically, this is understanding what the forest full of trees looks like.

None of these are a one shot deal. Iteratively refine your prioritization. Tune the MMF and re-socialize stories as you learn and get feedback. You aren't done socializing just because sprint zero is over. For anything of size, you don't get done socializing in just one meeting. Nor does all the socializing happen in meetings.

SIZE -- The Trees

When sizing (with abstract relative points), look at your stories in a little more depth, but not to the level of detail described below. Look at it just enough to give an estimate relative to the other stories. You don't need as much detail for a relative estimate as you would for an hours/days/weeks estimate. You quickly get to a point of diminishing returns. Consider that we use a Fibonacci series or something similar -- we use a diminishing level of precision as the stories get larger. Once you are pretty confident that it's a 21 point story, you don't need to spend more time to make sure it isn't really a 13 pointer.

As with the above, you may look at a story for sizing multiple times. If you've sized a bunch of stories at the start of a release, you should re-size the remaining work after 3 to 5 iterations. By then you've learned more. You will have become more familiar with the project, subject matter and the affected code.

Sizing also shouldn't be expected to be static. How big a 3 point story is will shift over time, especially but not only because of changes in the team. Hopefully the individuals are getting better, smarter, and the code is getting cleaner. Also, the work that we're comparing stories to changes. Point-drift happens. Old estimates are like milk -- they don't get better with time.

PLAN -- The Details

In iteration planning we break stories down into tasks. We estimate tasks in hours or half-days or maybe in pomodoros. We think in terms of detailed design and code and test cases.


Understanding that we're going to see each story multiple times with progressive levels of detail helps overcome the desire to go too deep too soon.

What approaches have you used to help people think about stories at the appropriate level?

3 arguments against BLOCKED and a bonus on IMPEDIMENT

Why I don’t like "blocked" –

In some companies, people don’t want to say they are blocked.

(1) Being blocked gives you a sense of blaming others. Not wanting to offend coworkers...

Yes, I'm waiting on Joe, but he's not blocking me!

But we want honesty and need safety. I need a safe environment so that Joe and I can agree that Joe's blocking me. It's not Joe's fault. It just is. And it needs to be a safe environment especially if it is Joe's fault.

(2) Being blocked gives you lots of scrutiny.

No! I’m not blocked! Don’t help me!

But that’s exactly what we want – attention on the problem, but in a servant leadership collaborative way. Too often, blockers attract the wrong kind of attention.

(3) Being blocked sounds so absolute.

...and I'm not totally blocked anyway. There's some other stuff I can do.

Yeah, less important stuff. Probably stuff we shouldn't be doing anyway, unless it's taking advantage of slack to sharpen your saw.

(4) Having an impediment sounds like a medical problem.

No, unh-uh, no impediments here.

Impediment is such a funny word. Who introduced that into the agile vernacular anyway? Nobody uses that in normal speech. People new to agile likely don't even know what that means.


That's why I like to ask "what's slowing you down?"

"Oh, yeah, my PC's a few years old. I don't have very good test data. The A/C shuts off at 5:30p each day. I have to make two hops to remote into the test-lab because of security reasons. The build server builds once per day instead of on check-in. The unit tests are taking a few minutes to run; I think someone put something bad in there. We should find it and move the offender over to the regression suite or make it faster. Why can't we get some stickier stickies? I'm waiting for Joe to give me access to the production server. And I keep getting interrupted by customers bypassing the support desk… Sure. Lots of stuff is slowing me down."

Ah. Great. Now that I know, we can go work on that.

Constellations and Deep Democracy

Constellations can be used as effectively with just one or two statements as well as with dozen, making it an effective tool for Deep Democracy.

One of the tools I picked up from Lyssa Adkins' book, Coaching Agile Teams, is called Constellation. (It really should be plural, Lyssa.) Briefly, the purpose of Constellations is to gain a better understanding of your team and their individual preferences, values, interests, or opinions.

Mechanically Constellations works like this: Put something in the middle of a big open room. Have everyone stand in a big circle around this object. Explain that you are going to read some statements. (Such as: "I like Scrum." "I get value out of our retros." "We should TDD more." "I think Agile will work for us." Etc.) Instruct the team to orient themselves closer or further away from this object after each statement is read to represent the extent to which they agree with that statement. If they agree, move in. If not, move out. Tell them to not over think it. Tell them to stand where their heart and head tells them to stand, not where they think they should stand. Then have the team observe the Constellation of people and discuss what it means. There are some considerations for how that discussion is facilitated, but that's a topic for another post.

The way it's described in the book is that the facilitator might want to read numerous statements. This is a great way for a team to get to know each other. I've done this exercise with about a dozen different teams. Now, I'm no longer surprised by what I find. A common surprise to the team is when they discover that their Product Owner doesn't like to run the demo but that someone else one the team has been dying to do it. Another: There's often an ah-ha moment when the team begins to understand that the quiet person just needs time to think before he speaks.

Anyway, I've done this lots and lots and have used 20 to 40 statements each time. Some of the resulting Constellations aren't interesting. I move on quickly and don't have discussion for those. Some are very revealing. I have a short discussion on the spot for those. Even the teams that are well established have interesting revelations using this technique. The number of questions and amount of discussion is bounded only by the team's willingness to continue standing.

Building on Michael Spayd's talk on Deep Democracy at Agile 2009, during the Atlanta Scrum Gathering in 2012, Lyssa Adkins and Michael Spayd led a Constellations exercise and only asked 2 questions.

They used the technique for Deep Democracy (Arnold Mindell). They were working with a large random group of people from the conference; I usually work with a team that has at least a little work history, and often a long history with each other. They facilitated the discussion carefully, more carefully than I would with a known group. Lyssa started with the inner ring and encouraged all voices to be heard, one ring at a time, an important aspect of Deep Democracy. Lyssa was careful to give voice to each ring in the Constellation and to set the ground rules: don't state that someone else's opinion is wrong or challenge someone else, use "I think" or "I feel" or "my opinion is", all opinions are valid, I will step in if you violate these rules, etc.

What I learned directly from Lyssa that I didn't get out of the book is that the Constellations technique can be useful with just one or two questions. In particular, it's useful when you have a specific narrow topic, even a controversial one -- when Deep Democracy is needed. This can provide a safe environment in which to speak and allows the facilitator to manage diverse opinions in a logical progression. It's also useful to reduce the number of questions as the size of the team grows (since it takes more time to allow more people to voice their opinion).

I would love to hear about your experiences with Constellations and Deep Democracy, together or separately. Are there other variations on this theme? Other ways to use this technique?

For the Sake of a Productive Retrospective

Even good, competent, and valued people sometimes have an off day, make an ill-advised or selfish choice, or are just plain mindless.¹

Like many others, I'm not quite satisfied with the Retrospective Prime Directive as it's written. I understand and appreciate Dinwiddie's explanation of it, but as a useful tool, the directive doesn't strike any chords for me. What I think the directive is trying to say is:

Retrospectives are not about blame. They are about moving forward.

So why not just say that? I'm fond of Tobias' take on it (with another phrase² inserted):

We are emotional and vulnerable beings, subject to a continuous flow of influences from a myriad of sources. Sometimes we perform magnificently, other times we mess up. Mostly we are somewhere between these extremes. In this last period of work everyone did what they did, and likely had reasons for doing so.
     Bearing in mind that there are many factors of which I am unaware.²
Accept what is. And now, what can we learn from our past actions and thinking that will inform and guide our future ones?

Whenever I'm working with a team that is still struggling to create a safe environment, I also suggest "quietly considering" this:

I will ensure that we have a safe environment
in which we can each own up to our own mistakes own our own
and endeavor to not be defensive if someone else points out my mistakes.
If someone gets defensive, we'll assume that the environment is not safe
rather than assume a personality flaw.

1. Stone, Patton, Heen, Fisher, Difficult Conversations: How to Discuss What Matters Most, Penguin, 2010, page 287.

2. Wallace C. Ellerbroek, MD, “Language, Thought, & Disease”, The CoEvolution Quarterly, No. 17, Spring 1978, page 33.