ODE - Outcome Driven Enterprise - The Mindmap

Early and often also provides options

Today I got a gift.  One of my clients is on the verge of delivering  to production their first release of a new [internal] product  It is only an increment, and while it has some value to a set of users, it is only a step along the way to bigger things.

It's taken them 5 1/2 months, with a team of almost 25, working half-time.

"Sorry?" asks the Blog Reader, "did you call this a gift?"

Well, yes.  Local folklore says this team has worked on this domain for almost three years without a release at all, and in light of that, this is blazing speed. But the gift is something else.  This little release has provided an option to address an emergent business need that is suddenly a top priority to the company.

Well shazzam!

My client is struggling to refresh its developers' skill sets, as well as improve the rate of deliver and satisfaction of the business. Very recently the Powers that Be pushed to the top of the priority list the need to support a new [external, for sale] product to their marketplace.  As you'd expect, time is of the essence; it needs to be in production in six months.

The Product Owner and her Customer Team coined new user stories to tag the needs.  The Team was given the stories with dialog and time to ruminate.  The proposed solution, signed off by everyone, even the Old Technology Bigots, uses this Little Release That Could as a key ingredient.  In fact, without this Release, the only options would have been Old Technology only. And while I acknowledge that that would not have been Evil and could still be considered agile, this option is much more compelling and compliant with my client's goals.

Thank you Santa!  As their agile coach I could not have asked for a better example of how delivering early and often is really good!

Agile coach, are you a meterorologist?

I'm learning the power of meteorology in my endeavors as an agile coach. As I influence the people in the organization I find that pressures are important.  Not pressures on individuals necessarily, but pressure zones in the organization itself.  


For example: I needed to find someone to fill  the Product Owner role for a business unit that wanted to start using Scrum. One of my ScrumMasters-in-training was worrying about finding the right person.  The conversation went something like this:


"What if we choose the wrong person?" he asked.
"Well, perhaps WE don't choose at all.  Perhaps we can get a volunteer.  It IS a hard role after all, and volunteers are better than conscripts."
"Ok, how do we do that?"
"Well, we are already creating a vacuum by spinning up Scrum Teams.  Let's produce a source to fill that vacuum, a pressure dome if you will."
He has a blank look.  "Uhm,  say what?"
I smile.  "Think of a weather map.  We have a low pressure system, spinning in place.  Let's build a high pressure system and move it close."
"Er, oookay.  I don't quite follow, but say we do; what will that accomplish?"
"We'll at least get some cool thunder and lightning."


We built a high pressure system by doing a series of Brown Bags on Scrum and the importance of the Product Owner role.  Some folks expressed interest in the P.O. role, and voilá! We had a supply to fill our vacuum.
So embrace your inner meteorologist, ye agile coaches and mentors.

In the center of every real business problems stands a human

It occurs to me that often even we, the [in our own eyes] Enlightened forget that at the center of every real business problem stands a human.

We often find ourselves in target rich environments. We witness the waste, chaos, and misery around us and, because we wish to Deny Pain, we apply ourselves and/or our advice to targets that are second order effects, or worse, mere consequences.

One of the principles given us is, "Build projects around motivated individuals." Permit me to show my bias by stating the corollary, "Form Teams around motivated individuals." And who is more motivated than that human standing in the middle of that real business problem?

As men and women that focus on improving, we ache to have sponsorship for our ideas and notions. We yearn to have access to people that have the organizational power to turn those notions into action. I submit to you that one need look no farther than the humans mentioned herein.

It isn't necessarily the IT managers. It isn't always the CIO/CTO/CWhateverO. It is the line of business manger. It is the Operations Team Lead. It is the Mail Room clerk.

Cooking with Software

No, I'm not referring to software for cooking. I'm referring to an idea for a new metaphor to replace the production line / building analogies: the commercial kitchen.


Kevin is the sous chef at a local restaurant. He calls the staff meeting to order. Before Kevin can begin the business, the restaurant owner comes in and starts to speak, agitatedly.

"I want to change how we work. Starting tomorrow, I want all of the waiters to report to work at 6am. Then, they will contact all of the customers that are coming to our restaurant and get their orders. We'll write all of those up, and then get them to confirm them with a credit card. Then, the kitchen staff will cook all of the meals for the day. When the customers arrive, the waiters will seat them and bring them their meals! Think of how efficient that will make us! Think of how pleased the customers will be when they get their food so quickly! And we'll charge their credit cards sooner and get more money!"

Kevin stares at the owner, and two mini-Kevins pop up, one on each shoulder.

"Kevin! He's insane! How will you predict who's coming? How will you keep the food warm? What if they change their minds? What if..."

The other mini-Kevin interrupts. "Bah! Keep your mouth shut, Kevin, this is your chance to move up... hee hee..."


Kevin's eyes cut left and right quickly, struggling on what to do?

"Uhm, boss, may I say something?" asks Kevin.

"Eh? Yea, sure."

"Well, we're pretty efficient already. We prepare in advance only what we need, and only those ingredients that take a lot of time to prepare, like our sauces. We cut and prepare our bulk so that we can react quickly, but we keep it to a minimum to preserve our workspace and freshness. And, well, our customers get drinks, appetizers, bread, etc., all within a few minutes of being seated.

We don't start cooking their meal until they decide what they want and place an order..."


I submit the modern, well-run commercial kitchen is Lean. Furthermore, it is a better analogy for building software in these, the Aughts.

To document or not to document, that is the question.

What is worthy of committing to storage? Information? Speculation? Knowledge?

I believe that there's a continuum at play here, along the lines of :

{speculation->information->knowledge->...}, where speculation is raw, unverifiable postulates, information is speculation transformed by direct oberservation and/or experience, and knowledge is information so well understood that it has become the currency of wisdom.

So, what's the good agile minded person to do?

Documenting speculation is the basis for heavy-handed methods and is mostly waste.

Documenting knowledge seems a futile activity that seeks to transfer understanding from one mind the the next.

So, is information the answer, dear Occam?

Oh, and for a facinating read from which some of my opinion is based, see Josip Pajk’s article, here.

Beware of hiding requirements as tests

User stories are beautiful things. Details concerning the user story, when expressed as tests, are precious gems adorning the beautiful thing.

But one must take care to not let the tests be a requirement in their own right. Those tests should circumscribe, limit, and clarify the story, just the story, and nothing but the story. If they do more than that then one runs the risk of hidden requirements, and that is evil. Remember, the Principle of Least Astonishment applies to all parties involved in the endeavor.

Edit:  It's 10/13/2011 now.  I've changed my mind.  Tests ARE requirements.  Requirements ARE tests.  They are the same thing.  If a test, especially the Acceptance Criteria alluded to above, describe requirements that would otherwise be missed, Rejoice!

The question is not one of hiding requirements, it is of size.  I've learned that Epic Stories are beautiful ways to manage large amounts of information.  Often the A/C for an epic are stories in their own right.  That isn't something to avoid, it is something to embrace.