RSS

Category Archives: Organizations

The Coolest Thing EVER! (for Lean geeks)

Lean thinking and theory of constraints have gone hand-in-hand in the agile world for as long as we’ve been stealing/borrowing ideas from the manufacturing world.  If you aren’t very familiar with how these things fit together with agile practices a good starting point is this InfoQ article (it is a little dated but still valid).

So Lean tells us we should reduce waste in our system and focus on throughput and cycle time, but doesn’t really do a good job telling us which waste to focus on first.  And that is a big-ass problem – because if we focus on a part of the system upstream of the bottleneck we can adversely affect the performance of the system by increasing WIP consequently increasing cycle-time and decreasing throughput.  Ouch!

Theory of Constraints comes to the rescue by telling you which waste to focus on first – the bottleneck!  The slowest part of your system is where you should start because, by definition, any improvement you make to the bottleneck directly impacts your cycle time and throughput.

So for years that’s where I left it when describing it to my clients and students.  The question of “How do you find the bottleneck?” never had a straight-forward answer.  That’s where you bring in the consultants or spend significant time and effort understanding and measuring your system so that you can find that all-important bottleneck.  An activity that has always seemed nebulous.

Okay – here comes the coolest part ever!  There is an insanely simple way to find the bottleneck.  Every. Single. Time.  (If I stop here it would make a great cliff-hanger wouldn’t it?)

  1. Draw/create your value stream map.  Pay special attention to identifying the queues in your system.
  2. Then, starting from the right-hand-side, traverse the VSM and find the first queue/inventory.
  3. The process to the right of that first queue from the end is your bottleneck.

Ta Da!!!!  That’s it.  Insanely simple way to find the bottleneck.  I’m sure this must have been written up somewhere before, but I’ve managed to miss this little tidbit throughout the years (and so have many of those I’ve been checking this with over the past few months).

“It can’t be THAT simple!”, I hear you exclaiming.  But think about it, if this is the very first queue from the end of the VSM, then any improvement flows directly to the user with no blockages because there are now queues downstream.

Feel free to poke holes in my theory and disprove this statement and I’ll be grateful because I will learn something along with you.  But if you can’t, isn’t this really cool?

 
2 Comments

Posted by on May 17, 2014 in Lean, Organizations

 

Tags: , ,

Estimates Are Always Low and Dates Are Not Met

Estimates are always low so dates are not often met.  That is a common occurrence in today’s software environment.  There are many, many approaches to this age-old question.  Relative estimation, no estimation, ideal days, and some fancy-shmancy techniques that are mathematically sound (given a few unsound assumptions) that are significantly impressive to those so inclined.

Whatever technique teams choose, they are often still disappointed.  So what gives?  Is there a practice out there that can save us?  My answer is both yes AND no.

The no part is easy. No, there is no one practice out there that can give us accurate estimates. Estimation is fortune-telling.  And all fortune-tellers (at least in software) are wrong.  Estimation is a lie.  Pure and simple.  But it is a very useful lie, because it really helps to have some indication about what and when we’ll get things done.

The yes part is a little bit more involved.  And it comes at the problem side-ways.  Instead of considering the estimation practice itself, let’s take a closer look at how teams typically fail with all estimation techniques – and then address the commonality instead.

Choose any single technique out there.  Whether it is relative estimation or anything else, there is a really good chance it is not just marketing fluff or bullshit.  In fact, there is a really good chance that some really smart effective people used it successfully and have probably helped others use it successfully also.

So what gives?  Why were these techniques successful in some places and unsuccessful in others?  Well, there could have been many reasons, here are some of the most common ones:

  • The original context was different, and it needs tweeking for the current context,
  • The technique was modified because it didn’t “fit” into our context, instead of trying to take the (usually negative feedback) and change the way we work,
  • We weren’t very disciplined in using it, because it was too hard, (check out We tried baseball but it didn’t work)
  • There were significant failures, and instead of taking that as a sign of the method giving us feedback, we took it as a sign of the method failing,
  • etc…

So let’s get back to yes, these methods actually work.  What I’ve found, again and again, when it comes to estimation, is that we are not able to effectively manage our agreements around how we will estimate and manage those estimates together.  We are not able to handle failures when they happen.  We are not able to confront issues when they arise.  We are not able to be disciplined in what we do.

These methods, like any methods, can be seen as agreements made amongst team members about how they will work together.  So if estimates are always low, then perhaps we need to look at our agreements; especially those we have broken.  And, perhaps, there is a reason that we are constantly giving low estimates.  Here are some of the ways some of the invisible impediments get in the way:

  • Safety:  Perhaps the #1 culprit when it comes to estimates.  If I don’t feel safe giving what I *really* believe something will take then you won’t get a good estimate from me.  If I don’t feel safe calling out an unreasonable estimate early – then there will be a problem.  And, perhaps the most common instance of all, if I don’t feel safe to say “I was wrong, I need more time” early on – then I’ll just soldier-on.
  • Respect:  Many times we don’t respect each other.  Take the common “Us vs. Them” mentality that is so prevalent in today’s business culture.  If the “Us” is managers, and the “Them” are developers, and we see them as incompetent, they will get that.  They will probably see us as being unreasonable and not able to understand the intricacies of software development. They will also act accordingly.
  • Ownership: Do we have a mentality of a whole team?  Do we have a shared task that we cannot complete alone?  Is our mindset that of “I own the results”?  If not, then it is all too easy to be in an obligation mindset and do estimates a year out because “you HAVE TO”.  And if you do that, then you disconnect from the results and can easily convince yourself “well they were asking for something unreasonable anyway, so I gave it to them although I KNEW it was the wrong thing to do”.
  • Intent: Why are we REALLY doing estimates?  Is it our intention to just get the managers off our backs?  Or, as managers, is our intention to hold people accountable (and even CYA?) if things go wrong even though we know estimates are a fiction?

So, if we are doing some sort of estimation method and it is not working, perhaps we need to look at the team dynamics.  Perhaps we need to look at how we work together as a team around our agreements.  And perhaps we need to look for some of those pesky invisible impediments and start on fixing them first – BEFORE we look at the estimation methods themselves.

 
Leave a comment

Posted by on December 16, 2013 in Culture, Organizations, Teams

 

Is It Safe?

The Scaled Agile Framework (SAFe), based on the work of Dean Leffingwell and his team, is a hot topic these days, and the discussion about it is characterized by hot language on both sides. Some people love it, others not so much. Taking sides on something like this is to be expected. But is it productive?

SAFe may not be the safest thing to talk about right now. But when it comes to discourse in the Agile community, we tend to be civil about it. So we thought it would be safe to come out with our own thoughts on the framework based on our experience of working with it, of reviewing the materials that describe it, and our  experience with Agile adoptions and implementations in general.

Getting the Big Picture

Over five days at the Agile 2013 conference, we had many opportunities to study “the big picture”. And each time we did, we felt like there was something missing. We realize now that that something is people.

In the Agile community we value individuals and interactions over processes and tools. We know that processes and tools are vital, but we acknowledge that their vitality is predicated on how people work together as they use them.

When we think about individuals and interactions, we think about organizational culture. Without a healthy workplace culture, processes and tools—even the very best—don’t work as well as we hope they will. We believe this is why so many Agile adoptions struggle and often fail.

Lots on “What”, Little on “How”, Less on “Who”

SAFe provides a detailed blueprint of what organizations can do structurally, but it is much less detailed about how things can be done, and it offers almost no information about interactions and individuals and the workplace culture that might support their success. This appears to have been a choice made with regard for the focus and scope of the effort as Mr. Leffingwell wrote in a recent blog post:

SAFe is largely quiet on the topic of implementation, change management and evolving corporate culture. We are focused on the framework content and continually understanding, and codifying best practices that people like you, in the field, discover. That is more than enough charter for us. However, we do understand that changing corporate culture to better reflect the behaviors and aptitudes of a Lean|Agile enterprise is a critical aspect. But, in our view, this is best achieved as result of success and better outcomes, rather than an object of attention to be addressed directly.

Let us consider this last sentence carefully. Is positive culture change best achieved by improved outcomes that result from new practices? Or are improved outcomes more likely to result from positive changes in culture?

We believe this is a false dichotomy. In our experience, the greatest successes and the most spectacular outcomes (the extraordinary productivity increases that research on Agile often describes) are achieved when culture and practice support each other in a positive feedback loop.

The Ever-Present, the Foundational, the Inseparable

Merely choosing to begin any type of Agile adoption is, in itself, a phenomenon of culture. An organization’s decision to trade one set of practices for another is only possible if the choice is culturally viable. Culture and practice are inherently intertwined and in play simultaneously. Our best chance of winning the game comes from leveraging both.

Culture is the soil in which the seeds of change are planted. To maximize our chances of success, we must tend to the earth as much as we tend to the business of getting things out of it. If the soil isn’t fertile when we start, and if it isn’t tended carefully along the way, growth is stunted, change withers on the vine, and in many cases, new initiatives die altogether.

SAFe is a strategy for change. It is a set of strategies, actually—a large and very impressive set that brings obvious value to organizations considering or executing large scale Agile adoption. But we have heard many times since organizational luminary Peter Drucker coined the phrase, that “Culture eats strategy for breakfast.” Why? Because even the best seeds have low yields in bad soil.

Back to Our Roots

We don’t have to go back to the Dust Bowl days or read The Grapes of Wrath to understand the importance of soil and, by extension, the importance of culture in advancing strategy. The soil of culture is where strategic change is grounded. Nor do we have to go back to the world-saving work of Norman Borlaug to know that the highest yields come from inspired and careful cultivation. But we must go back to Snowbird, Utah and the work that was done there in February of 2001, to remind ourselves of the fundamental ideas upon which Agile is based and why so many of us were so attracted to it in the first place.

When we do go back—when we read again the Manifesto and the Principles that define our work and enumerate the values of our global community—we see a group of people at the center of the software industry expressing the idea that people are at the center of software development.

Through all the projects and products we have contributed to and all our years of coding and coaching, we have come to believe that individuals and interactions matter, not only more than processes and tools, but more than anything else.

Culture is Complementary and Crucial

Culture without practice is daydreaming. Practice without culture is a nightmare. For SAFe—or any set of practices—to be optimally effective, a complementary cultural component is vital.

In affirming the importance of culture in Agile adoption and implementation, it appears that we are not alone. Mr. Leffingwell seems to be considering this as well. In the same blog post, he writes: “So maybe I’m wrong about just waiting for results before worrying about culture.”

To us this is neither a matter of right or wrong nor of waiting and worrying. Culture exists; it is here, now, in every organization where we work. It has mass and velocity; it is always moving in some direction whether we know what that direction is or not. And where it is moving always matters.

Just as we can make conscious choices about practice, so too can we choose to shape culture with commensurate intention. When we do, we bring under our control a force for powerful change while simultaneously reducing  risk. Is this a larger charter than attending to practice alone? Certainly. Do we think the effort is justified? We do.

We are happy to see that Mr. Leffingwell is also thinking about culture. It is our position that if we separate culture from practice, focusing on one to the exclusion of the other, we miss the opportunity to maximize results and minimize risk.

Haven’t We Known This Since the Very Beginning?

In pondering the interconnectedness of culture and practice, we we see why the dialog about SAFe has been so heated. In fact, we think Jim Highsmith saw this back in 2001, when he wrote:

…while the Manifesto provides some specific ideas, there is a deeper theme that drives many, but not all, to be sure, members of the alliance. At the close of the two-day meeting, Bob Martin joked that he was about to make a “mushy” statement. But while tinged with humor, few disagreed with Bob’s sentiments that we all felt privileged to work with a group of people who held a set of compatible values, a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work. At the core, I believe Agile Methodologists are really about “mushy” stuff, about delivering good products to customers by operating in an environment that does more than talk about “people as our most important asset” but actually “acts” as if people were the most important, and loses the word “asset”. So in the final analysis, the meteoric rise of interest in, and sometimes tremendous criticism of, Agile Methodologies is about the mushy stuff of values and culture.

We too believe that people are most important. We believe that culture is the engine that drives the most extraordinary results and that inattention to culture is the most common impediment to the success of Agile adoption and implementation.

What Will Make SAFe Safer?

The question is not whether SAFe should be used as the strategic basis for large Agile adoptions. The question is this: What will make those adoptions most successful? We believe that culture is the answer to this question; we believe that culture is the key to making SAFe safer.

Culture is not a replacement for strategy; it is a complement to, and an enabler of, strategy. It is also the true scaling agent of large-scale change. Without sufficient attention culture change, strategic change is all too often gamed, and then thereby undermined, sometimes to the point of total failure.

Through our work, we have come to value interactions and individuals over processes and tools. That is, while we believe that there is value to the latter, we value the former more.

Amr Elssamadisy and Steve Peha

 
4 Comments

Posted by on August 20, 2013 in Culture, Individuals, Interactions, Organizations, Teams

 

Tags: , ,

Why are most Agile Adoptions Failing?

I’ve moved this post to Industrial Logic’s blog.  I’ll continue to share my thoughts on my personal blog here and share the more mature articles to Industrial Logic’s site.

– Amr

 
1 Comment

Posted by on June 17, 2013 in Culture, Individuals, Organizations, Teams

 

Tags: , , , , , ,

Is it Safe to Fail?

Yesterday I was working with a group that was struggling with the balance between product owners and developers. It wasn’t an “Us vs. Them”, but a common tension that I’ve observed on teams working to get real results out of agile practices and processes. This particular team was using Scrum and we were discussing the question of when to review work during an iteration. Should the product owners wait until the end of the iteration to review the work? Or should they be reviewing work during the iteration as it gets completed? And what happens if they find something that doesn’t meet what they need?

In this particular situation, developers were often upset when product owners reviewed things that were still in-progress because “they weren’t ready yet.” They wanted product owners to hold off until they – the developers – said it was “ready for review”. The product owners, on the other hand, wanted to review things early so that if developers were going down a blind alley, they could tell them early on. Also, if there was a mistake – on either the product owner’s side or the developer’s side – that it was caught early and we didn’t spin our wheels working on something that would eventually get thrown out.

This is not an unusual situation. This particular scenario is one of the common reasons many teams find Kanban so attractive – because the artificial time-box of an iteration seems to keep us from doing the right thing and recognizing and responding to change early and often. But I wonder if this particular problem is not related to iterations at all.

In fact, I’m going to suggest that the root cause is the lack of feeling of SAFETY in and on the development team. Let me take a few steps back to explain:

I’ve been lucky enough to be on several high performance teams in my career. And these teams are phenomenal – they  are significantly more productive than your average development team. They do much better work from many points of views: quality, time to market, visibility, etc…. They also enjoy their work much more.

These teams are great at software development which means that they are extremely good at learning from failure. They use agile methods to build software, get feedback early, and respond to that feedback accordingly. A large portion of that feedback is based on failure: writing software that fails tests and gets fixed, building features that don’t meet the user’s needs and has to be re-designed or completely trashed, putting in technical solutions that don’t scale, and hundreds of other issues that come up. Those teams don’t get caught-up in the potentially draining tensions and stresses associated with failure.

Why not? What is special about these teams that they are resilient to the dragging and draining effects of failure – let alone regular and repeated failure?

You probably won’t be surprised to hear from me that I don’t have the entire answer, and the answer I do have falls into three categories: agile practices, individual human dynamics and culture.

Let me explain further. Failure – for most of us – is not an enjoyable experience. However some of us have become good at it. And the major reason behind this is SAFETY. If we feel safe to fail, and are rewarded for it regularly, we can find ways to fail fast and learn quickly.

Here’s what I’ve experienced and observed in teams that have the skill of failing fast and often and learning from those failures:

  1. Leaders create a culture that rewards small failures and the successes that come after them. They celebrate the successes and failures and lead by example.
  2. Individuals understand that failure is a milestone the road to success. They have experienced it multiple times and are not intimidated by it.
  3. Teams use software development practices that make failure SAFE.

Let’s look at #3 a little more closely. Consider different types of failures: failure in private and public failure. Failure in private is much easier to handle (although still not easy). Also consider that small failures are less overwhelming than large failures. A small failure is easier to recover from.

Now let’s consider some concrete practices that make it safer for us to fail:

  • Think of test driven development (TDD). How much easier is it to fail privately at your desk with a red bar, fix it, and then check in working code? How much less intimidating is it to find a mistake after a few minutes of work than a few days or weeks? Also, the other half of this coin, is the success and frequent, small celebrations of success when a developer sees a green-bar indicating tests pass.
  • Think of test driven requirements (aka TDR, automated acceptance tests first, behavior driven development/BDD, etc). How much easier is it to work incrementally with some FIT or Gherkin tests to make them pass and fail at the privacy of your own desk than it is for someone to manually review your work with you and point out your mistakes (or even worse, in the middle of an iteration demo with execs looking on)? Also, just like TDD, a passing test is a celebration of success.

The complaint from developers in the beginning of this blog were about product owners calling out their failures early and often. It was painful for them to have these issues brought up in public.  However these conversations with product owners have the potential of accelerating the learning of the team and thus accelerating their performance. The same developers on a team that practice TDD and TDR have fewer of those circumstances happen yet get the same feedback because these failures happen at their desk.

So, in the end, one of the best ways to encourage the learning from failure practice that is always found in high-performance teams is to make failing safe AND to celebrate successes. We can do this on multiple levels: at the cultural level, at the individual human dynamics and mindset, and with the software development practices we use. A few agile development practices are extremely good at this, specifically test driven development and test driven requirements because they allow us to fail privately and create small reward loops where we constantly celebrate small successes.

 
3 Comments

Posted by on June 5, 2013 in Culture, Interactions, Organizations

 

How Great Teams Make Decisions

So I’ve been reading We The People: Consenting to a Deeper Democracy which is a book recommended in The Culture Game by my good friend Dan Mezick.  This book describes sociocracy which is a consent-based governance system that looks a whole lot like scalable self-organizing teams.  Ok, sounds esoteric, right?  I agree, the book has been on my bookshelf for at least 6 months and I’m not quite sure why I picked it up, but am really happy I did.

Ok, I just lied, I picked it up because I’m trying to start a new user group in NYC focused on the the human dynamics and culture of high performance teams and I want to create a great self-organizing leadership team.  But I digress……

This morning in the subway, I read the following in a description of teams that practice sociocracy:

The requirement to resolve objections transforms decision making from a struggle for control into a process of puzzle solving.

That resonated for me.  In my experience on the few “magic teams” throughout my career that had really achieved high performance, they made some really great decisions.  And it wasn’t about power or the leader or anything else – it was really about the best decision.  It also wasn’t because we wanted what’s best for the team (although we did), but our mindset was different; it was about solving the problem at hand. And when we had a breakthrough – no matter who suggested the original idea – there was a collective feeling of success.  The mindset here was decisions are all about problem-solving”.

I didn’t realize it until this morning, but decision-making techniques are a really good way to evaluate the ability of an organization to get things done.  Those who can make good decisions repeatably will be much more effective.  And, as the wisdom of crowds tells us, a diverse set of independent non-experts will make better decisions than experts every single time.

Again, looking back at my experiences, but this time with teams and organizations that are struggling, they had difficulty making good decisions.  They could not leverage the expertise of the people they hired and payed good money.  Decisions were often made by managers and those in power who were usually several levels removed from the problems at hand.  This, unsurprisingly, led to low performance and mediocre results.  In these cultures, decisions were tied to power.   The mindset was “the important people make the decisions.”

Ok, so why am I blogging about this?  Well, the idea of “self organizing teams” has always been an ill-defined part of the message of the agile community.  How do they scale?  (Scrum of scrums has never worked for me.)  How do self-organizing teams work together?  Can we get the same level of performance that we get in small teams?

This is a step along the way of answering these questions.  Effective self-organizing teams make decisions with a mindset of “problem-solving” instead of “power”.  Mindsets can scale.  In fact, changing your mindset is often instantaneous.  Also, this is a good diagnostic tool when looking at teams and organizations – how do they make decisions?

 
Leave a comment

Posted by on April 12, 2013 in Interactions, Organizations, Teams

 

Tags: , , ,

Culture or Individuals First?

So, the lean world says that environment trumps all – and it does, but it is not sufficient.

Individuals.  “Individuals and their interactions over process and tools” says the Agile manifesto.  Yep, that too.  Useful in context, but also not sufficient to produce high performance.

Lately, I’ve been reviewing Tribal Leadership in preparation for Dave Logan’s talk later this month, and he talks about the tribal culture being all-important and that it is the determining factor for the level of success achieved per group.  But what comes first, the tribal culture “chicken” or the individual behavior “egg”?

In my experience it always comes with the individual.  That individual shows the types of behaviors we expect to find in high performance teams: ownership, respect for others, ability to build trust by making and keeping agreements, and the ability to create a safe space for others to collaborate with him.  That person somehow finds others of like minds, or infects those around him.  And once they reach critical mass, they start to set the norms and expectations of their group (team/department/organization depending on their reach and circles of influence).

So my answer (for today) is that individuals come first.  That’s my story, and I’m sticking to it.

 
Leave a comment

Posted by on April 3, 2013 in Individuals, Organizations, Teams

 

Tags: , , , ,

Evocative Documents, An Example Agile Adoption Pattern

Here is an example pattern from Agile Adoption Patterns: A Roadmap for Organizational Success:

 

Definition: Documents are created that evoke memories, conversations, and situations that are shared by those who wrote the document.  They are more meaningful and representative of a team’s understanding of the system than traditional documents.

 

Business Value: Evocative documents help prolong a product’s lifetime by accurately representing the team’s internal model of the software and allowing that model to be handed down from master to apprentice.  The better understanding of the system over time also reduces the maintenance cost of the system over time because appropriate changes reduce the deterioration of the software. 

Sketch: Aparna and Dave were on their way home from a week long UML training course and discussing what they had learned.  “UML certainly provides a rich and detailed tool for describing our software,” Dave noted.  “But it can still be misleading,” Aparna responded. “Remember our discussion about the customer class?”  “I do,” said Dave, “and I remember how we got into that discussion of what ‘is’ is – when people started using our UML description  as if it was a customer.”  “Oh yes, and that guy in the back talking about Alfred Korzybski and ‘the map is not the territory,’ that was weird,” Aparna added.  “But he was right, really,” continued Dave. “No matter how much detail you get in your UML model and templates, something is always missing.  The model is never the real thing.”  “And our understanding of what the real thing is keeps changing, and changes from one context to another,” Aparna said. “How can we put all of that in a model?”  “Well,” Dave suggested, “we probably don’t need to if we can find a way to remind ourselves of everything we know about something when we need it.”  “How would we do that?” Aparna asked.  “Remember that icon on the wall of the seminar room,” Dave enquired. “Remember when we asked the facility manager about it and she talked for half an hour about its meaning and history, and everything.”  “Sure do,” Aparna responded. “One simple symbol evoked a huge amount of memory.  Maybe that is the secret …”

Context: You are on a software development project where product lifetime and reducing the cost of software are important – you are building a system to last for several years.  Documentation isn’t working – as a document is passed from one person to another much of the context and value is lost, and as a result, the maintenance team’s understanding of the codebase constantly deteriorates.  This is resulting in the calcification of your software system. 

Forces: 

  1. Literate and legalistic societies and organizations share a deeply held, though often non-conscious, belief that written documents are representative in nature.

  2. A contract IS the agreement among parties to the contract.  The blueprint IS the building, albeit in a different format.  

  3. The specification IS the software artifact desired.  This belief is so strong in the arena of software that many believe that it should be possible to formally and mechanically transform specifications into an artifact with no interpretation or ambiguity.

  4. Documents that are built collectively – by having a conversation – are much more valuable to those who were part of the conversation.  These documents are evoke memories of the conversation, its context, and much more than what is merely written on paper.

  5. Agile development is the embodiment of group “theory building” as described by Peter Naur [Naur 1985].  That is, the software we build is directly related to a mental model – the ‘theory’ – that the programmers share.  To impart this model to others traditional documents fail miserably.  Naur suggests that the only successful way to share this model is through apprenticeship.

  6. Agile practices, more than any other kind of development practice, require the creation of a rich and easily accessible “external memory”.

  7. Representational documentation is notoriously limited and has a long track record of failure in supporting “theory building” and acting as an “external memory.”

Therefore:

All documentation should be evocative rather than representational.  Anyone that has read a good novel is familiar with the notion of an evocative document – one that enables the reader to “recall to mind” thousands of sensations, emotions, even details of time and place that the author could not possibly have included in the text of the novel.  

This is how you can truly preserve the shared knowledge and understanding of the team and pass it along to new members.  There is no “one way” to put together such a document, so the distinguishing factor in an evocative document is that it is a reminder of the real information and knowledge in a person’s head – it is not the knowledge itself. It is not directly representational.

A team that relies on evocative documents spends more time in face-to-face conversation and less time building and maintaining documents.  The documents they keep tend to be simple and only comprehensible to those in the conversation – therefore to transfer the knowledge behind the document to someone who was not there, the conversation and context have to be repeated and the document built from scratch.  What is gained by this is a much better transfer of knowledge within context that ultimately leads to more proper understanding of the application and reduced maintenance costs.  

More specifically, evocative documents tend to have the following characteristics:

  1. • Informal – 3×5 cards rather than syntactically correct and detailed UML diagrams.

  2. • Natural language based – both in terms of the natural language used by the team for communication inside and outside the office, but also in terms of the domain driven vocabulary of the project itself.

  3. • Rich in references to people, time, and place.

  4. • Contextual in nature, photos that are rich in color and detail communicate much more than simple UML diagrams. 

Evocative documents are an external memory to a previous conversation.  Evocative documents have value to those who took part in the conversation.  To share such a document with someone who was not part of the conversation they must reconstruct it with someone who was part of the original conversation.  This means that evocative documents are not very scalable.  (The problem is that neither are traditional documents, we just assume they are and are unaware of/ignore the information loss and corruption.)  

But:

Your documentation has probably slipped into representational form and is no longer evocative if:

  1. It takes longer to produce the documentation than it does to comprehend and use it.

  2. Anyone in the organization begins to express a belief that the documentation has intrinsic value and not just utilitarian value.

  3. Documentation that is highly stylized and that uses precisely defined and context free syntax (e.g., UML) will almost certainly be perceived as representational rather than evocative.  However, it need not be, as long as it brings up a shared conversation and/or experience.

  4. There is any kind of movement to make the documentation archival.

  5. Specialists are employed to produce the documentation.  There is an exception to this rule:, technical writers (who should really be more novelist than tech writer) charged with producing manuals and books for users of the software that were prevented from participation in its creation.

Variations:

Agile modeling, as originally described by Scott Ambler, is a form of just-in-time modeling.  People model to have a conversation and then take a digital photo of that model to remind them of the conversation.  This is a form of evocative document that uses highly stylized languages such as UML.

One last note on evocative documents – they point out a limitation of our current culture and what many of us take for granted.  Accepting the value of evocative documents means rejecting the notion of accurately communicating detailed information in context by writing them down.  You have to have a conversation, the document is there only as a reminder.  As the eminent American philosopher, Dr. Phil says “how’s that working for you?” – how have the reams of requirement, design, and planning documents been working for us?

 

References:

Ambler, S., and Jeffries, R., Agile Modeling: Effective Practices for Extreme Programming and the Unified Process, Wiley, 2002.

Dahlstrom: external memory

Larman, C., Applying UML and Patterns: An Introduction to Object Oriented Analysis and Design and Iterative Development 3rd edition, Addison Wesley, 2004. 

Korzybski, A., Science and Sanity: An Introduction to non-Aristotelian, Systems and General Semantics (5thedition), Institute of General Semantics, 1994.

Map-territory relation, Wikipedia, http://en.wikipedia.org/wiki/Map-territory_relation, accessed November 2007.

Naur, P., “Programming as Theory Building,” Microprocessing and Microprogramming, 15:55, 253-261, North Holland, 1985.  (Also reprinted in Cockburn’s Agile Development)

 

 
Leave a comment

Posted by on March 18, 2010 in Interactions, Organizations, Teams

 

Tags: , ,