Sep 172011

Only one girl gives me the raspberry...

Earlier this week, Renee Troughton wrote about the confusion that sets in with the various definitions used to describe requirements in agile development:

Epics, Themes, Stories, Features, MMFs, MVPs, MVFs, MMRs, Goals, Objectives, Tasks, etc.

As I read her post, I caught myself thinking about whether the different distinctions really help me write better software.

Meanwhile, Renee points out that people don’t always agree on the distinctions. Go figure, with so many ways to describe them.

If producing software is our main objective, then we come up with distinctions to help communicate and coordinate that production… except that confusion over common terminology actually makes communication harder.

Shifting paradigms in science

Now, in scientific paradigms (and I don’t pretend that writing software is as scientific as it is creative), we describe reality in a theory that holds up – until it doesn’t anymore.

When we discover it doesn’t hold, we propose a new theory that takes care of our past observations as well as what we now observe. In The Structure of Scientific Revolutions, Thomas Kuhn writes about “normal science” and how paradigm shifts take place.

In science, we move back and forth between:

  1. Trying to show that our current paradigm is satisfactory for the problems of the day and
  2. Trying to claim that the need for a new paradigm is upon us.

We once believed in miasma (bad air) theory as the cause for the spread of cholera and the Black Death… and then we learned about germs. We once thought we could store electricity in the water of a Leyden jar… and then we learned about capacitors.

During the transition from one paradigm to the next we just can’t explain some phenomenon we observe in terms of the old rules. We start to invent terms to fill in the gaps left from our previous understanding… and people get confused for a while.

Agile distinctions are metaphors

In the world of agile, however, we keep piling on the distinctions, without producing a truly standard lexicon. We aren’t in the middle of a paradigm shift – the problem is that our vocabulary is full of metaphors that make the distinctions weak.

Though metaphor is usually intended to help produce shared meaning, when the metaphor itself is not shared between people and we base our language on that metaphor, we leave meanings open to each person’s interpretation of the metaphor in question.

We can’t debate the “rightness” or the “wrongness” of a metaphor that isn’t held by others the way we like or with the precision we intend. Or rather, we can only debate dogmatically. (And we certainly do that.)

Is an Epic bigger than a Theme? Or is it the other way around? Who says so? If you encountered the confusion Renee writes about, your answer could be “it depends who you ask,” or simply “it depends.” Of course, if your answer is “who cares?” then we are in the same camp. Read on.

Back to basics… it’s the software

Why not a "library" metaphor???

Renee proposed a “library” metaphor that works just as well for me as the collection of terms she cited in her post. Remember that the main goal is producing software?

What it comes down to for me is that I don’t really care about whether the Epic or the Theme is bigger.

I’ll use what I need to build up and coordinate my team… and to communicate with my customers. And I’ll specifically avoid confusing them.

As I am sure you are aware, Newtonian physics was the answer before relativity… which was before quantum mechanics… and for most people Newton still works just fine.

We’ve had user stories as long as we’ve had XP. Now, Epics and Themes are helpful tools in planning bigger stories, but the skill of the project coach and team to ship the software takes priority over the nuances in terms.

Getting engaged in dogmatic debates over which metaphor sounds right to us is more like miasma. (Bad air, remember?) I’d be just as happy with invented words if they helped us communicate.

  17 Responses to “It’s the software, silly”

  1. The name, and hence the metaphor, for these different sized stories is not important. I’ll generally use whatever terminology is already in use by the client. There is not need to reconcile the various uses of these terms or to try to create “the best” set of terminology.

    What is important is that these things refer to chunks of functionality, not just chunks of work. Too often I see this facet get lost in the shuffle, leading people to try and measure progress by effort expended rather than by working software.

    • George, Thanks for cross-commenting here and on the LinkedIn Group. Last week, Michael Boumansour and I had a similar conversation about where task-orientation can creep into a project, and I agree with you that we have to keep our focus on the features and functionality. Much of our conversation involved the place for holding a “vision” for the team that helps them work toward the product and not just the “chunks of work” (tasks).

      Welcome back from Agile 2011!

  2. On LinkedIn Group “project management in – depth study”, Jeff Furman wrote:

    Hi Ken, this comes up a lot when I teach PMP classes. This comes up also with terms like ‘baseline’ versus ‘benchmark’ which have very specific standard definitions in the PMBOK, but which are used differently in different companies “outside the PMBOK”.

    I think there is a lot to be said for the way PMI goes for standardization of agreed-upon definitions of such terms. And I find that most students really like learning the agreed-upon PMI standard definitions, so they can use them the standard way and “move on with their lives.”

    • Hi Jeff. I have also noticed that people desire solid distinctions against which they can communicate clearly and execute more effectively in teams. Actually, I am curious and looking forward to the forthcoming publication of the PMI agile perspective…

      Because of the rapid expansion of agile terms and the high profile founders of different movements, the terms have become blurred. Even the subculture around agile seems to lead some people away from standardization and formality… although there is nothing in the most prevalent agile approaches that make it so.

      Regardless, that is an issue that makes standardization more difficult in agile communities. When Renee referenced Michael Cohn, and there is growing support for other “standard” leaders, maybe we will settle in on a consistent lexicon.

  3. On Google+, Stephan Schwab shared:

    The less experienced people are the more they seem to like to have clear definitions. They more their leaders are afraid that their people don’t have experience the more they lean towards a dogmatic approach where things have to be clearly defined. Both sides feed each other.

    • Yes. Having a discourse full of experienced people leads to arrogance, meanwhile. To be consistent in our use of words makes communicating easier, whether we are experienced or beginners.

      Doctors, lawyers and architects have clear definitions. The domain of patterns says software professionals do, too. And everybody wins.

  4. On LinkedIn Group Product Design & Development, Chuck Hodges wrote:

    There is also a similar issue for global projects, as its not just the technical metaphors that don’t translate (even when team members speak the same language)

    • This situation is fundamental enough that I figured it would be a useful conversation.

      Some see it as a need to get away from metaphors, others as a need for standardization. As our conversations evolve into discourses, we develop an internal language and the effective use of metaphors for communicating inside and outside becomes increasingly important.

      (And our ineffective use of metaphors should be identified and addressed before we produce too much communication cost.)

  5. On LinkedIn Group Agile Alliance, Marvin Toll wrote:

    Agreed. As an engineering discipline we need to move “Beyond Metaphor to Metric”.

    Here is a singular example… although (admittedly) we have also invested many years in other metaphors (besides Technical Debt).

  6. Also on Agile Alliance, Farid Askari wrote:

    With regards to your specific example, Themes versus Epics, I actually find it very useful to distinguish between the two, as they are not the same.

    As a product owner, I explain to my team an Epic as a user story that has not been decomposed into smaller stories according to the INVEST model. A Theme is a collection of related user stories. For example you want to design a trip planning site. At the high level, going to Italy is a Epic story, whereas, going on wine tasting, bicycle tours, hiking can all be grouped into a country-side theme vs scuba diving, surfing, boating can be grouped into aquatic theme.

    It makes release planning easier and gives the stake holders and the team members a better visual understanding of the different parts of the product.

    • Farid, I like your distinctions. If the distinctions are not shared, however, they can get confusing when people with different backgrounds come together. Renee pointed out specific cases where the distinctions began to overlap and the “alphabet soup” was getting untenable.

      I like Michael Boumansour’s approach of not introducing some distinctions unless and until they are contextually relevant. Waiting to introduce them, to me, also suggests there is space for making them consistent.

      The more fundamental concern is not Epics and Themes, but using metaphors in everyday speech that don’t communicate our thinking clearly. Unless you are an 800# gorilla, you have to give 110% to think outside the box.

      To have produced and shipped over a decade of agile products and not consider how our language helps or hinders communication can lead us into an era where our distinctions make people roll their eyes as well.

  7. And then Renee Troughton added:

    +1 At the end of the day I just want to get on with the project and deliver (ironically I said this on the podcast one day before you blogged about it). We ended up talking about this for fifteen minutes, in the end deciding that Epics and MMFs are groupings of stories but different, and there was no agreement on Themes.

    To re-iterate thoughts:
    * I would love standardisation on this and would welcome it with open arms (in the hope that a group of sensible, intelligent people thought this through fully)

    * The terms themselves bug me more so then the lack of a consistent decomposition framework. ‘Sprints’, ‘Scrums’, ‘Story’, etc – it just doesn’t help bridge the divide. We confuse the business enough with IT jargon, hence why I sometimes use the metaphor to aid in understanding, but yes as I said at the bottom of my post I was concerned with introducing more confusion.

    I like metaphors. I loved your quote:

    “Though metaphor is usually intended to help produce shared meaning, when the metaphor itself is not shared between people and we base our language on that metaphor, we leave meanings open to each person’s interpretation of the metaphor in question.”

    It sums it up for me. They are useful, but not if used incorrectly.

    • @Renee, sorry I missed your podcast… it is queued, but I hadn’t gotten to it. Meanwhile, it was in reading your post that I made my initial comment and figured it was worth writing more about.

      When I considered your sources and close monitoring and reporting on the agile space, it emphasized that the question of metaphors is not just a newbie question. It appears to me that ignoring concerns over communication in our industry is a form of irresponsibility.

  8. Back on LinkedIn Group Product Design & Development, Timothy Peters added:

    This is a fascinating concept to consider. I find that as the circle of people influenced by the metaphors widens, I have to be careful to periodically redefine their meaning and remind everyone what they mean. This then butts up against the communication cost factor and how much of this repetition is productive.

    Perhaps this points to the importance early on of working to infect conversational participants with a desire to teach newcomers the metaphorical meanings. This would seem to demand a certain competency in leadership in order to build this motivation into early conversation participants. Perhaps those competencies center on first being deliberate to influence from the moment a new idea arises and secondly being persuasive in your influence.

    Bottom line, if you can properly influence your conversation participants early on, could they then become the catalyst to ensure the balance of both efficacy and efficiency of the metaphor’s definition?

    • In “Leading Change”, John Kotter spoke to the concern for making sure distinctions are communicated effectively, even referring to the possibility to exploit 120,000 touch points rather than 6 when your vision for the future evolves.

      When we think people have heard our message and understood our metaphors once, perhaps even six months ago, but we think their interpretations are not evolving over time, we risk mis-communication (or “dis-communication”).

      So we are left with “how” to communicate to strengthen the message and get it to stick. We always have newcomers, so the first concern is not to assume everybody is starting from the same place. Another is to make sure core leaders are speaking together and share the same vision… and then get their commitment to weave it back into everyday life.

      As we embody shared vision, we avoid people thinking we are fakes, and we distribute the cost of communicating into small chunks that don’t seem as repetitive… “it’s just the way we do things” to achieve our vision.

  9. On LinkedIn Group Agile Tech Writers, Chris Despopoulos wrote:

    This is why writers are commonly called authors… authority has value in language, even in texts. Agile, like so many other things in high tech, is in no small part an exercise in inventing language. And then implementing processes based on descriptions in that language. Well, there are times when an authority has to step in and say, “This means X.” And for the greater good, the rest of the gang has to agree. Otherwise, babel… So I would say, if there’s a problem reconciling a metaphor, it’s time to bring out the gavel and unilaterally define it.

    My experience has been that Agile ends up pretty darned colloquial. That is, each group has its own (shall we say) dialect. It’s ok… so long as the group knows what it’s making, and how to organize the work. If two groups must join, then a simple mapping of terms should not be that hard… dialects transfer pretty easily. If one group has a new term for a new concept, then the other group is free to learn.

    • Chris, I have noticed that we develop our own discourses as we work in teams and small groups together, like a tribe. Everything is based on a similar foundation, but language always evolves.

      It shows up the most as tribes come together. Where differences are evident we can talk about them… but where they are more subtle, we risk thinking we are saying the same thing when we are not. When we hire new “experienced” team members, they may need time to learn the dialect, and it is not uncommon to see new employees get stalled a little reminiscing about how their other team “did it”.

      To this point, while agile has many leaders we know by name, it has appeared to me to be more democratic and less authoritarian than previous development approaches. It has produced some benefits, but it may slow down our ability to say “This means X.”

Leave a Reply