May 182017

My mother is going to laugh a lot at the fact that I’m writing this post, even if she’ll never admit it to me.  The idea that her son — who always used to get home late, sometimes knocking over the pots and pans that his father had set up against the door to announce his late arrival — is writing about time is a bit ironic.

But here we go. My good friend and excellent Agile Team Guide David A. Koontz (really, he’s an artist with teams; you should try to hire him) wrote an excellent article about Lead Time vs. Cycle Time, and the difference between how long we take to do a job vs. how long the customer waits for the results.

I’ve been working with Lean Kanban Inc. since last year, and I appreciate the sharp point they’ve put on terms around this issue. Here they are in a picture:

1. Customer Lead Time

The time from when we accept the customer’s request until deliver that request to the customer.

That’s it. Plain and simple. This is all the customer cares about!  The item could be “done” 5 minutes after the order is taken, but if it sits in a warehouse for a month before the customer gets it, the customer is still gonna be peeved.  Or as in David’s example, the item could sit around for a month and only take a few minutes to actually deliver. Either way the result is the same.

2. System Lead Time

The time from when we accept the customer’s request until the request reaches the first unbounded queue in the system.

This is a metric we care about when it comes to measuring and improving systems. Notice the Work In Process (WIP) limits in the picture above.  That last state, “Done” has no WIP limit. It’s potentially infinite. Even though we serviced the customer’s request at the end of Process C, it could sit around in a queue forever.

The reason we measure this only up to the point of the infinite queue is because we can only design and control systems that have WIP limits in them. Sometimes we can’t control what happens in that “Done” queue, so we can only work to improve everything up until that point. (At first. Once we get that under control, it’s time to have some conversations with the people in “Done.”)

This is why it’s important to have WIP limits on all work queues and buffers: if you don’t, then you don’t really have a pull system, and your ability to predict delivery is shot.

The actual LKI term for this metric is “Kanban System Lead Time.”  But if the first unbounded queue in your system is the Request buffer, guess what — you don’t have a kanban system. This, right here, is the most common pain I see when I’m asked to help with Agile delivery: a great Scrum engine with tightly-controlled WIP (from Sprint Planning), and a whole chain of unbounded queues upstream of it.

PRO TIP: your biggest predictability problem in this case is NOT your development process. :)

3. Time In Process (TIP)

The time that a particular request spends in a given process state.

This is what David called “cycle time,” and it’s a pretty common usage of the term. I prefer Time In Process because it’s clearer. “Lead Time” and “Cycle Time” can get confusing, so we just throw one term out. Yep, we don’t actually ever say “Cycle Time.” (Well, I try not to — old habits die hard.)

What about the time from Process A to Process C?  Easy, that’s just “the Time In Process for Process A, B, and C.” In our example above, TIP (Requests+A+B+C) for an item is the same as the System Lead Time for the item.

We use this in systems design to get a more fine-grained view of the system than System Lead Time.  And we use it day-to-day to meet our Service Level Expectations.  Do we expect most requests to spend 7 days TIP in Process B? Is this request here currently 6 days TIP? Then maybe we better get a move on and get it out of here — or think about renegotiating the customer request.

4. Working Time

Time spent on actually increasing the value of the item. Also called Touch Time.

In David’s example, this was also what he called “Cycle Time;” the time spent installing the basketball hoop. Often, the Working Time represents only a small fraction of the total Lead Time for the item. Which brings us to…

5. Waiting Time

Time where the item is not being actively worked on.

This is often a large portion of the total Lead Time (System, or Customer) for an item. This is where high WIP limits (or no WIP limits!) kills us. This is where multitasking kills us.  So much of the customer’s total wait time is just the request sitting around, or being shuttled back and forth from one person to another.  Which brings up…

6. Flow Efficiency

The ratio between total Working Time and total Waiting Time, expressed as a percentage of System Lead Time.

And here’s the second most common pain I see when asked to help with Agile delivery: poor flow efficiency.  In the example above, we take the customer’s order, and then it sits for a bit.  Then we start Process A and finish quickly… but it sits for a bit until it gets to Process B. Same thing happens with Process B. Process C is better; mostly we work on the request, with one brief interruption.

For systems with lousy flow efficiency, changing the system to reduce waiting times is going to be a huge bang for the buck — much more than improving the actual working processes. You’ll get faster delivery, and more focused, happier people who aren’t task-switching all the time.

One Last Distinction

In my recent AgileIndy talk, I made a call for 21st-century management to raise the game: we need to get better at managing systems, and leading people.

We sometimes use the terms above to refer to an individual request. “What’s the Time-in-Development for this FooBar Story? Is that going to affect our SLE?”  That’s valid. That’s the kind of question you’d hope to hear within the team, not from a manager.

If we are managing the systems, we use the terms I’ve outlined here to refer to requests in the aggregate — which really means referring to the system as a whole. “How can we get the System Lead Time down by 30% for all standard requests?” That’s also valid. And that’s the kind of question I really like to hear from management. 

Let the workers self-manage the work. Manage the systems. Lead the people.

Feb 232017
Image source: AOPA Flight Safety

My friend Scott Barnes tagged me about this article on factors affecting pilots’ decisions to land.

Scott’s share of this article reminds me of one more way in which my training as a Commercial Pilot and Flight Instructor influences my business consulting practices.

In aviation, we don’t think of an aborted landing as merely a landing that we “failed.” The aborted landing is actually a maneuver with procedures and performance standards. We train for it like any maneuver.

The Go-Around

Go-Around procedures. Source:

Go-Around Procedure (image:

Sometimes a landing shouldn’t happen. The entire flight path to the runway was fraught, so those final 100 feet to wheels-down are going to be messy. Another aircraft is on the runway you were just cleared to land on. You got distracted and got “behind the airplane” (you aren’t thinking ahead, and have become more of a passenger than a pilot.) The landing was going great, but the wind gusts are worse right now than they were sixty seconds ago… and as you fight the gusts, you are running out of runway.

As a student pilot, I had my share of unpleasant landings, including one which came close to scraping the tail of the aircraft on the runway tarmac.

My instructor — after examining the tail of the aircraft and breathing a sigh of relief to find it unharmed — informed me that any of these is a totally valid reason to skip the landing and go around.  In fact, I should plan every landing as if it were going to be a go-around.

“Get back up safe in the sky, re-plan, and come around and try again. Landings don’t cause crashes; pilots forcing themselves into bad landings cause crashes.”

This was eye-opening advice. How cool: as Pilot-In-Command, I have choices! I’m NOT doomed to follow my plan down into a fiery impact with the ground!

Warning Signs

But how often, in business, do we “force ourselves into bad landings?” The article lists six factors for why pilots do so, and they should ring a bell for us in business.

I’ve taken the liberty of translating the article’s six factors into typical sound-bites that represent the thinking behind these factors:

  1. Plan Continuation Error — “We need to stick to the plan. Why else did we make one?” 
  2. Sunk Cost Effect“We’ve invested a lot of time/money in this course of action, we need to see some return.”
  3. Cognitive Dissonance“The alternative you suggest sounds too complicated. Our current course of action is simplest.”
  4. Complacency“We’ve done dozens of deployments like this, I don’t see why you’re so pessimistic.”
  5. Hindsight Bias“Those warning signs you talk about aren’t warning signs; they are they only thing that could have happened. Stop worrying about what DID happen and focus on what SHOULD happen.”
  6. Bounded Rationality/’Satisficing’“I’m not rationalizing risk away; I just don’t think a few annoyed theoretical customers is as risky as delaying our product release by a month.”

How often have you heard statements like these, prior to the business equivalent of a crash into the ground?

Image source: AOPA Flight Safety

Image source: AOPA

Crashes in business can take longer than in aviation, but both are awful to watch.  I once saw one go on for 4 months. There were dozens of “passengers” (senior employees) involved in this particular venture, but despite all evidence, the “pilot” (C-level leader) continued to make statements that sounded a lot like those above.

Right up until the point that the company’s core business and customers were threatened.

It was the business equivalent of feeling the aircraft tail scrape the runway.

Plan the Go-Around — Detect When to Execute

I’m not trying to paralyze you with crash stories and accident reports. I’m hoping to show you that you have options besides “do or die.”

But only if you plan to have options. If there are warning signs, don’t simply hope that everything will be okay. Don’t shove the responsibility for a successful landing off onto your people. Question. Test your assumptions.

Here are some antidotes to the above risky soundbites:

  1. Plan for AlternativesWhat “go-around” procedures do we have if a risk manifests? Are we ready to execute them?
  2. Think Incremental ROIWe’ve invested a lot of time/money; how do we ensure that we get at least partial ROI no matter what?
  3. Be SkepticalWe’ve done dozens of successful deployments like this. But what’s different about this one?  
  4. View Risks as Discovered Work — I hear some concerns. Sounds like we’ve discovered some new risks. What work do we have to do to minimize these risks? Is this work in the new plan?
  5. Set Triggering ConditionsLooking ahead, under what circumstances might we need to change our plans? How can we tell if those conditions occur?
  6. Be Open to Peer ReviewI don’t think the risk of failure is as great as the risk of delay. But maybe I’m biased. So I’ve asked people outside my department for their assessment.

In aviation, we say:

“Plan every landing as a go-around, plan every [instrument weather] approach as a missed approach.”

Hope is not a strategy. “Go around triggers” for a project at risk from outside commitments.

In business, this means that while yes, we should “think positive” and “plan to ship it,” successfully delivering means that we also detect when that plan is no longer feasible, and then re-plan using newly discovered information.

Agile Development methods bake this re-planning into their process. Unfortunately too often the surrounding business processes do not. Too often, the people leading those processes view re-planning as a sign of failure.

So watch out for those warning sound bites. And stop thinking of deviation from the plan as failure. Start thinking of it as a procedure to be practiced and performed just like delivery.

As we say about go-arounds in aviation:

“Better to explain why you DID it, than for others to find out after the crash why you DIDN’T.”

 Posted by at 12:50 pm
Feb 102012

I love this Google+ post from Dave Gray. He talks about the operation of an aircraft carrier, a complex system with high personnel turnover but no comprehensive operations manual. There is no manual because it would have to be as complex as the carrier itself. Instead, the “manual” for the carrier is the sum of ongoing expertise and learning that is occurring all the time:

When the situation is stable, predictable, and well-understood, traditional hierarchy prevails. But when decisions need to be made quickly, decisions will migrate to the edge, where people can sense and respond to situations in real time.

At the end of the post Dave invites us to use this story as a metaphor for other large complex systems. One such large complex system is the so-called “software development process.” A documented process presupposes a simplistic ecosystem, but the ecosystem of enterprise software development — like the ecosystem of an aircraft carrier — is enormously complex. Beyond one person, a small team, or even a team of teams, enterprise software development is of the same order of complexity as the enterprise itself.

And as such, as Dave says, “there ain’t no manual.”

Sure, we need some abstractions (like UML) to help us quickly get our minds around general concepts. And we need some procedural checklists (like automated code-management tools). But mistaking these for “how to do software development” guides reminds me of Martin Fowler’s warning against mistaking software design docs for the software itself: “the code is the best source of comprehensive information, as the code is the easiest thing to keep in sync with the code.” Martin is reminding us that abstractions of complex systems are useful, but they are not the thing itself. Guidelines are useful, but manuals are useless.

So what do you do when your manual for the system will be as complex as the system itself? You don’t try to foster compliance — you foster learning.

And I have seen that scare the pee out of many people. They don’t want to learn. They don’t ever want to be the “new recruit” who has to learn how to best fit their own talents into that of the organization. They went to school, they have a degree, they have 10 years of experience, they want to prove to their organization that they “follow all the right processes and procedures.”

No wonder something like Scrum — three roles, three artifacts, three meetings, and 1 big rule: “adapt your work to best realize the needs of the product” — can be unsettling.

So, why are we learning to be afraid of learning?

 Posted by at 1:41 pm
Oct 162011

I recently spent a day helping the leadership of an organization make the leap from “can we become Agile?” to “now we’re becoming Agile!”  The problem was one of mindset: getting people to think less about barriers and more about what actions are possible.  My solution involved hands-on experiential learning and structured group debriefing.

I’ve written about it below, but I’m a visual person so I’ve added a lot of captioned pictures if you want the gist, and the how-to “recipe” for doing this mindset-shift yourself is at the end.

Continue reading »

 Posted by at 6:59 pm
Oct 022010

Oh, the farmer and the cowman should be friends.
One man likes to push a plough,
The other likes to chase a cow,
But that’s no reason why they cain’t be friends.

image from’ve noticed a disturbing trend at a few different clients now as far as how UX folk and Agile folk get along.  It put me in mind of a song from Rodgers & Hammerstein’s Oklahoma, barely-recalled from my high-school musical days.  Let me explain by way of example:

Steve is a User Experience (UX) expert on an Agile/Scrum team working on the new website.  He’s excited because he recently returned from an Agile conference and got a lot of great ideas from Jeff Patton’s session about User-Centered Design.  John is the Product Owner (PO) for the site and is juggling multiple voices and requests, but knows that each day without a new site feature delivered is another day that Venture Capital money is burned with no return on investment.  Geri is the ScrumMaster (SM) for the team and she wants everyone to follow the Scrum process because she knows it’s the best way to deliver value incrementally.

Three weeks ago at the meeting with the VC folks, John heard that they would really love to see do single-sign-on integration with Facebook, Twitter, NetFlix, and the websites — with a unified look and feel.  This morning during the sprint planning meeting, developer Brian cautiously raises the issue of design: does Steve have any wireframes or web composites done for Brian to use in his estimation of story size?  Steve replies that he’s still testing the wireframes with their user focus group and wants to make sure the design for the new single-sign-on will work for them before he releases them to the rest of the team.

John explodes. “What? It’s been three weeks! You’re telling me we still don’t have a thing to demo yet?”  Steve looks helplessly at Geri — surely she will understand the need for a good design?  “John has a point,” Geri says.  “All this user testing you keep talking about smells a lot like Big Up-Front Effort to me.  Can’t you get some wires to Brian ASAP, even if its just for a few stories?”  Steve is appalled.  Wires for just a portion of the site, when the VC folks clearly wanted a unified look and feel?  “Well, sure,” he huffs, “I can give you what I’ve got so far, and you can get right to work on it… if you don’t mind the users thinking it’s crap!

Let us let the curtain of imagination close over this scene for now.

I’d like to say a word fer the farmer
He come out west and made a lot of changes —
That’s right! He come out west and built a lot of fences,
And built ’em right across our cattle ranges!

Just like the farmer and the cowman, User Experience folk and Agilistas/ScrumMasters each provide value in ways that can inherently interfere with each other.  The UX person wants a good experience, and so needs to engage in some sort of holistic design.  This doesn’t have to mean Big Up-Front Effort, but it can look that way to the Agilista who has been fighting waterfall for much of her professional life.

They also each work in ways which tend to stir up the fears of the other.  The Agilista wants a continuous flow of bite-sized chunks of value, with frequent opportunities for inspection and adaptation.  This doesn’t have to mean a Frankenstein’s monster of cobbled-together parts, but to the UX person, even the possibility of creating such a monster is, pardon the phrase, horrifying.

I’d like to teach you all a little sayin’
And learn the words by heart the way you should
I don’t say I’m no better than anybody else,
But I’ll be damned if I ain’t jist as good!

So at the #womeninagile booth at Agile 2010, I had the great fortune to start a conversation with @carologic of Ask a User.  Carol is a UX expert and works through a variety of methods to incorporate actual user research and experience into the design of her client’s products.  While as an Agile coach and empiricism fanatic, I’m always espousing the “ready-fire-aim” and “fail fast” schools of adaptive outcome development.  Cage-match waiting to happen, right?

Wrong.  In 20 minutes of conversation at the booth, we were able to express our respective concerns with each others’ practices and how they are misapplied, and brainstorm at least three harmonious solutions integrating the best of Agile/Scrum and UX, in very specific ways.  Not to tease, but over the next few months, Carol and I will share those ideas with you in our respective blogs.  We will explore:

  • why we shouldn’t call the end-of-iteration demonstration of incremental functionality a “demo”
  • where to integrate user research into the Agile iteration cycle
  • the use of Boundary Objects as discussed in Israel Gat’s Agile 2010 talk

and more.  How did we come to this resolution so quickly?  Simple:  we both approached each others’ domains from a perspective of curiosity and interest — rather than from one of defensiveness.

And when this territory is a state
An’ joins the Union jus’ like all the others
The farmer, and cowman and the merchant
Mus’ all behave theirselves and act like brothers!

image from

I believe that diversity does not mean “tolerance of differences.”  Rather, diversity means “our differences make us collectively stronger.”  This isn’t compromise, this is learning from each other’s talents.  As Karl Weick said, “fight as if you are right and listen as if you are wrong.”

Let’s us UX and Agilista people listen to one another.  We’re not truly in competition, we both want the same things.  We just have different ideas of how to go about it.  And it’s in the union of the two that true value will be created.

As Oklahoma‘s Aunt Eller says, “ain’t nobody gonna slug out anything — this here’s a party.

 Posted by at 4:22 pm
Sep 222010

Rebecca Porterfield asks “can Agile work in a culture of single point accountability?”  The question stumped a panel discussion.  Too bad I wasn’t there, I’d have been able to give the usual pricey consultant answer:  “It depends.”

(cue laugh track)

image from The Village Voice,

In all seriousness, it depends on what you mean by “work.”  I personally have very high standards for “working” Agile.  Agile isn’t a way of doing, it’s a way of being.  So do I believe Agile can work in the spirit of its greatest potential, as a means to enable the shift from an deterministic organization to a learning organization (a la Senge), in a culture of single point accountability?

Can a possum stop a car?

Accountability When Agile is a Process

Sure, Agile can work as a process for incrementally creating quality software product when we insist on maintaining single-point accountability, exactly as Rebecca successfully implemented in her project.  You can “wrap” the Delivery Team in Agile and use the Product Owner and ScrumMaster as the “interfaces” for the team.  You can even promote individual accountability in such a scenario:

  • Product Owner (PO) — on the hook for the health of the (software) product
  • Team Coach/ScrumMaster (SM) — on the hook for the health of the Team and their adoption/adaptation of the process
  • Delivery Team — on the hook for demonstrating a working product increment at the end of each iteration

“Hey Derek, not too fast! That last one is team accountability!  So there isn’t individual accountability at the team level!”

Uh, no.  There certainly is.  In the context of the entire Agile Team (e.g. a Scrum Team consisting of a SM, PO, and Folks Who Make the Software Product Exist) the Delivery Team is accountable only so far as they collectively build working product.  Individually, however:

  • Delivery Team Member — on the hook to the rest of their Team for whatever commitments they make each day at standup; for asking for help when needed; and for swarming and providing help as needed.

See ?  If we are talking about a culture of accountability, then accountability depends in what context you view it.  Each person both has individual accountability and also is part of a Team that has team accountability.  In the context of the Delivery Team, Brian the Developer is accountable for the tasks he signs up for and tells his team “by tomorrow I will complete…”  In the context of accountability to the rest of the organization, however, there is no individual accountability at the Team level lest we promote siloed work and blame-shifting and all the other joys of WaterGile.  But in the same context of the rest of the organization, Geri the PO is the single-point of accountability for the “health of the (software) product (that the team delivers every increment).”

But can Geri truly be single-point accountable for the R-O-I of the product?  Because she is also part of the larger team of Product Management, which is team-accountable for making that R-O-I manifest and be something the organization can use.  In the context of the total utility of the software product, one must also consider the teams of marketing, sales, support, training, etc. to extract and deliver full value on the potential of the software product.

So it’s both.  In a single-point accountability culture, the successful Agilist who wishes to use Agile as a process for creating potentially useful software products needs to promote team accountability and individual accountability as appropriate for the context.  Asking which is more important is like asking whether “3” or “blind mice” is more important.

Lowest Common Denominator

Image from and

Now, this will work for churning out product at a reasonable rate, and Fred Winslow Taylor and members of his Fan Club can clap and sing that Agile will work in a culture of single-point responsibility.  Assuming that your organization has little commitment to the change necessary to achieve the hyper-productivity promises of Agile, assuming you don’t mind flat or near-flat velocity gains, flat team morale, and assuming you are okay with the criminal waste of human potential of churning out product with no real Awesomeness in it — please, be my guest.  Don’t look back, some other companies might be gaining on you.

But if this doesn’t seem to align with your organization’s values, if you actually want people to work better together, to develop their full potential as a team, to realize the power of their diversity and make some truly creative and useful things… you may wish to be cautious with single-point accountability and Agile.

Because you’re robbing people of responsibility.

Responsibility — being a source or cause for results — depends on having the opportunity to be the source for those results.  When you make one person (e.g. the PO, or the SM) on the hook for delivery of the product, people who don’t have the ability to deliver that product, you steal that opportunity away from the Delivery Team.  And that’s the greatest paradox of how I so often see Agile being implemented.

Trying to realize these kinds of gains while preserving single-point accountability for delivery will be about as successful as the possum trying to stop the car.

 Posted by at 8:11 pm
Sep 062010

So, I’ll be participating in Scrum Beyond Software in Phoenix later this September.

I have a bubbling head full of ideas to share there, and as a collaboration junkie, I’m making them visible for comment.  Suggestions? Criticisms?  Want to join me in Phoenix and collaborate?  Leave a comment!

Topic 1 — Science: A Framework to Aid Scientific Research Teams

Scrum is, at its heart, a simple empirical framework for learning and discovery.  Often it’s used to “discover” the unbuilt-but-needed features of a software product, and so people confuse it with a product development methodology.  But it’s more than that — Scrum is also useful for process improvement or organizational change.  Scrum is even self-modifying: it can be used to “discover” the best way to shape the framework itself to help make the team using it more effective.

When you generalize Scrum this way, it seems pretty obvious to try to apply it to how teams “do science”:

  • backlogs as analogs of hypotheses
  • swarming as part of research
  • team-synchronization via standups and lo-fi tools rather than long publishing processes
  • scrum of scrums to synchronize multiple teams
  • demos and retrospectives as analogs of findings and conclusions

These are fairly naive mappings; I hope to make richer ones in Phoenix.

Topic 2 — Healthcare: A Framework for Training Medical Teams

I first mentioned this in a Twitter post inspired by discussion at the 2010 Conference of the International Association of Medical Education.

It seems to me that much of the thought in medical education views education as a rather linear, deterministic process, using what Bob Marshall calls “analytical models,” as contrasted to empirical, stochastic or even chaordic models.  Example:  a “learning process” depends on:

  • a set of initial “learning outcomes”
  • guided “deliberate practice” where students work either on medical tasks, or simulated scenarios (as a team, no less!)
  • “reflective learning” where students debrief and self-assess.

To a Scrummer like me, this just screams “backlog, whole-team execution/delivery, retrospection, REPEAT” and also embracing student/team learning as a chaordic rather than deterministic process.  Unfortunately I see some of the literature and discussion in the medical education world take a rather “one-shot” approach to training:  Students come in, execute, and now they are “trained.”

Some topics and questions I’d like to raise in Phoenix:

  • How might we frame learning in the context of Scrum?  By individual lesson (sprint), and as an entire curriculum (release)?
  • Comments from people in the medical training/simulation field? How have you used something similar to Scrum?
  • What are the problems with taking an approach driven by feedback loops rather than a stepwise process?

Topic 3 — Healthcare: Patient-Centered Treatment

Inspired by Compassion as a Golden Rule for Healthcare and Real Participatory Healthcare Starts With Assigning the Patient to Your Team (same author)

I need to give more thought on this — or ideally jam with another collaboration junkie — but the nebulous ideas here are:

  • Linda Rising’s talk at Agile 2009 about how people who solve problems together, despite their backgrounds or knowledge, feel more empathy and understanding for each other
  • How this effect brings diverse skillsets on an expert team together, despite egos and fears, and makes the team more effective at problem-solving
  • Mapping the patient, and patient’s family into the role of “user”; mapping the medical staff into the role of “team”, and then:
  • Using the Scrum framework as a structure in which to allow these roles to interact.
  • How this is very different from the standard model of “lead physician interacts with patient/family, and specialists mostly  interact with lead physician”
  • Who should be the ScrumMaster and Product Owner?
 Posted by at 5:57 pm
Mar 102010

I have many ideas for blog posts as a result of attending and presenting at ScrumGathering 2010. But I’m going to take a first iteration here, lest I never get around to all my big ideas. How Agile, right?

I didn’t want to just post my fond memories — if you didn’t go to the beach, do you want to look at someone else’s vacation photos?  What I want to do here is  to dump my experiences into your brain. I recognize that you aren’t me, so if you had been there you would have had a different experience than I did.

But if you were me (or are someone who shares certain similarities with me) and you simply didn’t get to attend, here’s a brain dump for you (the session or person I learned each item from are listed at the bottom):


  1. B = f(P,E) Behavior is a function of the Person and their Environment; you can change behavior by changing their environment – CSelf
  2. We often mis-label things as self-organization. An example is self-assembly, such as how people board an elevator. True self-organization has a nontrivial definition, and is worth learning and remembering. – CSelf
  3. The “best friend, worst enemy” game, and how working to protect yourself results in team fragmentation (posted previously) – CSelf
  4. People are self-organizing systems. Naturally. As a species, we have over 13 billion years of experience with this, and only recently have we tried to manage people as things. — HOwen
  5. The “inventor” of OpenSpace Technology synthesized the genesis of OpenSpace after having a martini. He leaped into brilliance and realized that it would only work if there were minimal rules after his second martini. We underestimate the negative impact our everyday rational minds have on our ability to innovate — HOwen
  6. Many of the major catastrophes we’ve created come as result of trying to organize self-organizing systems — HOwen


  1. People’s emotional response to a situation depends on how much it challenges them, and also how much ability they have to handle it. You can change their response by changing either of these. – CSelf
  2. Three words you need to remember to help grow self-organizing teams: “LEAVE THEM ALONE” – CSelf
  3. Powerful questions are those which invite a transformative experience in the person being asked. They tend to be context-free, and totally open-ended — CCoach
  4. There are still plenty of “leaders” who blatantly destroy the elements critical to good teams (by moving members around between teams, for example) and yet are okay with paying to send someone to ScrumGathering. — Recep
  5. Team performance, production velocity, process effectiveness, and personal feelings can all spiral upward or downward. This fits in with my model of positive and negative feedback loops, and has been proven in empirical studies. Yet many people reject the concepts as “fluffy.” — Positive

Coaching and Training :

  1. A great way to ask for silence in a class is to have an agreement where, when you hold up your hand, everyone else goes silent and holds theirs up too. The class self-assembles into silence because they receive the visible signal from everyone else. — CCoach
  2. Being an independent coach/consultant can be isolating, but there are ways to keep in touch with the community. I hope to join in with growing this community — Recep, GK
  3. “Super Pecha Kucha” (a slide every 5 seconds) seems to be the up-and-coming presentation trick. Jurgen Appelo’s audience exploded when he finished his presentation like this. — DoltGuide
  4. Scrum people can be nakedly honest, and yet completely kind about it. I watched an interaction between Joseph Pelrine and Jurgen Appelo that was so gratifying it caused me to laugh in delight. — DoltGuide
  5. Pecha Kucha is completely doable with two people. — OurTalk
  6. Given enough practice, explicit signals between co-presenters are unneccessary. Don’t plan, iterate, even in your interactions. This takes the the meta-level conversations (e.g. “your turn”) and “bakes them in” to the presentation itself. — OurTalk
  7. If you are doing a dense PechaKucha talk, consider either paring it down still more, or warning people how dense it will be. — OurTalk
  8. Be prepared to see your own images turn up in other peoples’ presentations. Work hard to ensure that someone else’s don’t turn up in yours. Give credit where credit is due. Fix the problem when it is discovered (Jean, your image is now attributed correctly :) — convo, JT

Relating to People:

  1. Social media can be used bi-directionally, to truly connect people. Social media can be used unidirectionally for selfish reasons. I prefer the former. – Convo, SB
  2. As @ccarfi says, people can engage in “hunting” (one-off transactions) or “gardening” (long-term relationships). Watching Twitter posts clearly showed who was doing what at #sgus — Twitter
  3. Coaches and trainers can be one-sided in their conversation; talking but not really listening. Does this come as a result of being the “center of attention” in class all the time? Or are people like this attracted to training? Either way, I resolve to pay real attention and listen more. — convo, SB
  4. ScrumGathering this year seemed so much more focused on people, collaboration, and teams; less focused on process and mechanics. This was in large part due to my choices of interaction, but also on the overall content. I am grateful to the conference organizers. — convo, SB
  5. Conference energy can be addictive. Receiving attention, engaging in interactions, discovering new things. Leaving is actually like a physical and emotional crash. It reminds me of closing night with a theatre troupe. I was not the only person to have this reaction. — Twitter
  6. Being positive is not an attitude, it is a practice. — Positive


  1. I was recognized publicly for my assistance to Luke Hohmann in helping the ScrumAlliance set new direction for 2010. Gratitude, humility, joy. — Convo, LH
  2. The “Castillo Fort” room at the Gaylord Palms is a gorgeous place considering it’s entirely man-made. Like an open-air cave. — Recep
  3. You can get a cool thing that fits around the iPhone to turn it into a near-professional camcorder — Recep, GK
  4. The Twitter fountain was extremely cool. Google it. It was a large screen showing a constant feed of attendee posts over an ever-changing background of pictures posted — Twitter


The Sessions and Conversations:

  • CSelfOrg — Joseph Pelrine, Coaching Self-Organizing Teams
  • CCoach — Lyssa Adkins, Coaching the Coaches
  • Recep — reception
  • DoltGuide — Jurgen Appelo, “The Dolt’s Guide to Self-Organization”
  • OurTalk — myself and Scott Barnes, “What Is Scrum? Changing How You Think About What You Do”
  • HOwen — lunch keynote, “All Systems Are Self-Organizing” with Harrison Owen, known as the inventor of Open Space Technology
  • Positive — Lyssa Adkins, “Positive Psychology and Team Performance”
  • Twitter — staying involved “remotely” via the #SGUS Twitter stream, after I had left the conference
  • Convo — misc conversation. If initials are given, the conversation involved:
    • SB – Scott Barnes, @cryofx
    • LA – Lyssa Adkins, @lyssaadkins
    • GK – Gerry Kirk, @gerrykirk
    • JT – Jean Tabeka, @jeantabeka
    • LH – Luke Hohmann of InnovationGames
 Posted by at 9:59 pm
Mar 082010

Edit: This should properly be titled “Dispersion and Implosion in Teams.” See Tobias’ comment.

Exercise at ScrumGathering 2010: how simple internal models (“rules”) can have very different effects on team behavior.

In the first situation, each person has to use their “best friend” to protect themselves from their own “worst enemy.” (In this case, you “protect” yourself by moving so that your “friend” is between you and your “enemy.”)

Notice how the group fragments and disperses.

In the second situation, there’s one little change: each person has to protect their “friend” from their “enemy.”

Bit of a difference! The overall behavior is toward cohesion.

P.S. “Kids, don’t try this at home!” This exercise works because the participants agree to the rules. It does NOT imply that you can simply give people rules to follow and expect to get the desired behavior. Why not? Because people aren’t machines, that’s why not! :) The art of the team is, of course, in coaching and coaxing the teams such that the individuals experience a shift in their own “internal rules.”

Best Friend Worst Enemy

 Posted by at 1:30 pm
Apr 062009

Abby over at Haxr Chick cites Ken (Schwaber, co-inventor of Scrum) as comparing Scrum to a live-in mother-in-law who is constantly pointing out how you can improve.  Great post, and I like it.

But the discussion in the comments is just one variant of the many similar conversations I’ve heard about Scrum.  It goes something like this:

  • Neo: “Scrum is great, but we have to adapt it to fit our organization.”
  • Morpheus: “You must not adapt the Scrum framework.”
  • Neo: “Whoa.  Now you’re getting all religious on me.”

The whole point of “getting religious” about the Scrum framework is to detect when you are, ah, let me find the right extension to the metaphor here, drugging the mother-in-law rather than dealing with what she exposes.

If we can prematurely adapt Scrum to our situation, we have the freedom to adapt it such that we are comfortable within our dysfunction, rather than improving our dysfunction.*

Ken harps on 2 things to keep us from this pitfall:

  1. keep Scrum simple – 3 roles, 3 artifacts, 3 meetings, associated rules for each; and
  2. don’t adapt the Scrum framework (although adapting the process which you evolve around the framework is not only allowed, it is a must!)

By keeping Scrum simple, we reduce the temptation to tinker with it, and we reduce the amount we have to “interpret” it.  By keeping the framework constant, it gives us the same benefit as keeping rulers constant:  we get to adapt our behavior to improve rather than adapting the thing which exposes our behavior.  It would be some odd clothing made by a tailor who adjusted his measuring tape just to make me feel better about my 44″ waist.

But excuse me, I must be getting religious. :)

 Posted by at 1:29 pm