Posted on

SPIRIT: Development & Transformation in Organizations

Open Agile Adoption is a technique for success with Agile. It is an approach that encourages (and in some ways makes obvious) what it takes to get a rapid and lasting Agile adoption. Open Agile Adoption uses Open Space Technology as the primary tool for achieving this goal.

Open Agile Adoption is a sociological approach to Agile adoption. It is not a set of Agile practices but rather, a tool for “opening space” for the right conversations. It assumes people power Agile practices, not the other way around. Open Agile Adoption is based on the hypothesis that people need and require a sense of control and sense of progress to feel good at work and in life generally. It assumes that people want to (and in fact need to) express what they want, think and feel. Open Agile Adoption leverages the Open space meeting format to deliver a sense of control and to create a safe and open place for people to bring the very best they have to the task at hand.

We all want rapid and lasting Agile adoptions. At issue is exactly how to do this. We know the current practices-based approach of mandating specific practices is probably harmful. All we have to do is inspect the results to see what I am talking about.

Spirit: Up… or Down?

Harrison Owen has written many books on Open Space. When I was first forming my ideas on Open Agile Adoption, I started Googling around and eventually I came across an absolute gem of a book called SPIRIT: Development and Trasformation in Organizations by Harrison Owen. Not only is this book amazing, but it is also FREE for the taking as a PDF download.

In this book I picked up many interesting and useful ideas. It’s over 200 pages so stop right here if that’s too long for you to commit to. This is a deep and dense book. When I examined it I found that my pattern was to read maybe 10 pages and then try to integrate them. I went along this step-by-step way for quite a while the first time around. I’ve read the book 3 times and I still find myself reading it in this manner. It’s deep and wide, like a big, old river.

Here are some of my key takeaways from this book. Some are covered in the book, others are personal insights derived from a careful reading of it:

  • The spirit in an organization can be ‘up’ or ‘down’.
  • The culture is in the stories people tell. You an plot the culture in graphical form, using a mythograph.
  • All change is grief. People enter into a grief pattern which includes anger and (especially) denial.
  • Open Space can tip a group of people from denial to hope in one shot, if and when they are ready to move
  • Open Space can provide just the right set of conditions in time and space to create action and movement in the minds of participants
  • The entirety of reality is self-organizing. This means all social systems are self-governed.
  • Leadership is a essential function of a healthy social system. It is an emergent property of a smooth-functioning self-organizing system. The social system supplies leadership to itself. Leadership is not a role.
  • Likewise, management (of feedback) is essential and a self-supplied function of a social system. Management is a function, not a role.
  • All change is grief. All learning is change. Therefore, all learning has at least the potential for some grief. One (familar) way of thinking is dead or dying; another, largely unfamiliar…is being born. Something is dying while something else is being born.
  • Facilitators of development and transformation in organizations are servants. They serve a group of people in the here and now, in pursuit of the group’s aims. Facilitating this process is about serving other people. Without a heart of service, you have no shot at being helpful in this context.

Where’s The Book Review?

You might have started reading this post looking for a book review. I am not providing one here.

Instead, I offer you an opportunity. SPIRIT is a difficult book to read. Give it a look.

It’s not for everyone. That said, this book unlocked many mysteries for me. The focus on self-organization and the self-organizing universe helped me to understand the nature of both social systems (in general) and the specific dynamics of change in organizations. And so, the opportunity is to give it a serious look if you like what I am saying.

One of the biggest takeaways for me are the dynamics of grief that are evident when change is introduced to an organization, be it a team, department or entire enterprise. The hypothesis that all change produces grief is an extremely powerful and useful idea. If you sit with this concept for a while, you may find yourself questioning the wisdom of your current approach to Agile adoptions.

And so I invite you to examine this book. Will you examine it?

I do believe a careful and thorough reading of SPIRIT is a very leveraged use of time for any serious student of Agile coaching. For practitioners of Open Agile Adoption, a complete and careful reading of this book is required. That’s because the thinking, tools and techniques found in the SPIRIT book are informing the entire Open Agile Adoption approach.

We all want rapid and lasting Agile adoptions. The Open Agile Adoption technique (OAA) can help. The OAA technique is drawing deeply from the book SPIRIT by Harrison Owen. It’s an amazing and even essential book for any person who is serious about achieving a rapid and lasting Agile adoption. In a very real sense the book SPIRIT by Harrison Owen, first published in 1986, is the first (and perhaps the only) book written on how to achieve a rapid and lasting Agile adoption.

I have written this book for friends and colleagues, known and unknown, who find themselves in the midst of a transforming world, and are resolved  to look beneath the surface to the underlying source of change. This source, which has become manifest in the form and structure of our organizations, I call Spirit. – Harrison Owen, Prologue, SPIRIT: Development and Transformation in Organizations. (Circa 1986)

Related Links:

[1] SPIRIT Book: (PDF link)

[2] Open Agile Adoption technique (link)

Back to Open Agile Adoption home

***

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Posted on

Engagement Part 3: Productivity and Human Happiness

Question: How easy is it for you to be truly productive, each day, in your work?

The hypothesis: Productivity is a basic and fundamental source of human happiness.

Very little has been written about the impact of productivity on basic human happiness. Jane McGonigal in her book REALITY IS BROKEN discusses “blissful productivity”. Tony Hsieh in his book DELIVERING HAPPINESS explains that a sense of perceived progress is essential to human happiness. (I refer and build upon the work of these authors in my book, THE CULTURE GAME.)

.

A writer named Wallace Ward (pen name: Frank Wallace) wrote a book in the 1970’s called “The Advanced Concepts of Poker”. In this Appendix of this book he describes poker as a “profitable yet unproductive activity.”

.

He goes on to say:

.

Poker can work against the good player’s self-esteem and happiness no matter how much money he wins since the source of self-esteem and happiness lies in being productive, and poker is a nonproductive activity. Also, in the long run, a person will almost always earn more money by pursuing productive routes rather than nonproductive or destructive routes. [1]
.
.
He goes on to carefully and definitively define what he means by [productivity]:
.

Productivity is defined as adding to the sum total of mankind’s material, intellectual, physiological. psychological, or aesthetic well-being. Humans earn genuine self-esteem and happiness through the pursuit of productive goals. [2]
.
.
.
The Agile way of working is a “productive route”. We can get there faster by using techniques like Open Agile Adoption to engage people in the joyful task of becoming more and more productive.
.
.
.
References
.
[1] Advanced Concepts of Poker, Addendum “Poker Notes” (PDF link)
.
[2] Productivity as defined by Wallace Ward (pen name Frank Wallace) in his book, “Advanced Concepts of Poker”, Addendum “Poker Notes” (PDF link)
Posted on

Open Agile Adoption

What is Open Agile Adoption?

Open Agile Adoption is a technique that can be used by any leader in any organization to help encourage and obtain a more rapid and lasting Agile adoption.

It can also be used by any internal or external Agile coach to facilitate a genuine and lasting adoption.

You can get the full story here: www.OpenAgileAdoption.com

The hypothesis of Open Agile Adoption (OAA) assumes the following:

  • Engagement is the fuel of a rapid and lasting Agile adoption.
  • The use of Open Space Technology is effective in generating high levels of engagement.
  • Creative and independent thinkers do their best work when actively engaged, and will actively disengage when explicit mandates reduce feelings of freedom and autonomy.

There is much more to Open Agile Adoption than the simple use of Open Space to generate engagement. I explained it all at the Global Scrum Gathering keynote on 9/24 in Paris.

.

====================================================

      Videos        Articles       BlogPosts       Training       Downloads

====================================================

.

What follows are some frequently asked questions about Open Agile Adoption:

Q. What is the Open Agile Adoption technique?

A. The basic idea behind the technique is very simple. At the start of an Agile adoption, you plan, execute (and then examine) the experience of conducting an Open Space meeting of at least one day, in which the Open Space meeting theme addresses what the Agile adoption means for the group. Candidate themes might include:

  • What is so great about Agile at CompanyX?
  • What does it mean for CompanyX to be Agile?
  • How can we help each other become Agile at CompanyX?
  • Agility at CompanyX: In Service to What?

The meeting includes a full implementation of the Open Space meeting format, including

  • A theme, formatted as a question;
  • An invitation, distributed broadly throughout the organization, sent well in advance of the meeting, providing adequate time to consider it;
  • A highly authorized Sponsor,
  • A highly skilled & experienced facilitator of Open Space meetings,
  • Opt-in participation, and
  • At least one full day for the meeting. It also includes …
  • Food and beverages all day (every good meeting needs good food!)
  • The rapid generation of full proceedings as described by Harrison Owen in his book on Open Space.
  • Inspection of the results by executives & the sponsor, with immediate action taken regarding areas of concern (such as communication between IT and the business, production support issues that may derail the Agile work, and so on)

(You can learn more about the Open Space meeting format here.)

Q. How is this different from how Agile is typically implemented?

A. Most Agile adoptions simply mandate specific practices. With Open Agile Adoption, the difference is that the people closest to the work (the people that DO the work) are being invited into the process of figuring Agile out, they are being invited to “write the story” of how Agile is implemented in their company. Typical Agile adoptions simply mandate both Agile and specific practices like Scrum. The predictable result is the generation of resentment and not too long after that….disengagement on the part of the people who do the work.

Q. Is mandating Agile a harmful idea?

A. No. Mandating Agile is not a harmful idea. It’s a very useful idea for businesses that face challenges. These business challenges answer the “why Agile” question, and set the context for the conversation…

..However: often, there is no conversation. The common pattern is to not just mandate an Agile direction… but also to mandate the use of specific Agile practices. To define the “how”. Without a conversation!

Mandating practices puts you at serious risk of disengaging the very people who actually do the work! We cannot “mandate collaboration” without creating serious potential for resentment … and disengagement.

The Agile Manifesto says:

Build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done.

Prescriptions and mandates tend to de-motivate and dis-engage people. Prescriptions and mandates associate with reduced feelings of control…and well-being. One way to engage people is to ask them what they think. Engagement is the goal, and Open Agile Adoption is the strategy for obtaining it.

Open Agile Adoption starts with an invitation, not a mandate or a prescription.  Contrary to popular belief, we cannot make people cooperate. We cannot force people to collaborate. What we can do is invite people into the process of writing the story.

And that is what Open Agile Adoption is all about.

Q. Can Open Agile Adoption be used by organizations that already attempted to implement Agile and are struggling to get a good and successful Agile adoption?

A. Yes. Open Agile Adoption is useful for working with troubled Agile implementations. It can help get the culture of the company moving in the direction of genuine and lasting Agility.

Q. Who formulated Open Agile Adoption?

A. The Open Agile Adoption technique was developed over a 3-year period with the willing clients of Daniel Mezick, a professional Agile & executive coach with many Boston-based clients. Daniel is the author of The Culture Game: Tools for the Agile Manager.

Q. Is there more to the Open Agile Adoption story?

A. Yes, there is much more to the story. Open Agile Adoption is a technique that incorporates Open Space Technology in addition to many other essential elements.

Intrigued? You can follow the unfolding story of Open Agile Adoption, by bookmarking this page. There are also presentations planned for the following Agile conference events:

 

You can get the full story here: www.OpenAgileAdoption.com

***

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Posted on

Daily Scrum: A Status Meeting?

is the Daily Scrum a ‘status meeting’? (trick question)

(scroll down for answer…)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

No. The Daily Scrum IS NOT repeat not a (traditional) status meeting…

…I recently fielded this question during a Scrum briefing I did for a client:

Question:

What’s the diff between a Daily Scrum and “status meeting”? The 3 questions sound like “status info”….?

Answer:

The Daily Scrum is not a ‘status meeting’ in the traditional sense of reporting to a person.

In a traditional status meeting, you report your status to a person in a role that has authority- a role like PROJECT MANAGER. A person in a role who is an ‘authority figure’.

FYI: This is a BIG deal!

In the Daily Scrum, you report the 3 questions (arguably status info) to your TEAM. Because the TEAM is the authority in that time in that place, namely: the Daily Scrum. The Daily Scrum is the TEAMs meeting. The Scrum Master (if present at all!) is NOT the boss, a “manager”, or a “project manager”. The Scrum Master is NONE of these things!

TEAM reports to TEAM. TEAM is authority in the Daily Scrum.

A subtle yet profoundly HUGE difference !

Further, the Daily Scrum is not a place to discuss solutions. Is IS THE PLACE to surface and make explicit topics for subsequent discussion. After the Daily Scrum !

If you have further questions, will you please ask me them on Twitter?

Here is my Twitter feed.

I hope this helps!

NOTE: The Scrum Guide is the ultimate authority on Scrum.

Here it is in English.

Here is the Scrum Guide written in various languages.

***

 

 

 

 

 

 

 

 

 

Posted on

Tribal Leadership: Is It a Game?

 

The book TRIBAL LEADERSHIP lays out 5 stages of culture. The 5 stages are basically stories that people tell themselves…and others.

 

 

 

 

Here are the 5 progressive stories:

  • Life Sucks
  • My Life Sucks
  • I’m Great!
  • We’re Great!
  • Life is Great!

What I have come to realize is that the content of this cultural self-talk is related to games.

Games have 4 properties:

  • A goal/set of goals
  • Rules
  • Ways to get feedback on progress
  • Opt in participation (you can opt-out)

My current belief is that the 4th property, “opt in participation”, is an absolutely huge factor. It is highly correlated with levels of joyfulness, satisfaction, feelings of well-being, and overall life quality.

When you are forced to play a game, it is almost never fun.

When you opt-in to play a game, things get interesting!

Here is a summary of what I think is going on with these stories. These five stages of TRIBAL LEADERSHIP are actually stories and related self-talk, and are actually about the ability to make choices, about game structure, and about control, progress, belonging and meaning:

 

TL Stage Your Story The GAME connection
Stage 1 Life sucks! I’m forced to play games I do not want to play and/or do not understand. I have no options. I have absolutely no sense of control.
Stage 2 My Life Sucks! Some people play enjoyable (opt-in) games, but I don’t. I’m forced to play and cannot opt out. I get it, yet I have a low sense of control and almost no sense of progress.
Stage 3 I’m Great! I’ve figured out how to win. Further, I now define MY game, and now you have to play it. You ARE playing it! I’m now in control & now making great progress!
Stage 4 We’re Great! I opt-in to play a bigger, cooperative, goal-seeking game, with others. I now have a sense of belonging.
Stage 5 Life is Great! I opt-in to play a bigger, cooperative goal-seeking game, with others. And this time, we play big and intend to change the world. I now have a sense of higher purpose.

 

Summary

In my book THE CULTURE GAME, I explain the concepts and facilities available to create a good-game structure at work, a game where the enjoyment is so great that the distinction between work and play is minimal.

My current belief is that we are not nearly focused enough on using know-how about game mechanics to debug the problems we face at home, and work and in the wider world.

Culture, as it turns out, is a game.

Jane McGonigal gets it right: Reality IS Broken. And Zappos CEO Tony Hsieh also gets it right in his book, DELIVERING HAPPINESS: we all want to experience a sense of control, a sense of progress, a sense of belonging, and a sense of higher purpose and meaning. Good games deliver substantial happiness. The 5 stages of culture as described in the book TRIBAL LEADERSHIP do appear to confirm this hypothesis.

 

The Relationship to Effective Agile Adoptions

Agile adoptions are typically implemented as a mandate. This is acceptable so long as leadership sets out the clear direction and stops short of mandating specific practices. My current hypothesis, which appears to be valid based on experience, is:

  • Mandates of practices in an Agile adoption amounts to a game without the essential opt-in feature
  • People have needs. The mandate quickly reduces the feelings of control, progress, and belonging that are basic human needs
  • Resentment and disengagement are the natural and predictable results;
  • Disengagement is death to any attempt at a rapid and lasting Agile adoption.

The solution? Check in on what people want, what people think and what people feel BEFORE embarking on the journey of Agile adoption in your company. Open Agile Adoption is one way to do that.

 

Resources

For a deeper dive into these concepts, you might consider taking a look at these resources:

Blog Post: How Games Deliver Happiness And Learning

Blog Post: Open Agile Adoption

Audio Book, absolutely free download: Tribal Leadership by Dave Logan and co-authors

***

 

 

 

 

 

 

 

 

Posted on

The Global Scrum Gathering Keynote: Paris 2013

I am grateful to have been invited into (and have accepted) the opportunity to deliver a plenary (keynote) address at the Global Scrum Gathering in Paris, France. The event runs from September 23-25 and the keynote is scheduled for Tuesday, September 24. I am honored to be part of this event with Henrik Kniberg and Dario Nardi, who also are delivering keynote addresses on Sept 23 and Sept 25 respectively.

You can learn about the 2013 Global Scrum Gathering in Paris here. If you click the [Keynotes] tab and then the right-arrow, you can examine the three keynotes, including the description of my talk.

I also list it here, for your convenience:

Open Agile Adoption 
The Agile journey may be best characterized as a rite of passage. Those who are taking the next step always do so as a group. During the journey, all the participants share the same basic status. Successful participants find themselves in a new and very unfamiliar place. And lastly, anyone who wants to complete the journey must also be willing to leave many things behind.

  • In tribal societies, passage rites from start to finish are facilitated and in fact led, by a “master of ceremonies.” What has changed?
  • Is the modern journey into agile actually a passage rite… for modern tribes?
  • Is the Scrum Master in fact the master of ceremonies in a modern rite of passage for teams and organizations?

In this session, together we explore the surprising answer. We also explore how to specifically leverage Open Space as a tool for helping to create authentic and lasting Agile adoptions.

I plan to explain Open Agile Adoption, an approach to implementing Agile that I have developed over a three-year period during which I have coached inside over 20 organizations. I have coached Agile since late 2007 and began experimenting with new approaches in 2009. At that time I noticed how some very intelligent people became disengaged during Agile adoptions. I began to ask why.

I began experimenting with the use of Open Space to help encourage more engagement, in service to rapid and lasting Agile adoptions. These Open Space experiments  generated some very surprising results. I’m grateful to the many organizations in and around Boston that have allowed me to experiment with sociological approaches to solving the Agile adoption puzzle.

Sociology First, THEN Practices

For my part, I value practices…because sound practices are very important. Yet solid, sound practices implemented with disregard to what people want, what they think and what they feel is, at best, misguided. It tends to generate disengagement.

I have learned the hard way, through experience, that the people who do the work are telling themselves a story. And that story is:

  • I get paid for thinking, and
  • I get paid for solving problems, and
  • I get paid for being creative.

That’s the story. This is one reason why it is essential to value sociological factors: if we mandate specific practices, the thinking and the problem-solving and the creativity that people bring to work is suddenly dampened. Squelched. Discouraged. Even killed off. Further, and more importantly, any sense of control is diminished. A sense of perceived control is essential for any sense of well-being.

Result: The prescription of specific practices becomes a topic for resentment…and eventually, disengagement. In my experience, it doesn’t take too long for people to “check out” on mandates and prescriptions. This disengagement is death to any honest attempt to bring improvement to an organization.

In Paris, I plan to tell you the wider story of Open Agile Adoption. The story includes many interesting people…and more than one courageous leader who took a legitimate shot of greatness with their Agile adoptions. I’ll tell the stories, and present several case studies. I’ll also provide a toolkit, free to the world… that anyone, anywhere can use to repeat the Agile adoption results I am getting.

I hope to see you in Paris. If you cannot attend, you can follow the Open Agile Adoption story on Twitter and here on my blog. As we head into September, I’ll explain more and more about the concepts and facilities of Open Agile Adoption. I’ll also explain the specific components, which are firmly rooted in sociology and cultural anthropology. On September 24 in Paris, I’ll present the actual case data and experience reports, and numerous testimonials on video.

More importantly, on September 24 2013, the date of the Paris keynote, I will make available to you and everyone, worldwide, a free, comprehensive, open-source toolkit for implementing a rapid and lasting Open Agile Adoption.

Frank Zappa, the offbeat musical genius, once said: “Without deviation from the norm, progress is not possible.” I believe he is correct.

I hope you will join me in learning more and more about the details of the Open Agile Adoption technique, incorporating Open Space Technology, as we head into September. You can stay up-to-date on my writing about it by bookmarking this link.

Posted on

July 24 WALTHAM MEETING: Extreme Manufacturing

Scrum is used in all kinds of environments! One of the most exciting examples is Team WikiSpeed, which designed and built a 100 mile per gallon car in just three months. The team accomplished this amazing feat using “Extreme Manufacturing” –  a set of practices that combine Scrum, XP, and modular design to deliver hyper-productivity in a manufacturing environment. This brings the Agile revolution full circle, where agile practices with roots in Toyota that formed the foundation of Scrum are transformed in the software world and injected back into auto manufacturing. Imagine a new car design process where every week the latest design can be driven off the lot!

At this event, Scrum co-creator Jeff Sutherland and WikiSpeed founder Joe Justice will discuss how you can implement test-driven hardware development within Scrum. Get ahead of your competition and learn how WikiSpeed developed component architecture and produced hardware in one week sprints.

Register:

http://www.brownpapertickets.com/event/418614

About The Presenters:

Jeff Sutherland is the co-creator of Scrum and a leading expert on how the framework has evolved to meet the needs of today’s business. The methodology he developed in 1993 and formalized in 1995 with Ken Schwaber has since been adopted by the vast majority of software development companies around the world.

Joe Justice founded and has grown WIKISPEED, a company building 100+ mpg, modular commuter cars using Agile process, to a multinational business in 18+ countries, and now applies Agile methodologies to reduce time-to-value in social good projects such as polio vaccine distribution and low-cost medical centers for developing communities. Joe Justice consults on behalf of SolutionsIQ to realize the benefits of Agile services in non-software-centered verticals such as scientific R&D, oil, entertainment, manufacturing, food service, hospitality, health care, transportation, government, merger management, and education.

Meeting Agenda:

6:30 pm Introduction

7:00 pm Food, beverages, and socializing

7:20 pm Main event

8:20 pm Done

8:30 pm Done Done

Meeting Location:

CORPORATE OFFICE PARK
200 West Street
Waltham, MA 02451

The event room is located on the 1st floor. Enter the building. Take the hallway to the left. Walk past the elevators. The door to the event room will be on your right before the restrooms.

Register:

http://www.brownpapertickets.com/event/418614

 

Posted on

July 25 DOWNTOWN MEETING: Invisible Impediments to Learning – POSTPONED

We’re all aware of the many challenges to learning on agile teams: the length of the release cycle, the clarity of the goal, the ability to learn from failures, and so on. But there’s more. There are things that are in our way every single day that we may not notice or be able to express; some of are even uncomfortable to consider. For example:

  • How does my mindset affect my ability to learn as an individual and to contribute learning to my team and my organization?
  • How does my approach to ownership advance or hinder my ability to help myself and others push through challenges and recover from failure?
  • How does my respect – or lack thereof – for my peers affect my ability to build software?
  • What does it cost me or my team when I miss an agreement? And, just as important, what does it cost when when I fail to confront a missed agreement?

These are some of the invisible impediments to learning that reduce our ability to create great software efficiently.

In this session, you’ll identify these invisible impediments to learning and leave with things you can do right away to accelerate individual, team, and organizational effectiveness.

NOTE: The downtown event is being held at PayPal in Boston. To accommodate security, registration will be closed at 9:00 PM EST on Tue 7/23. Walk-ins will not be allowed to attend. Please be sure to register in advance for this event and bring a photo ID.

Register:

This event has been postponed. There is no downtown event in July.

About The Presenter:

Amr Elssamadisy brings together individual human dynamics, environment and cultural engineering, and agile software development practices to produce immediate and lasting results for his clients.  With a hands-on approach, and infectious can-do attitude, Amr leverages his years of experience (both success and failure) to hold up a mirror to the organization and then guide and teach his clients to make incremental, measurable improvements.

Meeting Agenda:

6:00 pm Introduction

6:30 pm Beverages and socializing

6:50 pm Main event

7:50 pm Done

8:00 pm Done Done

Meeting Location:

PayPal
1 International Place (6th floor)
Boston, MA 02110

Register:

This event has been postponed. There is no downtown event in July.

 

Posted on

No Estimates

There’s a meme getting traction in the Agile community: #NoEstimates [1]. It’s the idea that putting effort into estimating user stories is mostly a waste of time. I agree that, in general, in most cases, estimates are inaccurate.

Especially early in a project, these estimates can be a total wild-ass guess (hereafter “WAG”) and have no basis in reality.

Prominent blog posts that explain and advance the #NoEstimates idea are listed at the end of this post. [4,5,6].

Value, Cost and Risk

Projects are funded and authorized by those who have an interest in value, the cost of obtaining that value, and the risk associated with attempting to obtain that value.

  • The value is the benefit, advantage or other gain that occurs as a result of building a feature, eliminating technical debt, and the like.
  • The cost is the total sum of cash and non-cash payments required to create value.
  • The risk is the possibility of loss of cash and non-cash assets (example: employee morale, employee retention, time, etc) associated with investing time and effort in the creation of value.

Now, for most typical organizations who are new to Agile, it is unlikely that authority will enjoy being told “estimates are a waste of time, so we are not doing them.” The most progressives organizations are already OK with this idea. The problem of course is that 90% of the Agile work going on is going on inside relatively unprogressive organizations, inside orgs that are learning. Selling #NoEstimates is a tough sell in that spot.

Risk

Few if any people in the Agile community discuss risk when discussing value and cost. (Chris Matts, a man who works on trading systems for a living. is one notable exception here [2].)

Regarding risk, the main thing risk managers do in (for example) hedge funds is define the risk [3]. This is usually defined by ‘stops’ that limit loss to a known, predictable number in dollar or percentage terms. Key to getting this number is knowing the cost of the trade. For example if you want to limit risk to not more than $50 and not more than 10% of the trade, the dollar cost of the trade cannot be less than $500. That’s the cost of creating and maintaining the trade. Without knowing the total cost of the trade, it is hard to manage (“limit”) risk in any rational way.

The Larger Concern

The larger concern is the fact that team members gain a substantial amount of team learning via discussions about estimates. During estimation, a given item in a backlog gets discussed, and the team members learn about that work (and each other) as they discuss it. One may say with some certainty that the estimation task is actually a ‘cover story’ for the wider task of team learning. If estimates are 100% eliminated, how is this team learning replaced? Team learning is obviously essential. Discussions during the estimation task create many team-learning moments.

Summary

It’s true that most estimates are waste. It’s rational to believe this, and there are many good blog posts elsewhere that explain “why”. You can examine them by investigating the Twitter hash tag #NoEstimates (see below).

People behave irrationally and of course project sponsors and people who fund these projects are no exception. Many organizations in fact have built up various departments and policies that support and in fact demand information like estimates before a project is funded.

The problems that remain to be solved are:

  • How exactly to explain to project sponsors that the cost component delivered as an estimate is not really valid, and therefore is waste?
  • How to encourage the same level of team learning that takes place during the estimation process?

Most estimates may be waste, but for most coaches and clients, estimates are a necessary fact of life, especially in the early part of any move to Agile.

Related Links:

[1] #NoEstimates Tweets on Twitter

[2] Chris Matts blog (blog posts and links)

[3] Trading Risk: Enhanced Profitability Through Risk Control (book)

[4] Five Reasons You Should Stop Estimating User Stories (blog post link)

[5] Story Points Considered Harmful (blog post link)

[6] #NoEstimates HashTag Explained (blog post link)