This is an excellent series of videos by Lyssa Adkins:
Part One of Two: http://www.youtube.com/watch?v=TvYqhYEaqMs
Part Two of Two: http://www.youtube.com/watch?v=L9tSjpqeBa4
I highly recommend taking the twenty minutes to watch these two videos. Anyone who is a ScrumMaster, a Project Manager or an Agile Coach should take the time!
OpenAgile is similar to Scrum in many respects. Both are systems for delivering value to stakeholders. Both are agile methods. Both are frameworks that deliberately avoid giving all the answers. So why would we choose OpenAgile over Scrum?
The most important difference is in applicability: Scrum is designed to help organizations optimize new software product development, whereas OpenAgile is designed to help anyone learn to deliver value effectively.
OpenAgile is an improvement over Scrum in the following ways:
More effective teamwork and team practices, in particular the Consultative Method of Decision Making, and
applicability over a larger range of team sizes from a single individual on up.
Recognition of the individual capacities required for effective learning, namely Truthfulness, Detachment,
Search, Love and Courage. Scrum acknowledges a separate set of qualities, but does not show how they systematically connect with the requirements of a Scrum environment.
Systematic handling of more types of work beyond just “new artifacts” and “obstacles”. In particular, OpenAgile includes calendar items, repetitive items and quality items and acknowledges their unique qualities in a work
environment. OpenAgile also provides a framework to include additional types of work beyond these five.
Improved role definitions based on extensive experience.
There is only one role defined in OpenAgile (Team Member) vs. three defined in Scrum (Team Member, ScrumMaster, Product Owner).
There are multiple paths of service that allow Team Members and Stakeholders to engage with an OpenAgile team or community in different ways. There are five paths of service: Process Facilitation, Growth Facilitation, Tutoring, Mentoring, and Catalyst.
The Process Facilitator path of service is similar to the ScrumMaster role with the following major differences:
The Growth Facilitator path of service is similar to the Product Owner role with the following major differences:
Integration of principles and practices from other methods. Two examples suffice:
From Crystal: creating a safe work/learning environment.
From Lean: build quality in, value stream mapping, root cause analysis, standard work.
OpenAgile allows interruptions during the Cycle. Scrum has the concept of Sprint Safety. This makes Scrum
unsuitable for operational work and general management.
The distinction between Commitment Velocity and other uses of the term “velocity” used in Scrum. Commitment Velocity is the historical minimum slope of a team’s Cycle burndown charts and determines how much work a team plans in its Engagement Meeting.
Flexibility in the length a Cycle. Scrum requires that Sprints (Cycles) be one month in duration or less.
OpenAgile allows a Cycle to be longer than that and instead provides a guideline that there should be a minimum number of Cycles planned in the time expected to reach the overall goal.
The Progress Meeting in OpenAgile does not require people to take turns or directly answer specific questions.
Avoiding conflict-oriented models of staff and management (Chickens and Pigs in Scrum).
Terminology changes to be more clear in meaning and applicable beyond software. A comparative glossary is
included below.
Another major difference between OpenAgile and Scrum is how the community operates. OpenAgile is an open-source
method that has a specific structure for community involvement that allows for continuous improvement of the system. Scrum is closed. It is closely managed by it’s founders and this has led to challenges with the method becoming dogmatic. OpenAgile is meant to constantly evolve and grow.
Comparative Glossary between OpenAgile and Scrum
| OpenAgile | Scrum |
|---|---|
| Cycle | Sprint |
| Cycle Planning | Sprint Planning and Sprint Review |
| Team Member | Team Member or “Pigs” |
| Process Facilitator | ScrumMaster |
| Growth Facilitator | Product Owner |
| Work Queue | Product Backlog |
| Work Queue Item | Product Backlog Item |
| Cycle Plan | Sprint Backlog |
| Task | Task |
| Work Period | Day |
| Progress Meeting | Daily Scrum |
| Learning Circle w/ steps | “Inspect and Adapt” |
| Delivered Value | Potentially Shippable Software |
| Stakeholders | “Chickens” |
| Five Types of Work:
New, Repetitive, Obstacles, Calendar, |
- no equivalents -
User Stories, N/A, Impediments, N/A, N/A |
| Consultative Decision Making | - no equivalents - |
| Sector / Community | - no equivalents - |
References on OpenAgile:
References on Scrum:
http://www.scrumalliance.org/
http://www.scrum.org/
“Agile Software Development with Scrum” - Schwaber and Beedle
“Agile Project Management with Scrum” - Schwaber
“Scrum and the Enterprise” – Schwaber
Imagine your father is in surgery for a routine tonsillectomy. Something goes wrong with the anesthesia and his heart goes nuts. The defibrillator is brought out, the paddles applied to your father’s chest and the surgeon yells “CLEAR!”. He triggers the defibrillator, but nothing happens, just a small clicking noise. He quickly checks the machine, and everything looks okay. He tries again. “CLEAR!” There’s a small buzzing noise and your father’s body trembles slightly. The surgeon puts the paddles down, and, getting frantic, yells at the nurses to find another defib machine, “NOW!!!”. Thirty agonizing seconds pass. One of the nurses rushes into O.R. with a cart with another defibrillator machine on it. It gets set up. Another fifteen seconds pass. It charges and the surgeon applies it again. “CLEAR!” There’s a huge shock and your father is killed instantly. It takes a few more minutes for him to be officially pronounced dead.
Is this how projects are run in your organization?
If this had been a description of a real event, you would be furious. You would demand that the defibrillators work better – one hundred percent of the time would be about right! You would sue the hospital for buying shoddy defibrillators. You would sue the company that made them. You would sue the surgeon.
Let’s stop running projects this way. Agile is a reliable defibrillator for your organization’s heart.
What motivates human beings to do the right thing? To do good deeds, to be truthful, to be kind, to be helpful, to try to make the world a better place? First of all, we have to realize that everything we say and do has an actual, real effect on our environment for better or for worse. Every time we help someone, or tell the truth, it actually makes the world better in some small way, just as when we lie, cheat, steal or speak unkindly to someone, no matter how small the affront, we actually make the world worse. In fact, our thoughts, words and actions can really have only one of two basic effects on the world – they can make it better or make it worse. Period.
There are some powerful cultural forces in our society, most obviously the constant stream of materialistic propaganda through various forms of hypnotic media, that influence the way we perceive our ability to contribute to the betterment or worsening of our environment. The basic message is that individuals can’t affect any real fundamental change in society (i.e., their environment) and that the best any of us can do is to change our position, rank or class within the permanent structures of our society. Therefore, “only the strong survive”, “get what you can while you can” and the “pursuit of happiness” have become not only slogans that we live by, but conceptions of human nature that have constructed our social reality.
For example, the concept behind “the pursuit of happiness” is that happiness is something external and fixed that a person has to find somewhere “out there”. Embedded in this “right” is the implicit message that “average” individuals and groups do not have the potential to exert influence on, and contribute in any meaningful and lasting way to the shaping of the prevailing social order. Thus, there is always a better neighborhood to live in, a better employer to work for, a better school for your kids to go to, etc. It disempowers us all from thinking that we can get together and do something right now about our immediate reality. ”Don’t even bother”, it says, “you won’t be able to change anything anyways – you’re wasting time, effort, and worst of all – money! Better to lie just a little, cheat just a little, step on your neighbor just a little in order to protect your own little piece of turf.”
Understanding the truth about our reality – our potential to contribute to the betterment of the world – is what will actually begin to motivate us to be good – that is, the fact that our good thoughts, good words, and good actions can and do make the world better. ”Better” becomes not merely an external pursuit that we fight to get our little piece of; rather, it is an organic, sembiotic process of growth. For one thing, it requires vision: What would the world be like, for example, if everyone always tried to tell the truth? Would it really be so bad? Would human affairs come to stand still? Would the economy crumble? Or would it, rather, begin create something new… something better?
I had a fantastic discussion this weekend while on a road trip with my colleague David Parker. We talked about the different aspects of Truthfulness. This is what we came up with.
Honesty
Are you perfectly honest? Is every statement you make factually correct to the best of your knowledge?
Behaviors that are not honest include: hyperbole and exaggeration, sarcasm, falsehoods, omissions.
Honesty is the quality most obviously associated with Truthfulness.
Integrity
When you make a commitment, do you keep it? Are your deeds an accurate reflection of your words and thoughts?
Behaviors that erode integrity include hypocrisy, unreliability, lateness.
Transparency
When someone wants to know something can they find it out from you? Can you provide simple proof of your words and deeds?
Behaviors that prevent transparency include stonewalling, passing the buck, verbal diarrhea, and the use of esoteric or inappropriate jargon.
Serenity
Do you accept that the unexpected is natural? Have you given up trying to control your environment?
Things that block serenity are anxiety and worry, reactionary anger, backstabbing, and manipulation.
Humility
Do you accept that others have wisdom, knowledge and experience that you don’t? Can you admit both the possibility of being wrong, and the fact of being wrong?
There are many things that prevent the development of humility: taking offense from comments about yourself, your ideas or your actions, insisting on your way, vanity, boasting, and even ostentatious self-deprecation.
On April 1, 2009 Scott Ambler posted on his blog “a parody of a very serious ethical lapse within the agile community.” It was an April Fool’s joke – a fake ad for a 2-day agile certification course called “SCUM Certified™ Agile Master, or more colloquially SCAMmer”. The mock-ad states that
We want to be perfectly clear about this, by taking this ‘certification course’ what we’re certifying is that you attended the course. It is your choice (nod nod, wink wink) if you wish to present yourself as a professional SCAMmer. Yes, about 99.8% of course attendees choose to do this, why would you take the course otherwise?
This piece will not be a direct response to Ambler’s joke. That would be…well, rather foolish. Instead, what I intend to address here are the concerns raised by his “Parting Thoughts”, which take on a more serious tone and seem to be getting to the heart of what’s really (and understandably) bothering him.
In his “Parting Thoughts”, he states “I believe we can do much better.” He is referring, of course, to the “ethical lapse” jokingly addressed by his mock-ad. He goes on to say:
My hope is that this joke has made you step back and think about what’s going on around you. Being a “Certified X”, whatever X happens to be, implies that you’ve done something to earn that certification. If you’ve done very little to earn a certification then at best that’s what your certification is worth: very little. If you’re involved in a questionable certification scheme, regardless of whatever justifications that you tell yourself you have still shamed both yourself and your so-called profession. If you turn a blind eye to people who claim to be “certified masters” after doing almost nothing to earn that certification then you too are complicit: As Edmund Burke first said, all that is necessary for the triumph of evil is for good men to do nothing. I invite everyone in the agile community to read Ethics for the Real World and to stand up and show some integrity. Enough is enough.
What Ambler seems to be saying here is that for those of us in the agile community to “do much better”, what we really need is to do something about “questionable certification schemes”. The “something” he proposes is that we should not “turn a blind eye to people who claim to be ‘certified masters’ after doing nothing to earn that certification”. What he then prescribes to all of us in the agile community is to read a book and to “stand up and show some integrity”.
So I decided to take the challenge… sort of. What I mean by “sort of” is that I didn’t read the whole book; rather, I followed the link to amazon.com and read the first chapter entitled “Almost Ethical: Waking Up to Compromise”. I think I got it.
So, let’s say that we can all agree that integrity is a good thing and it would be a good if everyone’s actions were always distinguished by integrity and uprightness. At the same time, let’s assume for the sake of this blog that we can also all agree that we live in a very complex world that constantly presents us with situations that make it very difficult to live up to such a standard. Perhaps we may also all agree that in many of these situations, we often fail to live up to the standards of integrity that we espouse and would like to see established in the world.
In Ethics, Howard and Korver identify that “Lying, a form of deception, plays a central role in ethical compromise” and that lying “appears… commonly in ethical thinking.” They point out that “Most of us are practiced liars.” They offer the results of one study as evidence of this:
147 college students and community members kept daily diaries of lying. The students reported telling an average of two lies per day, the community members one. None thought their lie telling was serious (although none of them asked the people they lied to).
They go on to make the following observations:
If we hold a video camera up to our lives, we may be astonished at the incredible sweep of lies on the landscape. If we pan that camera to view the lives of others, we see disingenuousness everywhere. Imagine being in the shoes of the following people, whose stories are based on real events:
Whether or not you’ve ever been in these situations, you no doubt have been in similar ones. Every time, you have probably had at least one very good reason to compromise – and at times you did. You lied. You may feel uneasy about it. You may even be haunted by it.
But you shouldn’t feel alone. Using compromise as a helping hand in life has a storied, if seamy, tradition. Even revered leaders lie routinely…
No doubt, subsequent chapters of this book offer helpful advice about how to overcome the temptations to lie that so many of us so often find ourselves feeling. What I would like to point out, though, is Howard’s and Krover’s insight that lying “has a storied, if seamy, tradition.” In other words, lying has become an ingrained, normal and expected habit of our culture. Temptation is one thing, but breaking out of a culture of lying requires a sea change in human morals, standards and codes of conduct.
Now that the immensity of what we’re actually dealing with when we start talking about “integrity” has become more clear – i.e. integrity is a really hard thing to figure out in a complex world that is really messed up – what can we actually do about it? In other words, is it futile to try to be a person of integrity in a corrupt world? The short answer to this question is, unfortunately, “No”. Just like you cannot be a just person in an unjust world. A brief example will illustrate this fact: It is almost impossible for any one person living in North America to be able to guarantee that not one article of clothing that they own was manufactured in a sweat shop or by child laborers. Indeed, most of us can agree that sweat shops and child labor are examples of flagrant injustice. By participating in an economy that feeds off of their existence, i.e. paying for goods manufactured under such conditions, we are investing in the system that perpetuates the oppression and exploitation of the people whose survival depends on that system.
Being a person of integrity is equally elusive to being a person of justice. In order to survive in the jungle, you have to obey the laws of the jungle. So what is the solution? What can we actually do? Is it a hopeless situation, this reality of ours?
Indeed, it is not enough for people to just “be good”. We must also all strive to transform the social environment, structures and institutions that we are a part of in our daily lives. In other words, it is not enough to be a “good” person who attacks everything that one perceives as being “bad”. You can’t just decide that you are going to be civilized in the jungle and complain about all the things that are going to eat you and hope to survive. You also have to contribute to building the civilization that will replace it, contribute to cultivating a new garden. You will need to find like-minded individuals and work shoulder to shoulder with them and learn to overlook all of their many shortcomings as they learn to overlook yours.
There is another good book that I’ve been reading: Beyond the Culture of Contest by Michael Karlberg, Associate Professor in the Department of Communication at Western Washington University, whose research and writing focus on the relationship between communication, culture and conflict. Here is how Karlberg opens his book:
We live in a culture of contest. In western-liberal societies our economic, political and legal systems, as well as many of our other social institutions and practices, are competitive and conflictual. Surrounding this culture is a culture of protest. In response to the social and ecological problems engendered by our culture of contest, we engage in protests, demonstrations, acts of civil disobedience, partisan organizing, litigation, strikes and other oppositional strategies of social advocacy and change.
These competitive and conflictual norms have become so ubiquitous that they appear natural and inevitable to many people. Indeed, conventional wisdom suggests that these social norms are an inevitable expression of an essentially selfish and aggressive human nature. The prevailing social order, according to this logic, is an inevitable reflection of human nature. But is a culture of contest and protest really an inevitable reflection of human nature? Or is it possible that human beings have the developmental potential for either adversarial or mutualistic behaviour? Is it possible that human culture, rather than human nature, determines which of these potentials is more fully expressed? Is it possible that the prevailing culture of contest and protest cultivates the former rather than the latter? And if so, what are the implications?
It seems that by taking Ambler up on his challenge, that is, in trying to figure out how to “stand up and show some integrity”, some initial conclusions can be drawn:
I hope that everyone who reads this finds it to be an attractive invitation to participate in a mutualistic discourse on how we in the agile community can find ways we can work together to contribute to building a better world – a world characterized by integrity, uprightness, justice, truthfulness, prosperity and joy.
The first day of the Scrum Gathering in Orlando is finished. I had a great day all-in-all. I went to 3 and a half sessions, took a nice sun break in the afternoon, and then mingled at the evening reception.
Some observations:
More People Using Agile and Scrum for Non-Software
This was interesting. When I actually spent time talking with people I heard several times that people were using agile approaches in non-software environments. One person is working with an oil company to apply agile methods to all project work. Another two people are extending agile / Scrum into marketing departments. And one other person was applying agile into the whole organization.
Of course, with OpenAgile, I’m very interested in all this. I’m hoping that I can organize some sort of group / institute / organization for people using agile methods outside of software development. If you’re interested, please contact me on LinkedIn or Facebook or any other method you wish. People seemed to be in general agreement that this is still new stuff, and that they are having to make adaptations to make agile work in these other environments. After all, not all work is purely creative or problem-solving!
Economic and Recession Fears
Gregory Balestrero gave a talk about the relationship between the PMI and the Scrum Alliance. I felt that his talk was much more 30000 foot level and that it probably wasn’t quite right for the audience. The questions people asked at the end seemed much more appropriate for someone who was an author of the PMBoK rather than the CEO of the PMI. There was a mis-match between presenter and audience. At any rate, Gregory spoke quite a bit about the economy and the fears people have about it. He emphasized that this time actually represents a real opportunity for organizations to get better at doing projects by focusing on value. I couldn’t agree more!
As well, in my discussions with several other individuals who are coaches or run agile coaching businesses, I heard quite frequently that the past few months have been hard on business here in the United States. One company has actually laid off some coaches. This is in line with our experience at Berteig Consulting… up to a point. December and January were slow, and in fact slower than “normal”, but we still did very well in the Dec. to Feb. quarter. Clearly the Canadian market is still moving well, and there is a recognition that agile and Scrum are a means to help organizations get through these tough times.
One a related note, the resort we are staying in and in which the conference is being held is the Gaylord Palms. Apparently, bookings are way down at the hotel to the point where they have temporarily closed some of the restaurants in the resort. Likewise, when my family went to a water park during the day today, some of the rides were closed because there were so few people. Please remember: this is Spring Break!!! Clearly tourism is _way_ down.
Reconnecting with Friends and Collegues
I’ve met up with (in no particular order): Tobias Mayer, Alistair Cockburn, Catherine Louis (from Nortel), Sanjiv Augustine, Mike Vizdos, Carole Marks, Mitch Lacey, Jim Cundiff, Gabby Benefield, and probably others that I can’t remember.
I also met for the first time several people. I hope I can keep in touch with everyone!
Highlight of the Day
Mike Cohn gave a presentation on Leading Self-Organizing Teams. It was fantastic. My favorite part of it was his introducing the CDE (Containers, Differences and transforming Exchanges) model. In this model, self-organization is positively influenced by appropriate constraints on the containers, differences and transforming exchanges among the people who are asked to self-organize. To explain: containers define in-ness vs. out-ness for participation, scope of work, environment of the group that is self-organizing. Differences are the variations in the skills, qualities, attitudes, knowledge etc. of group members. And transforming exchanges are the interactions between group members both amongst each other and with outside groups, where such interactions cause a transformation of some sort: creation of value, sharing of knowledge, new activities, etc.
By using the CDE model, we can diagnose challenges facing an agile team. Mike Cohn included a number of scenarios for us to use to practice the application of this model.
Looking Forward to Day 2
Hopefully Day 2, which is primarily and Open Space event, will be even more interesting that Day 1. I will continue to post frequent articles about the events of the day! Please feel free to ask for more details in the comments… or to suggest that I connect with someone, or to bring up a topic for the Open Space portion.
Two very interesting videos. The first, a presentation by Rod Jeffries, goes through a treatment of “Lateral Violence”. The second is three role-play scenarios to demonstrate the concepts. Both of these videos are in the context of nursing in hospitals… however, it takes little imagination to see how they apply in other environments. I would actually assert that the problems described in these videos are endemic to most organizations.
Alistair Cockburn has also written about safety in a team context.
Scrum and other agile methods all have some mechanisms for dealing with this sort of challenge, but they can start failing quickly if the sponsors of the agile effort do not overcome the habitual and cultural challengs.
“Without changing our patterns of thought, we will not be able to solve the problems that we created with our current patterns of thought.” -Albert Einstein
“We are what we repeatedly do. Excellence, then, is not an act, but habit.” -Aristotle
Among leading Agile thinkers, coaches, trainers and practitioners there is a rich, ongoing discourse around a subtly deceptive concept – the concept of the Definition of Done. Within this discourse, a singular constant challenge is emerging: old patterns of thought.
For example, there is an old pattern of thought that tells managers of software companies that at least some part of the Definition of Done must be imposed on teams in order to protect a universal standard. Rationalizing this antiquated thought pattern seems to have become a rigorous intellectual discipline in and of itself. One of the most prevalent excuses to which many managers have invested a great amount of mental and emotional energy seems to be around the challenging concept of multiple Agile teams working together on the same project (or product). Surely, in such cases there needs to be some kind of imposed standard that all teams need to comply with in order to avoid chaos in the main build, yes? In fact, this is the exact wrong approach to take.
We also seem to become confused at times by our own limited understanding of the words that we use when attempting to talk about things we are or are not trying and learning to do. The more we learn about doing something, the more we are able to talk about it in practical terms. Since theoretical discussions around semantics rarely result in appreciably improved behavior/results, we will endeavor here to address this subject with both brevity and caution.
Our old patterns of thought make understanding many words, including the word definition and the word done, problematic. We tend to think of these words as implying static, rigid, absolute conditions; for example, the way we tend to think of the word definition in terms of the definitions of words. We like to think that those definitions are relatively stable. Indeed, there are some real benefits to this. We can have conversations with people and assume that for the most part their understanding of the definitions of the words we are using are similar to our own. But even with words, there can be more than one definition, which already makes the definitions of words less static than they often seem. At some level, one might even ask – who actually decides on the definitions of words? Is there an actual authority out there (not merely the self-proclaimed “official” authorities) that decides on definitions and hands them down to us? Some may say “yes, indeed, namely the authoritative texts of the world’s religions,” for example. On the other hand one could also say that the definitions of words have evolved through the ages (just as languages have) as humanity has received progressively more complex guidance from religious texts according to its evolving capacity (compare, say, the Bhagavad Gita to the Quran). But that is another conversation. What is important to acknowledge here is that the meanings of words expand and evolve over time given the capacity of the individuals who use them to develop new patterns of thought and that the energy required to do so is tremendous, even epochal.
An old pattern of thought construct around the word done is equally problematic. A conversation limited by a rigid understanding of the concept of what done means, is and looks like can quickly take us spinning off into the stratosphere of “nothing is ever done.” When there is a lack of trust and respect among people, as is generally the case in our society, and since ownership and ego are often entangled with limited and rigid understand, we then find ourselves in situations in which the limited and rigid understanding of a few with arbitrary power and authority take precedence over the understanding of others. In other words, people in authority are expected to solve every problem and people that do work are expected to be robots. Both are set up by this arrangement to fail.
Indeed, there is a real problem in trying to talk about things that we do not do, or that we do not sincerely try to do. True learning, on the other hand, consists in people striving to be truthful and sincere working together engagement in a continuous cycle of action, reflection and consultation. Learning also requires us to be truthful – if we think we have all the answers, learning becomes extremely difficult, if not impossible. If we are not at least trying to learn to define what “done” is to us, we will never be able to actually talk about it in a knowledgeable and meaningful way. Furthermore, it will likewise be impossible for us to help anyone else learn to understand their own Definition of Done if we haven’t learned through real experience about how to understand our own.
As we engage in a real learning process, through action, reflection and consultation, new patterns of thought begin to emerge and perhaps even crystallize. These emerging new patterns help us to bring concepts out of the stratosphere of semantics, rhetoric and theory back down to earth where we can actually act and reflect on them in order to implement creative new solutions to the problems of our world.
In her Agile 2007 presentation The Role of Leadership in Software Development (http://www.infoq.com/presentations/poppendieck-agile-leadership), Mary Poppendieck offers powerful insights into the history of patterns of thought around leadership and the emergence of Agile thinking out of the wisdom of Lean Manufacturing.
As with all Agile methods, Scrum is a framework for learning in which new patterns of thought that began to crystallize in Lean Manufacturing practices have been adapted and applied to software development practices. It then follows that the Definition of Done in Scrum is consistent with a specific Lean Manufacturing practice, namely Standard Work.
In his book Workplace Management, Taiichi Ohno, the father of Lean Manufacturing, defines Standard Work as such:
“There is something called standard work, but standards should be changed constantly. Instead, if you think of the standard as the best you can do, it’s all over. The standard work is only a baseline for doing further kaizen [change for the better]. It is kai-aku [change for the worse] if things get worse than now, and it is kaizen if things get better than now. Standards are set arbitrarily by humans, so how can they not change?
“You should not create these away from the job. See what is happening on the gemba [shop floor] and write it down.”
Based on the assertions of the previous two paragraphs, we must conclude that just as standards should be changed constantly in Standard Work, so too should definitions change constantly in the Definition of Done.
How, then, does our work benefit from a Definition of Done that is always changing? This is a deceptively simple question, as it is an example of a problem posed by old patterns of thought that can only be solved by new patterns of thought. In order for the old patterns of thought thinker to be helped to form new patterns of thought, he must be accompanied by the new patterns of thought thinker to develop the capability to adopt new patterns of thought. In other words, in order to really learn, people need to be accompanied by those who have more experience. Such an exercise is far beyond the scope of any article and requires a completely different venue – namely the coaching relationship. More about capacity-building and accompaniment later.
For now, suffice it to say that the point of having a Definition of Done that is always changing is to allow for kaizen – the Definition of Done, therefore, like Standard Work, is only a baseline from which we constantly change for the better. In other words, the Definition of Done is the record of what we are actually doing now. It allows us to be absolutely confident that we know as much as possilbe about what we are actual doing now so that we can make real, concrete, and confident decisions about actual improvements to our work.
Actually doing the Definition of Done, as Ohno tells us is simple: “See what is happening on the gemba [shop floor] and write it down.” For many of us though, this simplicity is deceptive in that it is actually often very difficult – both the seeing and the writing.
The ability to see what is actually going on is clearly vital to the capability of defining done. It is valuable, therefore, to examine more closely the sense of sight:
We have physical eyes that see. What do our eyes see? Light. Is this what Ohno is talking about when he says “see what’s going on” – literally seeing light – or is he talking about a different kind of sight? Clearly, what he is talking about is what we might call true sight, or the ability to see the truth. We can think of truth, therefore as being like light.
Is it our physical sight that sees the light of truth? This, of course, is impossible since our physical eyes only see physical light. So what is the sense in us that allows us to see the light of truth – in other words, what is true sight? Some may say that it is our sense of justice. One must have a strong, developed sense of justice in order perceive truth, especially in environments like software development in which the truth can be easily hidden.
Writing down the Definition of Done with accuracy and clarity requires us to be both truthful and precise. This is very difficult to do well in our present environments of opacity, defined roles, command and control management, fear of failure and general distrust.
Clearly, we can see now that the Definition of Done, challenging to understand in its subtlety as a concept, is far more difficult to apply effectively in reality and therefore fully realize its value in practice.
The concept that allows for the value of the Definition of Done to be realized is the concept of expanding the Definition of Done. Expanding the Definition of Done in Scrum and Agile is the equivalent of kaizen in Lean Manufacturing. In order to expand the Definition of Done, the actual Definition of Done needs to be well understood. In other words, “Where there is no Standard there can be no Kaizen.”
Ohno says:
“When creating Standard Work, it will be difficult to establish a standard if you are trying to achieve ‘the best way.’ This is a big mistake. Document exactly what you are doing now. If you make it better than it is now, it is kaizen. If not, and you establish the best possible way, the motivation for kaizen will be gone.”
This brings us back to the initial problem created by our old patterns of thought around our understanding of the Definition of Done – namely the misconception that at least some of the Definition of Done must be dictated by management in order to have consistency across teams working on the same large project. The solution to this problem is challenging yet simple: It’s irrelevant. An organization is a living, breathing entity. When management makes room for kaizen by not dictating standards, kaizen has more power to pollinate the entire organization and transform the way people think and work than imposed standards could ever begin to hope for. Dictating standards, in other words, is limiting while kaizen harnesses the creativity of all.
Again, Ohno says:
“We need to use the words ‘you [the worker] made [the standard]’ as in ‘follow the decisions you made,’ When we say ‘they were made’ [for you] people feel like it was forced upon them. When a decision is made, we need to ask who made the decision. Since you also have the authority to decide, if you decide, you must at least follow your decision, and then this will not be forced upon you at all.
“But in the beginning, you must perform the Standard Work, and as you do, you should find things you don’t like, and you will think of one kaizen idea after another. Then you should implement these ideas right away, and make this the new standard.”
Changing our patterns of thought requires creativity, but who’s creativity?
Ohno:
“Years ago, I made them hang the standard work documents on the shop floor. After a year I said to a team leader, ‘The color of the paper has changed, which means you have been doing it the same way, so you have been a salary thief for the last year.’ I said ‘What do you come to work to do each day? If you are observing every day you ought to be finding things you don’t like, and rewriting the standard immediately. Even if the document hanging there is from last month, this is wrong.’
“At Toyota in the beginning we had the team leaders write down the dates on the standard work sheets when they hung them. This gave me a good reason to scold the team leaders, saying ‘Have you been goofing off all month?’
“If it takes one or two months to create these documents, this is nonsense.”
People on the shop floor or the Scrum teams need to be given the freedom and authority to figure out how to do their work better and change the standards of their work as they learn. Ohno was really first and foremost a master coach who knew how to accompany people to develop their capabilities to perceive truth and generate and apply their own knowledge and creative solutions to challenging problems.
Gary Hamel, in his article “Management Innovation” in the February 2006 edition of the Harvard Business Review, wrote:
“Only after American carmakers had exhausted every other explanation for Toyota’s success- an undervalued yen, a docile workforce, Japanese culture, superior automation- were they finally able to admit that Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.”
In Scrum, the Team itself defines Done by what it actually gets done. The ScrumMaster removes obstacles so that the Team can expand its Definition of Done (kaizen). Scrum assumes that all Team members are dedicated to expanding the Team’s Definition of Done from Sprint to Sprint and that the Team will achieve this as long as organizational obstacles (such as managerial control fetish) are not impeding it from doing so. When a Team is empowered in this way to expand its own Definition of Done (as well as empowered in other ways, according to the rules of Scrum), it will have the space it needs in order to grow into a hyper-productive Team. That is to say that no one outside of the Team (i.e. management) dictates any part of the Team’s Definition of Done (a common management practice that results in kai-aku). The Definition of Done is one ingredient in the remedy for curing our culture’s leadership disease – the failure to learn.
“…your failure is an internal disease…You firmly believe that sound management means executives on the one side and workers on the other, on the one side men who think and on the other side men who only work.” -Konusuke Matsushita
(Shameless Plug: we offer excellent Certified ScrumMaster Training and in it we discuss the Definition of “Done” in the context of people’s actual problems.)
In Scrum, there is a concept of the “Definition of ‘Done’” that is used to understand what teams produce every Sprint. Unfortunately, it is not well understood, nor is it consistently applied. Part of the problem is that the name of the concept is misleading. Every time we do coaching or training in organizations, we spend an inordinate amount of time getting this concept across clearly. Recently, one of our coaches, Travis Birch, had an insight about the name of the concept. The word “definition” makes us think of something static and permanent. Definitions don’t normally change. However, in Scrum, the definition of “done” is always changing. Doneness is not something that we get perfect at the start, rather, teams develop their capacity to deliver more and more each Sprint… and not just in terms of features. As I explained in another article called Four Methods of Perfecting Agile, the definition of “done” is something that can and should grow over time.
So what can we do? Can we rename the concept? The concept is really a snapshot description of the activities and attributes that a team puts into a Sprint’s worth of work. For example, at first a team might not be writing automated unit tests. Therefore, automated unit tests are not part of the definition of “done” – a snapshot of their work at the end of the Sprint does not include automated unit tests. Then in a retrospective the team decides that they need to create automated unit tests. They do so in the next Sprint. Now, automated unit tests are a part of the definition of “done”. Finally, a few Sprints later, one of the members of the team attends Agile Software Engineering Practices training [shameless plug] and decides that they should start doing test-driven development. The team learns how to do this and from now on the definition of “done” includes test-driving all production code.
<strong>A New Name</strong>
Let’s try another name for this concept: the “Expanding Benchmark”. I think this term much more accurately conveys the sense of the concept. It is expected that this concept is not static, rather, as the team overcomes obstacles, automates things, learns new skills, and gains new trust and authority, that their work will expand. And specifically, we are expanding the benchmark of what activities and attributes of software are delivered at the end of each Sprint.
So – let’s get rid of the Definition of “Done” and start talking about a team’s Expanding Benchmark. What sayest you?
I’m currently doing some coaching work with Regina, a new project manager working with a small team of web developers at a community development organization in Toronto. We had our first session last week. Regina was having trouble getting started on a particular project and I shared with her some of the Agile methods of creating a prioritized Cycle Plan, breaking it down into small tasks, etc.
Regina seems to be finding Agile methods helpful in general, but there was a special kind of interaction that we had around removing an obstacle that was particularly interesting for me. It had to do with an email she received from Peter, a developer working on one of the websites she’s managing. Regina shared a concern that she didn’t know some of the technical terms Peter was using. So I had her read through the email and form questions around the points she wasn’t clear about – i.e., “what are buttons?” and I wrote them down as she was speaking.
I then suggested that she compose a reply email containing the same set of questions. Regina’s eyes opened wide and she exclaimed, “Oh yeah – that’s so obvious!” I went on to mention that another option would be to go and do some research on her own but that there were some valuable advantages in asking Peter directly, particularly in terms of team-building, that may not be as immediately apparent as asking the questions solely for the purpose of having them answered. Here are a few:
First, it’s a way forRegina to remind Peter that she does not have a technical background and that he should not assume that she is familiar with web-lingo. Second, it also reminds him that she is a different person from the last manager he was working with and subtly reinforces that it’s important that they get to know each other as two individual human beings and learn to work together effectively. Third, and perhaps most importantly, it gives Peter an opportunity to help someone else on the team learn something new, and by doing so, contribute to the culture of learning on the team. Fourth, and perhaps most obviously, it promotes open lines of clear communication on the team.
(Of course, if the team was colocated, which it is not, lack of communication would be much less of an obstacle!)
Asking questions in the interest of learning makes it visible to others that you don’t know everything. For some people, this presents a dilemma. What makes it a dilemma is that asking meaningful questions is something that many people aren’t able to do well. The ability to ask meaningful questions is a learnable skill requiring the capabilities of truthfulness, humility and courage. Such capabilities – let’s call them moral capabilities – can themselves be developed through conscious, focused effort.
Someone in the position of a newly hired manager, or a veteran manager with a new team, who lacks these capabilities may feel that it is important to present to a team a persona of all-knowingness. But, of course, this is false and the truth of one’s degree of knowledge and capability, or lack thereof, soon becomes apparent anyway. Clearly, this person needs to do some honest hard work to develop some humility, but truthfulness and courage are still often major factors.
Or maybe you’re the kind of person (like Regina) who just doesn’t want to bother anyone. In this case, humility is not necessarily lacking, but truthfulness – and perhaps most of all courage – may need some attention. Concepts around moral capabilities deserve much more elaboration, but for the sake of brevity, I’ll leave it at that.
To sum it up, if you are open and clear in the way you ask questions, people will tend to appreciate it and will trust you more in the end. Moreover, it can have a transformative effect on the environment of the team. When your team members realize that you are not afraid to ask questions and be truthful about your lack of knowledge in a certain area, it will encourage them to be more truthful about their own capabilities. Not to mention that most people feel good when they are able to help others. When your team members feel safe to ask for help and free to help each other, it is empowering for everyone.
Asking meaningful questions, therefore, is an essential aspect of learning together, and nothing is a more powerful contributor to the success of an organization than a team that learns as a team.
Okay, global markets are in turmoil. Consumer spending is dropping. Economists are forecasting recessions or extremely small growth. Businesses are adjusting revenue and earnings forecasts. Bad news all around.
Actually, no. This is the perfect time to be in business. This time of crisis can actually be the opportunity that your business desperately needed, you just didn’t know it.
The way to get through this is simple: focus on value, remove waste and obstacles. The trouble is, simple though this sounds, it’s actually very hard for many businesses. Why? Because one of the first responses to financial crisis is to cut costs, and the easiest, most obvious cost in most businesses is staff. Cutting staff is not the same as focusing on value and removing waste and obstacles. In fact, cutting staff is almost the exact wrong thing to do. Why? Because you still leave in place all the old policies, procedures, checkpoints, systems, role definitions, chokepoints, logjams and wasteful activities that were hidden because we were riding through “good times”.
It’s true, of course, that staff are a substantial cost for most businesses. However, we sometimes lose sight of the fact that in any business where staff is a substantial cost, it also probably means that staff are responsible for a large proportion of the value your business generates. Cutting staff therefore means reducing value, and that just puts your business into a vicious cycle. Cut staff, deliver less value, customers and clients don’t get as much value, they start looking elsewhere, you get more revenue pressure, you cut more staff, etc. Not only that, but if you cut staff, but leave the bureaucracy in place, then the ratio of bureaucratic overhead to staff is increased leading to even worse productivity!
Okay, so where does agile fit in? Simple: agile methods such as Scrum for software work and OpenAgile for business management are designed to help you find waste, remove it, focus on value, learn from both successess and mistakes, and do better next time all in very short cycles which allow you and your business and your teams to adapt to changing (market, economic, competitive) conditions very quickly, always delivering the highest value fastest and at the best price.
Recent case studies in the Scrum community are showing revenue gains of 200 to 400 percent in less than a year for companies that are rigorously adopting Scrum, not as a “solution” or a “methodology” but as a powerful, principle-based, learning framework applied universally. Scrum and other agile methods, when used properly, cause substantial, deep changes in an organization’s culture and habits. These changes all center around the idea of delivering high value, high quality, quickly, and always getting better and better and better at doing this.
Teams using agile methods become super-teams. Organizations using agile methods become super-organizations.
Feeling the fear of recession? Feeling the need to cut costs? Anxious if your job, your team or your business is going to survive this crisis? Use agile – Scrum, OpenAgile, Extreme Programming, Lean Software Development, Crystal – to not just survive the crisis, but to thrive while your competition struggles and succumbs to the challenges.
Some Other Reasons Agile is Good in a Recession:
“customers will start asking about iterative deliveries (to control spendings(sic))” – (agilerevolution.net)
“Agile can drastically improve time to benefits, quality and efficiency, team morale, the relationship between IT and business staff, and responsiveness to change.” – (thoughtworks.com – PDF)
The word “Agile” refers to a type of method for getting work done. It’s all about doing valuable work with speed and quality. An Agile team delivers finished work frequently while working at a sustainable pace. Agile process consists of short iterations of work that deliver small increments of potentially shippable customer value. Frequent delivery ensures visibility of the work of the team, as well as its needs and obstacles, to all stakeholders.
Agile refers to a discipline defined as the middle way of excellence between chaos and bureaucracy. Agile also refers to the philosophy that humans do work in a complex world.
Although Agile has emerged out of endemic crisis in the software development sector (but not exclusive to it!) – mainly caused by the pressure built up from the strata of systemic dishonesty and distrust – it is not a software development process methodology. Rather, it is a system of learning that challenges deep cultural assumptions and catalyzes change in an organization.
Agile methods are made of processes, principles and tools. But most importantly they are concerned with people. Therefore, Truthfulness is the foundation of success in an Agile organization.
Although Agile cannot force people to be truthful, it reveals the direct consequences of opacity in an organization, confronts it and challenges it to change.
Agile prioritizes by value, not “dependency”. In fact, Agile teams are expected to break dependencies and are empowered by such challenges. Agile teams self-organize their own work - they are not “managed resources”. Agile is team-focused rather than project-focused. Agile responds to evolving requirements and avoids frozen requirements. In an Agile environment change is embraced as natural and healthy, rather than as something “risky” to be avoided.
In short, Agile is about overcoming fear, both on the part of individuals as well as collectively and culturally on the part of organizations.
As with any sincere effort to overcome habitual fear, Agile work is hard work. Becoming Agile can be an uncomfortable, confusing and frustrating process and can remain that way for a long time.
Agile is the art of the possible. It’s methods are idealistic, not dogmatic. Agile is about learning, adapting and striving for the ideal. Agile is based in reality – it relies on everyone to be truthful about the possible and to contribute honestly towards customer value.
Therefore, Agile requires a constructive and positive attitude. In an Agile environment, a state of crisis is an embraced opportunity to learn and improve.
An Agile team is empowered by its responsibility to self-organize. On an Agile team, people work together towards a common goal and coordinate their work amongst themselves. There are no managers or bosses on Agile teams. Correspondingly, no member of an Agile team reports to a boss or a manager. All team members report to the team. While working on a team, everyone checks their institutional titles, roles and responsibilities at the door. All members of an Agile team are responsible for one thing: contributing as much customer value as possible to the work of the team.
Agile exposes the true character of an organization’s culture and forces visibility on all levels.
At Berteig Consulting, we practice Agile. I am currently working in the role of Process Facilitator for our core team of 4. We work in 1-week iterations. As a couple of the team members have a 4-day work week, we have our Retrospective on Monday mornings at 10 AM, followed by the Planning Meeting for our next iteration at 11 AM. The remaining work days begin with a daily stand-up meeting using the reporting methods of the Daily Scrum (each member reports 3 things to the team – “What I did yesterday”, What I’m doing today”, and “What are my obstacles”). We work in a collocated team room, with product backlog items, iteration backlog tasks, obstacles, definition of done and a burn-down chart all up on the walls. We are currently in our fourth iteration of our current project (which, in this case, is the business itself!). As part of our retrospectives, team members actually demo finished work – i.e., Mishkin shows us some of the great changes he’s made to his course materials and Paul demos the latest edition of our beautiful newsletter (the one you’re reading right now!). Laila has even demoed some travel tools that she’s been working on for the coaches and trainers. We also decided to each write our reflections in order to share them with those who might find it useful as a way of wrapping up the retrospective for this iteration.
Agile can be implemented anywhere people do work together. Visibility of work, openness of consultation and a strong collaborative spirit feeds an overall feeling of excitement and optimism on an Agile team. Clear goals based on small pieces of prioritized value and sustainability of work ensure quality and speed of productivity. But of course, in order for a team to build up these capabilities, it must establish, maintain and defend a firm and immovable foundation of truthfulness.
Bob C. Martin (Uncle Bob to you and me) suggested, in his “quintessence” keynote at the Agile2008 conference that he had the perfect metric for code quality. Cyclomatic complexity and others were interesting mostly to those who invented them, etc. His answer was brilliant, and was easily measured during code reviews:
WTFs per minute
I love it. All you need is a counter and a stop-watch. Start code-review and start watch and start clicking anytime you see code that makes you say or think “What the F???”. This dovetails nicely with his original recommendation for a new statement in the agile manifesto: “Craftsmanship over Crap”.
One of the challenges with agile methods is to get a clear perspective on how to measure process improvements. I recently had a brief discussion with a C-level executive at a small organization about this. His concern was that cycle time was meaningless because it depended so much upon the size of the work package. So how do we use cycle time as a meaningful measurement? What else can we use to measure process improvement?
Let’s look at the difference in measuring cycle time in an agile vs. non-agile environment. Then we’ll get to other measurements.
First, let’s define cycle time. From iSixSigma we have:
Cycle time is the total time from the beginning to the end of your process, as defined by you and your customer. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.
This definition is important because it gives us a clue about the potential difference between a waterfall vs. agile method of delivering value. Let’s imagine the typical process used in a waterfall environment. The following are the high-level steps:
So from the start of the customer request formally submitted to the time that the fulfillment of that request is made is our true cycle time. There are a few important things to note here. First, there is a queue of work based on requests made but not yet scheduled. There is another queue for work scheduled but not yet started. We know that if we can reduce the size of these queues, we can improve cycle time in a general sense. Second, we know that most organizations of any significant size will have different queues based on the urgency of the request. For example, a high severity bug discovered in the production system of a company’s largest client will be treated differently than a wish list item for a small not-yet-client. These two requests won’t even go in the same queue: the high priority problem will be quickly escalated to a support or development team that can work on it immediately. Third, it is tempting for the development group to measure their local cycle time. This is a Really Bad Idea since it leads to sub-optimizing behaviors. For example, it is easy for the development team to improve their cycle time by sacrificing quality… but this just causes the QA cycle time to increase, and probably the overall cycle time (true cycle time) is affected more than the local improvement in the development group’s cycle time.
Now let’s look at the steps that occur in an ideal agile environment:
So the ideal method of doing agile has a maximum cycle time of two months to deliver from the time a request is made… how many teams are doing this? Not many.
The ideal is extremely difficult to accomplish. Getting to that state requires that the development organization catches up to the business side so that there are zero pending requests at the start of each iteration. It also requires that the business side users and stakeholders are able to articulate their requests so that they are small, and appropriately detailed for the team doing the work.
A realistic agile implementation actually is a lot more messy. Depending on the type of request, the cycle time for a piece of work can vary widely. Some low priority items may take years even in an agile environment. A low priority request is made and approved but then never quite makes it into a project… and then once in a project never quite makes it to the top of the team’s product backlog. This is interesting to look at sometimes, but it points out another important aspect of measuring cycle time: mostly we care about average cycle time (or some other statistically interesting aggregate measure).
The predominant factor in most organizations’ cycle time is the number and size of the queues they use as work is processed. In most organizations there are several queues and most of them contain large numbers of requests or bits of work in process. Queues represent huge amounts of waste. It is easy to see that queue size and cycle time are closely related: the more items in a queue, the longer the cycle time.
This leads to a simple conclusion: regardless of lifecycle approach, reducing the size of an organization’s queues is one of the easiest ways to reduce cycle time. What are some common queues? There are often queues of projects, queues of enhancement requests, queues of defects to be fixed, queues of features, queues of tasks, queues of email (large inboxes), queues of approval requests, queues of production database changes. The number of queues increases the more an organization is oriented around functional groups, and the number of queues decreases the more an organization arranges work to be handled by cross-functional teams.
This is where queueing theory and agile methods intersect really well. Cycle time is related to the load on your system, in particular your units of work processing. In most organizations, teams are created to handle work. The more work given to a team simultaneously, the higher their utilization level. Many organizations like high utilization levels because it gives them a guarantee that people are doing valuable work all the time that they are paid to work. This is a completely false benefit and in fact is extremely destructive to overall productivity. From queueing theory we know that the cycle time for a piece of work increases exponentially to the utilization level. We see this whenever we over-load a server… but for some reason we fail to see this when we overload a person or a team or an organization even though it still happens.
Cycle time is also related to the variability in the size of the work packages. Low variability means that the exponential factor related to load is low, and high variability means that the exponential factor is high. In other words, if you have a highway that only allows motorbikes, you can have a very high load without getting bad traffic jams. On the other hand, if you have a highway that allows anything on it, you get traffic jams even with low levels of load. This is why HOV or commuter lanes and the left lane in multi-lane highways don’t typically allow transport trucks and buses. This result from queueing theory is not intuitively obvious so it is even harder for us to apply to software development.
But apply these two ideas, load and work size variability, we must if we wish to create a high performance development organization. The simplest way to do this is to have a single team work on a single project at a time and use iterations to ensure that the work being done is always exactly the same size – the size of the iteration.
It is possible to have very short iterations and still have a long cycle time. Many organizations make a few common mistakes with agile that cause this. If the work done inside each iteration is restricted to pure development work and everything else is done outside the iterations, then cycle time likely stays long. A common example of this is having the QA folks remain separate from the development team and do their work after a development team releases their work.
There is really only one way to avoid this: have a comprehensive definition of “done” that is met by the team every single iteration. This ensures that all work from idea to release for a given customer request is done inside a single iteration. A side effect of this is that all the pieces of work need to be small. It also gets rid of all the queues except one: the queue of ideas approved for delivery. With a single queue to manage, it becomes easy to measure cycle time, and therefore easy to improve it.
Improving cycle time can now be done in a few ways:
Once you have control of cycle time, it is possible to make reasonable measurements of productivity and two more metrics become extremely important (not that they weren’t important before, but they are easier to work with now). The first is Return on Investment (ROI) and the second is customer satisfaction.
ROI is in its simplest form a measure of how much benefit there is to doing something as compared to the cost of doing it. It takes into account the importance of time and timing, the importance of other options you may have, and of course, hopefully takes into account the business reality of your work. It also takes into account costs.
In software development, the primary cost is the cost of the staff doing the work, and the time factor is your cycle time (Ah! that’s where we use it). If you have a consistent team working on iterations that are always the same size and if you have little or no work being done outside of the iterations, it is very easy to calculate ROI in a useful way. Simply measure how much value a given iteration worth of work will generate and divide by the cost of the team for an iterations (and if the team is not yet doing work as it comes in, take into account the time value of money since the work might not be done for several iterations). Now, productivity is simply a measure of the Return for each Team-Iteration. Dollars/iteration. Simple. If the team’s productivity goes down, you can ask some really simple questions:
Customer satisfaction can be measured in many ways. If you have already started using agile practices, there is a good chance that your customers will already be more satisfied than they were before. This will show up informally through word-of-mouth. However, it is good to have a more systematic way of measuring customer satisfaction. One of the simplest and most commonly used methods of measuring customer satisfaction is the Net Promoter Score. From WikiPedia:
Companies obtain their Net Promoter Score by asking customers a single question (usually, “How likely is it that you would recommend us to a friend or colleague?”). Based on their responses, customers can be categorized into one of three groups: Promoters, Passives, and Detractors. In the net promoter framework, Promoters are viewed as valuable assets that drive profitable growth because of their repeat/increased purchases, longevity and referrals, while Detractors are seen as liabilities that destroy profitable growth because of their complaints, reduced purchases/defection and negative word-of-mouth. Companies calculate their Net Promoter Score by subtracting their % Detractors from their % Promoters.
The Net Promoter Score is closely linked to quality including the hard-to-measure parts of quality like responsiveness, ease of use, and fitness for purpose.
Cycle time also affects customer satisfaction. The faster you can respond to requests by customer, users or other stakeholders, the more likely they are to be satisfied. This happens for two reasons: fast response time means that solutions are more likely to still be useful and correct when actually delivered, and it also gives more opportunities for feedback.
In fact, if we look at these three measures, cycle time, ROI and customer satisfaction, we see that they form a mutually supporting and cross-checking system of ensuring productivity and effectiveness. Measuring anything else muddies the waters and can cause sub-optimal behaviors. The real challenge for most teams is realizing that all their local measures of performance and effectiveness may actually be causing harm (unintentionally) because they draw the team’s attention away from the three organizationally important measures.
Cycle time is the measure that is most closely related to process improvements, but ROI and customer satisfaction should also be used to ensure that process improvements don’t accidentally harm the organization.