Author: kyle

“Who would win in a fight betwen a Moose and a Bison?” says my then-six year old son after our visit to Yellowstone.

Being as this is the 768th question of that type that he’s asked in the last 5 minutes, I’ve had some practice answering.

“Which one is bigger?” I ask.

“The Moose.”

“Yes the moose is definitely taller.   Which one weighs more?”

“The Bison”

“Okay…well then the Bison probably wins the fight.  In animals, the heavier animal almost always wins a 1-on-1 fight.”

30 seconds later:  “Who would win in a fight between a Fox and a Bobcat?”

Rather than subjecting you further to 392 more conversations about animals, I’d like to talk about organizational survival strategies.   Interestingly, they seem to largely match up with animal kingdom survival strategies.

Essentially, animal survival strategies come down to one of the following:

Be big/tough enough that you’re hard to kill.
Be quick enough that the big killer can’t catch you.
Swarm, so that even if some of you die, you still succeed.
Have special skills (poison, shell, etc.)

Making a small nimble rabbit work with a turtle shell just isn’t going to work.

So what about organizations?

Some organizations are like hippos.  They’re just big.  Because they’re big, and strong, and tough…nothing much messes with them.

Other organizations are like rabbits.  They dance and dodge, bob and weave, and move quickly to handle issues.  But they have to, because they’re small.

Other organizations try lots and lots of things.  Most of them fail, and occasionally something works, often very well.

And still other organizations become unreasonably good at one or two things, and focus only on that.

What folks seem to have a big problem with is:   they want organizations to do things that the organization itself isn’t designed to do.   They want rabbit-like fast organizations to be highly resilient.    They want large, hippo-organizations to bob, weave and dance….and implement Agile type speeds.

Have we considered whether if you’ve got a hippo, asking it to dance (on land) is a rather absurd proposition.   If you get the hippo in a tutu, we should probably call that a win, and go home.

To Solve a problem, first figure out what problem you’re solving.

If you have a problem that centers around how to get something done fast and efficiently…note that speed is the essence of your problem.  Probably, speed trumps correctness, repeatability, and documentation.  So…do it fast.   The problem you’re solving demands you do it fast.

If you have a problem that centers around solving the same problem repeatedly, then recognize that repetition is the essence of yoru problem.  Don’t build a solution designed to be fast.  Build a solution where repeatability is the essence.

One of the major problems in modern software process is that no one is willing to admit what the central problem is that their process is designed to solve.   Hero is designed to solve small problems.  Commander is designed to solve problems of how to coordinate lots of people.   Agile is designed to solve problems around change.

What’s your problem?   If you can figure that out…you might be able to decide how to solve it.

With additional attention comes additional clarity.

Complexity is the core question, as discussed recently.  But what are the choices?   Turns out there are three basic answers.  One I already discussed, but the other two are better understood in a different way.

How complex is your system?

Is it a simple system?  Handle things with simple answers.  Individual experts, working largely independently, with bucket lists and goal targeting.

Is it a stable system?  Handle things with stability reinforcing answers.  Plan your projects. Manage to the plan.  Work by schedule.  Define processes and tasks.

But what if it’s a changing system?   Then handle things with answers that leverage change. You can’t manage the group, you need to rely on natural social systems (tribes).   You can’t guide with plans, you must use feedback.  You can’t schedule, you have to prioritize.   You can’t define processes and tasks, you have to build ceremonies.

Simple, Stable, or Changing?  That’s your question.  Use the right system for the right problem.

We’ve run through a couple models of analysis on the nature of Agile/fluid systems.  Specifically, we’ve looked at that Method Grid, and then recently, we were trying to address which question needed asked.  I think we’ve made a breakthrough in our analysis.

Question:  Why is it that Hero and Director are more natural states than Messiah and Wedding Planner?

It seems as if there’s some natural synchronicity between Independent work and Individual responsibility, and also a natural synchronicity between planning and management.

Perhaps calling them out as separate axes is not the right thing to do…maybe there’s a deeper, underlying question, which is being answered in the same way on different axes that leads to this synchronicity.  And once we looked, we did indeed find that to be true.

The new claim:   There is one question at the heart of Agile.  The Agile manifesto gropes blindly for the question, but seems clearly to be looking for it.  The fluid principles are each a manifestation of the Agile question, in a different domain.  What is the question?

Q:  How do you handle complexity?

And at that same deep level, there are three basic paradigmatic responses.

Paradigm 1:  Simplicity.
A:  We don’t.  Our problem isn’t that complex.
Why do startups run in a profoundly different fashion than large companies?  Because their problems aren’t big enough yet.  They’re applying simple solutions (frequently from a brilliant insight) to simple problems.  In applying simple solutions to simple problems, they don’t address complexity at all.  And that’s wonderful.  For the domains that it works in.

Paradigm 2:  Control.  (aka Mechanical, Resisting, Rigid, Structured, Design, Managed)
A:  In the face of complexity, we attempt to control it.
Once problems become difficult enough, the Simplicity paradigm is insufficient to handle the problem.  We design a complexity management system.  More than a couple dozen people in an organization, and the group dynamics need management.  More than a couple dozen modules in your code, and you need to start doing design.  More than a couple dozen weeks in your project, and you need to lay out a plan.  More than a couple priorities, and you need a schedule.  More than a couple risks, and you need a process.   Everyone knows this system, as every large business we’ve seen has followed this mode.

Paradigm 3:  Fluid (aka Biological, Accepting, Organic, Nudge)
A:  In the face of complexity, we travel with it.
At some point after problems become difficult enough that the Simplicity paradigm is insufficient to handle the problem, so too is the Control paradigm unable to handle the complexity of the system.  Nature is complex enough we cannot direct it.  Rather, we need to work with nature, rather than against it.  In the southwest USA, build from brick and adobe to handle the heat.  In California, build flexible, wooden structures to handle the earthquakes.  In Galveston, build on stilts, to handle the Surges.  Nature will not be commanded…but in flowing with nature, we can get some of what we want.

In the face of hundreds of people in an organization, we need to abolish the formal organizational structure that fights nature, and instead allow natural social systems to emerge.  Tribes sit at the 150-person level.  Hunting parties are near 10.  Pairs work together naturally as well.  Natural social systems don’t sit well with authority.

In the face of thousands of components in a system, and fluid requirements, we need to abandon the notion that a design will capture what we need.  Rather, we need test-driven design and an aggressively maintainable system in order to build good enough architectures to survive the natural change cycle.

In the face of hundreds of competing priorities, we need to abolish the formal method of scheduling, and focus instead.  Biological systems like human beings and human organizations have limited bandwidth.  Scheduling 6 things at once doesn’t get 6 things done faster.  Rather, it usually means that at least 5 things get done slower than they would have,  and usually aggressive prioritization/queuing/focus gets 9 things done faster than 6 things in a scheduled fashion.

In the face of innumerable risks, process cannot save us.  We need a better answer.  A natural, flowing with human patterns instead of against them answer.  The answer that gets us there is ceremony.

In the face of more than a couple encounters with changing reality, planning systems crumble under the weight of replanning.  Instead, we need fluid, biological responses to changing conditions.  We need the ur-mechanism for responding to reality.  Feedback systems are the only answer.

There is only one question:

How complex is your problem?

If you have easy problems, a simple paradigm can solve them.
For mildly difficult problems, the control paradigm is standard because it handles them.
But for the actually hard problems, fluid systems are the only answer.

It’s interesting also to consider how many problems fall into the moderately difficult category…and how much overlap there is between the problem-solving capacity of control vs. fluid systems?  How many problems can control solve (well) that fluid can’t?

As our understanding of Fluid approaches improves, we’ve come to see more and more that it isn’t just the answers to traditional questions that are wrong, but rather it’s almost always the wrong question being asked as well.  And when you ask the wrong question, the right answer is nearly impossible.  It’s as if we’re discussing wealth with a mathophobe and they ask us the question, “If I want to get rich, what should I do with my life savings?  Should I go to Vegas, should I play the lottery, or should I invest in high volatility derivatives?”

The answer is no.  Wrong question.  You get rich by investing other people’s money.  And  you don’t do it in the lottery, vegas, or bankruptcy-immune derivatives.  Now…I’m not exactly rich, so I don’t have enough to say here…but I can tell you with confidence that with the question being so wrong…the answer can’t be right.

And so it goes with decisions in the business world.  Almost every question you’re asked will be the wrong question.  Which of course makes the answers insane.

What questions do we need to fix?

How can we get the right answer to our questions?  Should we rely on experts, or should we rely on careful planning?

No.  Wrong question.  The right question is:

How do we find out where we’re wrong faster?

Feedback systems.

————-

How do we assign responsibility to  individuals to get work done?  Responsibility to the individual, or responsibility to the manager?

No.  Wrong question.  The right question is:

How do we assign responsibilty to groups?   

You build a tribe.

————

How do we determine what is important?  Should we work in an interrupt driven (scheduled) system, or should we build bucket lists?

No.  Wrong question.  The right question is:

How do we determine what to do first/next?

Work from a queue.

——————

What existing business feature should we trust to bring us good results?  Should we trust the individuals and relationships?  Or should we trust our metrics?

No.  Wrong question.  The right question is:

What system should we build that we can trust?

Ceremony.

———————

The old questions are the wrong questions.  The old answers are nuts.

The new questions, with answers:

How do we handle error?  Feedback

What gets responsibility?  Tribe.

What do we work on?  Queues.

What can we trust?  Ceremony.

Finally, some good questions.

The theory of using Ritalin in schools goes like this:

1. Grades measure learning.
2. Sitting still and listening is an important part of learning
3. ADHD prevents kids from sitting still and listening.
4. Ritalin allows ADHD kids to sit still and listen.

Therefore:

• Ritalin will help ADHD kids get good grades.

The problem is that the conclusion is false.  Recently, scientists figured out that Ritalin is not actually effective at improving grades.

Why is this? Ritalin supports the standard schooling model very well. If students can’t sit still and listen, what should we do? Ritalin is a very simple answer: Give them a drug that allows them to sit still and listen.

What can explain then, the failure of Ritalin to improve the grades of the students? There are several explanations available, but few of them look especially good for the standard learning model, and none of them look good for the use of Ritalin.

If we have a syllogism with 4 premises and a conclusion, and the conclusion turns out to be false, then so too must one of the premises be false.

For the purposes of this discussion, I think that we don’t need to worry much about premise one’s truth.  It is also pretty well established that ADHD prevents kids from sitting still and listening, and that Ritalin allows ADHD kids to sit still and listen.  That leaves only one premise to address*, which is almost certainly wrong:

2.  Sitting still and listening is an important part of learning

But, someone might object, this is a foundation of our entire school system, and most of our training in the corporate world.  Indeed it is.  And that’s a pretty big problem.

Let us suggest instead a different model of learning.

There are three domains which we interact with in our learning process:

• The Territory — The real world
• The Map — Our mental representation of the real world — usually not in words
• The Words — What we use to communicate about the world.

Or, because I’m suggesting that the listening/reading thing isn’t good enough, let’s get a picture:

The original tree is the territory.**  What someone sees looking at the world.  That is translated via some process into some sort of mental map of a tree for the original observer.  Then, the original observer communicates something about what he’s understood to a listener “Tree”.  Then, if all the stars are aligned, the listener builds his or her own mental map of what was communicated.

The problem is that this system is designed to communicate mostly old stuff.  It kinda sucks for communicating novelty.  And the learning process is about the communication of information and methods that are new to the listener.  Somewhere between the business of translating from the map into words and the business of translating from words back into a map, there is usually a failure.

While this in itself would be sufficient to explain the failure of Ritalin, we can take it further.

An awful lot of the time, this is not a picture of what’s happened.  It’s more like this:

There’s usually an intermediary between the discoverer and the listener.  Oftentimes the intermediary doesn’t even do the real translation from map to words.  Rather, they encode the words.   And that’s where we get real problems.

Human beings have the capability to encode words.  They also have the ability to build maps.  But basically people can’t build good maps from words.  And you can’t do anything with your words except repeat them until you have a map.  Unfortunately, 20 years in teaching, and nearly that many more in school says that the business of going from words to map is effectively non-existent.

Ticking upwards to close:   What can we do about it?  As educators, we can focus heavily on what a student can do rather than what words they can say.  As Agilists, we can keep our meetings small and participatory.  Anyone not talking is out if it’s more than 10 minutes.  And as learners, we can focus on our ability to really understand by doing, rather than keeping a set of words in our heads.

* It could also be true that Ritalin prevents learning another fashion, independent of sitting still and listening.

** Yes, the whole diagram constitutes something sitting somewhere between words and map.  It’s clearly not words, but it’s an attempt to communicate my map to you.

Hero is one of several methods we have of solving problems.  And, as you can tell, gentle reader, it’s not a particularly Agile method of solving problems.  Indeed, the term was originally coined in order to be used as a foil to carefully differentiate between a few standard problem-solving methods.

However, in our exploration, we discovered a few more methods, and discovered that you could categorize them neatly.  Let’s begin with hero.  When we explored the characteristics of a heroic approach, we identified two factors as being the primary signifiers.

First, hero is about independent actors, each doing what they do well.  Perhaps they’re in a group, and perhaps not, but they remain independent.  Dirty Harry and John McClane (Die Hard) are iconic individual movie heroes.  The more recent Avengers movie show us a group heroic effort.  Each hero does his or her own thing, brilliantly, and independently (except for a few touching scenes in which they help one another for a few seconds).  But the independence is central to the heroics.  Each participant helps, but they each work solo.

Second, we might call out that the heroic approach relies on expert intuition to solve problems.  Each participant is required to be expert in order to solve the problem.  And it is by virtue of their expertise that the problem gets solved.  In the case of the two cop-hero movies, it is their grit, determination, individual excellence, and their long careers as cops that make them succeed.  In the Avengers movie, it’s their individual superpowers (a very impressive form of expertise).

If we were drawing a diagram, we might see hero sitting at the intersection of independent and intuition:

With hero as the first method, the second method we named is now generally referred to as Director.  Director is modeled after the approach of any legendary movie director.  Steven Speilburg is among the best of the modern examples.  How does Spielburg develop a movie?  He does it very differently than a hero would, both on the grouping axis and on the optimizing axis.

On the optimizing axis, Spielburg makes a plan.  Not only does he make a plan, he takes years to make a plan.  Get a thousand scripts.  Read them all.  Throw them all away, except the best two.  Rewrite/improve those scripts 30 times each.  Pick the better of the two.  Rewrite it another 30 times.  Nail down every shot location, every line, and every look in the movie.  And then?  Hire some actors to make it work.  Spielburg is a planner.  A darn good planner, but his fundamental method for excellence is nonetheless to plan exceptionally well.

On the grouping axis, Speilburg manages his group.   Not only does he have a plan, and share his plan with the team, but when the team doesn’t follow his plan to the tee, he cajoles sometimes, yells sometimes, fires someone even sometimes, and then gets back to the business of managing the details of all 7000 participants in the movie-making process.

A director, to be successful, plans and manages his team.  A heroic group operates with intuition and independence.  These are hugely different.  Putting these two into the grid, we now have this:

Once we see this relationship, it becomes pretty easy to fill in the other two quadrants.  Intuitive-Managed is Supernanny or Gordon Ramsay or any other Managing Expert approach, including essentially all management consulting.

Planned independent is a lone caterer, prepping a meal for 500.  Alternately, an individual carefully planning his or her stops on a cross-country driving vacation.

Our graph has grown

This exhausts most normal methods for solving problems.  However, we assert there are more, and that they fit nicely into our grid.

Let’s take another method, and see if we can place it.

The notion of a high-performing team (HPT) has been discussed in management literature for the last 60 years.  What are the characteristics?  The three primaries are group-decision-making, and highly competent individuals who flow into one another’s roles as needed.  Rather clearly, they optimize their decisions based on intuition and expertise, but they organize in a completely different fashion from the independent and managed groups.    The simplest way to describe their method of organization is tribal.  The team forms a common bond with a common purpose, and in a very egalitarian fashion (while recognizing individual expertise) moves towards a solution as a tribe.

This expands the grid to look like this:

But wait, there’s more (It’s not sold in any store).   We know of another method for solving problems besides intuition and planning.  What does a scientist do?  A scientist proposes a hypothesis, and then runs an experiment to determine if (s)he is right or not.  Rather than planning a correct result, or relying on years of expertise and the hard-won intuition, a scientist gets to the truth via feedback.  Michaelson-Morley figured they’d measure the directional flow of the ether.  Turns out that they couldn’t find one.  Indeed, that experiment in which they attempted to measure something turned into one of the foundations of Einstein’s theory of relativity.  Run an experiment.  Measure the results.  Decide what to test next.  Run another experiment.  Eventually we converge upon the truth, but we get there only via feedback systems.   Expert intuition, or even perfect planning are simply insufficient.

As Agilists, we all do standups.  Three questions.  What did you do since the last standup?  What will you do before the next one?  Do you have any impediments?  And maybe a fourth: Do I need to have a parking lot conversation after the standup about anything?

Or at least, we all try to do them.  Oftentimes, we run into difficulties.  Sometimes the scrum master tries to lead the standup, and take reports.  Sometimes the standup turns into a set of conversations.  Sometimes the team drones on.  Sometimes even the scrum master is unable to prevent herself from asking questions of the folks reporting.

Is there anything that can be done about these problems?  Funny you should ask.

In the last few months we’ve seen a few interesting experiments tried in our standups.  The simplest standard experiment in standup is to choose a talking token, and to require that the only person who gets to talk is the one with the talking token.  In general, this is a good practice, and if the standup has any tendency to revert to conversation rather than a short team-to-team reporting, the talking token is a generically good idea.

A step in that direction that went very well for some of our teams over the last year occurred when trying to get remote workers to report /participate during the standup.  We ended up having difficulties getting the polycom system to work so we ended up using a cell-phone, and calling the shared number.  Then, the person reporting would hold the cellphone, and speak into it, allowing the remote worker(s) to hear what was being said.  As a side effect, it was among the most well-obeyed talking tokens I’ve seen.

A different step in that direction came up when one of our most conscientious scrum masters found that she couldn’t prevent herself from asking questions during standup, and also determined that not everyone was following the rules.  Her response was to print up a set of four index cards, each with one of the 3+1 questions on it.  The new rule on that team is: not only can you not talk unless you’re holding the deck of cards, but you also can only talk about what card you’re showing.  It makes standups extremely focused.

Also, because one of our standup’s quality metrics is that we do 4-days a week of correct standup behavior, that same team has Cowboy fridays, in which they do a 90% correct standup, but relax a little bit, and allow themselves to not follow the rules perfectly.

But the last experiment may be the best.  An awful lot of scrum teams have a difficulty with just yammering on during the standup, rather than talking about what tasks they accomplished, and what tasks they will be working on.  The trick we’ve recently tried to address this concern (besides the normal bribery and threats) is to attempt silent standups.

The rules:  Do your standup correctly, but no spoken words (or sign language).  Move tasks, from WIP to complete, from not started to WIP, or update their hours.  Also, write up impediments, and parking lot items into the right locations.  We’ve tried a few.  They are incredibly good at forcing the team back to the task-focused nature of the standups.  Might be the best experiment we’ve tried related to standups.  Also, silent standups end up being really short.  A modification would be to just do Today/Tomorrow silent, and allow impediments and parking lot items to be vocalized.

While I wouldn’t suggest that silent becomes the norm, doing it once every week or two really reminds teams to focus on talking to tasks, skip talking if they have nothing to say, and to put tasks up that are being missed in normal discussion.

What else have you seen work to make standups better?

There have been dozens or hundreds of explanations of Agile thrown about by dozens of us Agilistas these last dozen years or so.  This is me throwing my hat into the ring.

Agile consists of precisely one idea applied consistently to the business of software development.  That idea is:

Feedback loops.

Why do we have a daily standup?  Because the daily standup gives you feedback (from the team to the rest of the team) on (among other things) the progress of the team towards the end of the iteration.

Why do we have an iteration demo?  Because the iteration demo gives the project stakeholders feedback from the APO on what he’s been getting the team to do in the last iteration.

Pair programming?  Feedback on the second-to-second basis on code design/correctness.

Automated unit tests?  Feedback on the quality of the code on a minute-wise basis.

Retrospectives?  Feedback on the quality of the process.

One more time:  there is only one big idea in Agile.

Feed the feedback loop

First…This is Kyle.  Not Tom, Not Geri.  Maybe I should be Granny.

One of the things we’ve been worrying about at work recently is metrics for Agile Adoption.   How can we tell if a project, or project area, or the organization as a whole has become Agile?

Our first pass at this question resulted in the recognition that there’s a whole bunch of items that someone ought to be doing to be doing Agile well.  And so we worked out a 100-point checklist for that: here’s what we’d like to be doing.  But then the inevitable business question of “passing score” came up.  And we had to think harder.  Our question became “What is the minimum viable product of an Agile adoption?”  What measurements do you have to make to give the yes-no on agile for a team?

I propose that fundamentally, there is only one measurement that we really care about;  that everything else is a detail:

Do you get feedback from delivering working, tested, end-to-end, deployable, “DONE” code to business users every 1-4 weeks?

Pair programming?  Support for making that 1-4 week cycle happen.

Automated testing?  Support for making the testers not explode on iteration 4.

Daily standups?  Support for finding problems daily, so we can hit our cycle.

Task board?  Continuous information about whether we are on track for our cycle.

Burndown chart?  Information so we can correct daily for our 1-4 week cycle.

One more time:  You can measure (the beginning of) agile adoption in one metric:

Do you get feedback from delivering working, tested, end-to-end, deployable, “DONE” code to business users every 1-4 weeks?