Posted on

On Retrospectives: Part 1

Retrospectives are team learning ceremonies and have the potential to create genuine team learning. Yet, I often notice that even after a great Retrospective, the team often forgets about the answer to question #3, “What do we want to change?” Jeff Sutherland once coached me in this and told me to focus the team on ONE and only ONE thing to change, so they have a better chance of actually remembering, focusing on it, and doing something about it. Since then I have used this technique to very good effect when coaching agile teams.

Another good technique is:  take pictures of everything. Usually in a retro we answer the three questions “What is going well?”, “What is going badly?” and “What do we want to change?”. Usually sticky noted and sharpies are used to get these items generated. Taking picture of the sticky notes-and-votes (the votes with dots) is a good way for the Scrum Master to recall what happened and remind the team.

I like to see the team to put up a poster of the #1 thing that needs changing. This visual management artifact makes it real that a) We had this conversation b) We committed to the act of doing something and c) We all know where we are with respect to this item we SAID we intend to change. Consider prompting the team to create a poster and put it up on the wall (in a prominent place) for the entire Sprint. That makes it real.

This next picture below depicts the act of deciding on that one thing you may eventually depict in a poster:

 

Question #3, "What do we want to change?". We used voting dots to get to one item.

 

This is the RESULT of the retro, the decision on what to change.

The above figure show 2 columns. Each column is an topic, with multiple notes from earlier. The notes in a column are related and come from the answers to retro question #2, “What’s not working?”. These have been voted on and the top two are depicted: changes to team composition and the pulling of people from the Sprint work during the Sprint. This team is experiencing both. As facilitator, I guided them to identify these top two items. Then I placed a blank sticky note under each column to receive votes. I gave each team member one (red-heart) sticker each, and asked them to place a vote on which of the 2 columns mattered most to them, in terms of what to change.

We came out of this retro with the decision that the team wants to address the issue of authority outside of the team making changes to team composition constantly.

Remembering to Remember

OK, now assume teh team is in the next Sprint and is doing a remarkable job of working on the one thing, that one impediment that they want to change. fix, edit, re-factor, etc. They do a good job, and now we are doing another retrospective at the end of this Sprint.

As facilitator of that meeting, it is a good idea to recall and re-depict the OTHER items that were candidates for change. By this I mean, the #2, #3, #4 candidate items etc from the LAST retro. Look at those as a start for the 3rd question “What do we want to change?”

By bringing these items back to full attention, the team recalls what other items may still be in the way, from 1 retrospective ago. This important sentiment is often lost from retro to retro, Sprint to Sprint.

Summary

In general, retrospectives are the single best source of substantial team learning. How much learning the team actually gets is a function of many factors related to team-recall and team-remembering. As the facilitator of retrospectives, keep this in mind. Be mindful for the team. Remember, and help them remember. This post provides some techniques. They are summarized below:

1. Come out with ONE thing to change, not many things. Use dot-voting to get the team to choose the one item. Structure the voting to yield ONE and only ONE item. As facilitator, steer them towards ONE thing.

2. Take pictures of everything on the wall if you are the facilitator. Use these images to help yourself remind the team of what it says it wants.

3. Coming out of the retro, suggest that the team make a poster that depicts the one thing they are committed to changing. Consider making this a group activity during the end of the retro.

4. In your current retro, recall and remind the team about the other candidate-items-for-change that came up at the last retro. Use the pictures and notes you kept and show the team these artifacts as you answer teh 3rd question “What do we want to change?”

I have experience doing Agile coaching that dates back to 2008. If you like this post and want to see more like it, leave a comment to that effect and I’ll compose another with more content on retrospectives. I have a few other tips you may find useful.

 

Posted on

Agile Project Management: It’s Got Legs

Agile Project Management. Where does it fit on the Stacey Complexity Graph?

Scrum and Agile generally are getting more popular because more and more work is becoming complicated, complex and even chaotic. Scrum and Agile work well in complexity and chaos because they are empirical in nature and as such, feature more frequent inspection. Scrum and most all Agile methods are empirical; empiricism is very effective when the situation under consideration is complex or even chaotic.

The Stacey Complexity Graph depicts these general zones and it is worthwhile to investigate the topography of this diagram if you are unfamiliar with it; this post assumes you know the Stacey graph.

What is happening is this: more and more of the surface of the Stacey graph is being consumed by complexity. More and more work is complex. The frontier of complexity and chaos is expanding. The frontier is more a wide fuzzy band that it is a very clear line or border. Regardless– more and more complexity is reality, even for previously ‘traditional’ project management projects.

Technology is driving all the change-on-change.

This is creating a situation where empirical methods are superior for managing work.

Repeat, this is creating a situation.

And the situation is this: the regular-old Project Manager is getting squeezed. More and more work is complicated and even complex and chaotic. This is forcing traditional PM’s to adopt Agile ways. The egg-shaped region in the center of the diagram is the traditional zone for Project Management: relatively high levels of agreement, and relatively low levels of complexity. There are many projects, even software projects, that are located here. Seriously.

 

The Stacey Complexity Graph. The frontier of Complexity, driven by technological change, is growing out from upper right to lower left. More and more work is more and more complex, day by day. This has implications far beyond software projects.

 

The green frontier shows how complexity and chaos are expanding to envelope more and more of our work in modern society. Towards the lower-left of the diagram, we have well-understood, even boring tasks like cutting the grass. Or paying your bills. No PM needed. Up towards the upper right, we have utter chaos and complexity. This is a zone where no Project Manager can help you, whatsoever,  because the rate of change is too big. You must use empirical approaches– frequent inspection—  to get a grip on reality near the upper-right of this graph.

So, using this graph, we can make the following assertions:

  • Some work is perfectly suited for management by traditional PMs. The quantity of this type of work is decreasing every day.
  • The rate of change in the world, driven by technology, is increasing. This increases complexity– and has the effect of making more and more work complex in nature. The quantity of complex and even chaotic work is increasing every day.
  • The traditional PM is getting squeezed. These PMs must adapt quickly.
  • For more and more work, there is a range of blended approaches, with ‘pure PM’ at one extreme and ‘pure Empiricism’ at the other extreme. In between, blended approaches make total sense. This is an opportunity for people managing these projects to engage in an art form. That art form is the creation of a tailored and customized project approach which perfectly manifests what is called requisite agility. It is the ideal, optimal level of Agility for a given situation. It is always tailored. For more detail on this, see the post, Requisite Agility: The Command and Control Military Gets Agile.

Summary

I think these explanations may be very useful, perhaps essential,  for anyone busy debating the merits of the Agile Project Manager. The Agile PM certainly has a place in the effective management of work, yet certainly, not all kinds of work. Yet increasingly, more and more work is well suited for an Agile PM approach. This is what I am calling empiricism injection. It is happening everywhere. The name of the game is the proper characterization of the project. From there, the right blended approach can be crafted and deployed.

The scary thing– and the thing driving growth of Agile (read: “empirical”) approaches– is the amazing rate of change IN the rate of change. The rate of change– across the whole world of work, and human civilization as a whole– is accelerating very quickly. This explains why the PMI is coming into Agile, explains the growth of Agile methods, and the effectiveness of using them. There is a small place for the traditional PM, a growing place for the blended PM, and a rapidly expanding place for the the purely empirical Agile approach. At one extreme, pure Agile is overkill. At the other, it is the only way. In between, we have more and more places where Agility plays well, and with it the opportunity to make artful choices.

For traditional PMs, the situation is clear: the traditional PMP “sweet spot” is being overrun by a wave of complexity. Each day, fewer and fewer projects qualify for a pure PM approach. The game has changed, is changing, and will change– in the direction of more complexity, more inspection, and much more overall empiricism in the ‘management’ of projects.

Anyone arguing the relative merit of the traditional Project Manager can probably do well by framing the discussion inside the Stacey Complexity Graph.

 

Posted on

Free-Standing Agility

The goal of any legitimate Agile Coach is what I am calling Free Standing Agility:

Free Standing Agility is that characteristic of a group of people, which allows it to at once identify, and rationally respond to, environmental change. Such changes may be both intrinsic and extrinsic in nature. By definition, Free Standing Agility is free of dependence on anyone who does not have group membership.

This Free Standing Agility (FSA) is that property that allows a team, group or organization to adjust, moment by moment, to forces and influences that alter their current environment and situation. This is typically a business environment, but need not be, to satisfy the definition. Any group or organization, for example a hockey team, or an orchestra, can be in state of FSA.

Agile Coaching

‘agile coaches’ who insinuate themselves into a group of people who they are purportedly coaching are doing a serious disservice to that group. The coaching relationship must not be polluted with dysfunctional structure. Embedding and ‘integrating’ into a group of people who are learning how to be a group is a most insincere act.

Such insinuations may take the following forms:

  • Occupying the Scrum Master role for “some time”, certainly more than 7 days, with no intent to teach the role, thereby robbing the group of important experience in that role. Note: Scrum Masters must learn by doing. If no one else is “doing” the SM role, there is no intent to teach it on the part of the “coach”.
  • Engaging in Extended-Stay (embedded) “coaching”. In almost all cases, engagements of this type have at least the potential to engender a serious dependency on the “coach”.
  • Occupying the Product Owner role for longer than 2 days, with no intent to teach the role to anyone else.

Free Standing Agility is possible when the Agile Coach engages in an arms-length relationship with the client group. In this manner, dependencies that are dangerous to both Client and Agile Coach are intentionally avoided, in service to the development of Free-Standing Agility in the client group.

See also: Previous Posts on Agile Coaching Ethics

Posted on

Agile Coaching and the Learning Landscape

In previous posts about Agile Coaching Values, I discuss how the lack of clear definitions for Agile and Agile Coaching create opening for all kinds of sorrows and abuses in the role of Agile Coach.

Once again, I reiterate: most people doing this kind of work have a genuine and passionate interest in creating a space for clients that leads to what I am calling Free-Standing Agility. That said, whenever there is money involved, we can expect abuses.

One way to curb current and future abuses is to be, as a community, self-policing. We can choose to encourage as normal the identification of actual and potential ethical abuses of the Agile Coaching role. Or, we can watch as the emerging profession dies a death of one thousand (ethical) paper cuts.

To be clear, I am not offering a definition of Agile, nor I am offering a definition for the role of Agile Coach. What I am offering is my participation in a wider conversation in and around the ethics of Agile Coaching.

I wonder how much longer we as a community can defer this essential conversation.

The Current Situation

A quick survey of the landscape illustrates the confluence of forces that are creating a crisis of ethics in Agile Coaching:

  • There is no ethical standard for the Agile Coach role. We are just starting this essential conversation. Some like excellent Agile leader George Dinwiddie are speaking plainly about what they are seeing. Quoting George’s well-reasoned post, “What is An Agile Coach?”:“…..The coach helps the team articulate the results it wants, and generate courses of action to achieve those results. The coach partners with the team on the coaching process, but allows the team to exercise its own judgement about the software development practice. The coach does not become a member of the team, but endeavors to wean the team off of the need to consult with the coach on a regular basis. There are consultants whose business model includes making the client more dependent on the consultant. That, to me, is not coaching. And that’s not the model of consulting that I choose.

 

  • There are some people in the Agile community that have a legitimate voice, who are presently unwilling or unable to articulate a public position on the essential matter of ethical concerns in the Agile Coaching space. This behavior is a non-starter and has the effect of dampening community-wide development of the dialogue. This in turn impedes a more rapid development of Agile Coaching into a legitimate profession.

 

  • The advent of the PMI Agile certification has the effect of complicating and widening the Agile conversation to include traditional projects and project managers. This creates more terms, words, and complex “noise” in the dialogue and debate about what is and is not Agile and by extension, and about what is and is not Agile Coaching. This in turn more greatly confuses what is and is not a good ethical standard for Agile Coaching. This at-time confusing noise becomes cover for potential unethical practices and borderline coach behaviors.

 

  • Some in the Agile Coach community are publicly asserting that embedded, 5-days-a-week Agile coaching, with he coach often occupying the Scrum Master role, is  legitimate in every way and in every case. There is a strong assertion, by some, that coaches can legitimately “consult” in the Scrum Master role, for “some time”, and this is actually a foundational element of good Agile Coaching. Not so fast. While there are specific cases where 5-days-a-week coaching makes total sense, in my view (and the view of many others who participate in this community,) these are the exceptions, not the rule. Those who seek to validate an embedded, ‘integrated’ Agile Coaching model are actually instigating this wider worldwide conversation about Agile Coaching Ethics. They do so by making strong public assertions that ’embedding’ an ‘integrate coach’ as Scrum Master for ‘some time’ is actually a foundational aspect of a comprehensive ‘model’ of Agile Coaching. Great! Let’s have this conversation without delay.

 

This conversation about Agile Coaching Ethics is starting. Has started. Is now underway.

And here is the very good news: This  is a very healthy conversation, ultimately leading to more community wellness. It is driven by a confluence of forces that are conspiring together, drawing in participants that have have a keen and legitimate interest in Agile Coaching.

 

Posted on

Agile Coaching Ethics: The Epic User Stories

Agile Coaching Ethics. Hmmm.

So, what are the requirements we are seeking to make real here?

What are the requirements for the users of a Agile Coaching Code of Ethics?

And why do you care?

 

Here are some candidate Epics for your consideration:

As an Agile Coach, I want to to understand the ethical boundaries of the profession of Agile Coaching, so I can deliver great service to my Clients, avoid ever doing harm to my Clients, and advance the state of Agility in my community and in the wider world.

As an Agile Coach, I want to to understand the ethical boundaries of the profession of Agile Coaching, so I can align and associate with other Agile Coaches who share and subscribe to these ideas

As an Agile Coaching Client, I want to to understand the ethical boundaries of the profession of Agile Coaching, so I can more fully understand what Agile Coaching behaviors are “in bounds” and which are out-of-bounds

As an Agile Coaching Client, I want to to understand the ethical boundaries of the profession of Agile Coaching, so I can ask questions about these ethical boundaries to prospective Agile Coaches, before I engage them

As a prospective Agile Coach, I want to to understand the ethical boundaries of the profession of Agile Coaching, so I can decide if this is a profession I want to actually associate with, and be a part of

As a Agile Community Member, I want to to clearly understand the ethical boundaries in the profession of Agile Coaching, so that I may map the actual behavior of Agile Coaches I encounter to this standard

As a Agile Coaching Community Member, I want to to clearly understand the ethical boundaries in the profession of Agile Coaching, so that I can determine if these standards are sufficient to encourage genuine greatness in our community, and work to improve them with others in the coaching community when these standards need more clarity of definition

As an International Agile Coach, I want to to understand the ethical boundaries of the profession of Agile Coaching which apply universally, so I can apply this universal subset to all of my Agile Coaching work throughout the world

As an International Agile Coach, I want to to understand the ethical boundaries of the profession of Agile Coaching which apply universally, so I can align with other Agile Coaching professionals opting-in to the application of these ethical standards throughout the world

Please add to these Epic User Stories for an Agile Coaching Code of Ethics; you may do so by adding a comment. Please use the User Story format if you do so.

 

See also:

Previous Posts on Agile Coaching Ethics

Posted on

Agile Coaching Ethics: The Definitions

There is plenty of money to be made in Agile Coaching. Wherever there is money involved in providing counsel and advice, there are ethical considerations to address.

When discussing Agile Coaching Ethics,we must first define our terms.

The real problem with defining Agile Coaching ethics is the fuzziness of the Agile Coaching role itself. And it is exactly this fuzzy definition  for Agile that creates opening for all kinds of unethical behavior, such as taking up the Scrum Master role and even the Product Owner role for a very long time as a ‘coach’. Remember, Clients know very little and are vulnerable.

When is it legitimate for a coach to be on an “extended-stay” with a client? When is is acceptable for someone in the Agile Coaching role to occupy the role of Scrum Master? Product Owner? For how long?

And in service to what?

Lyssa Adkins in her book Coaching Agile Teams, lists some of the varying roles that legitimate Agile coaches assume. These include:

Mentor

Facilitator

Teacher

Problem Solver (NOTE: this section does not condone ‘contracting’ or ‘consulting’ to solve Client problems)

Conflict Manager

Collaboration Conductor

I do not see anything here which validates the idea of the Agile Coach being on extended-stay, indefinitely,  in the Scrum Master role. In my view, that is not Agile coaching. Instead, it is plainly:  fee-for-service contracting.

So let’s call it that !

Agile Coaching is not contracting. Or is it? Some say this contracting is coaching.

How exactly have we come to include contract labor in a definition of coaching? There are some in our community who are promoting the idea of including ‘consulting’ in the Agile Coach definition. This includes taking up the role of Scrum Master for ‘some time’.  Excuse me?

Is it legitimate for a professional Agile coaching to take up the Scrum Master role for an undefined length of time? Or is this merely contracting? I assert it is the latter. Practices like this give Agile Coaching a black eye, as I have articulated earlier, in this post. In this situation, a dangerous and potentially harmful dependency on the ‘coach’ may be engendered. Such dependency has great potential to reduce the Agile-learning yield for the client, even as more money is being spent on this so-called ‘coaching’.

The deeper problem is the definition of Agile.

What is Agile? We have the manifesto, we have the Scrum values, etc. Where can the clear definition of Agile be found? Once we have located this definition, we may more properly address the question “What is an Agile Coach?” and my favorite question: “What are and where may I find the ethical standards for Agile Coaching?”

If you want to get confused quickly, simply Google “What is Agile” and examine the results.

And so it is here that the opening exists for the creation of many sorrows. “What is in” and “what is out” of Agile Coaching is fuzzy at best. That leaves the door open to all kinds of coaching abuses, including attempts to include contracting and “consulting” in the Agile Coaching definition, to justify doing for the Client what the client can and must do for themselves.

We might consider tightening up the definition of Agile Coaching. Since the role encompasses so many tasks, and the definition of Agile itself is so broad, it may be best to describe what Agile Coaching is NOT. This is a shorter list, and such a list clearly defines what behavior is out-of-bounds for legitimate and professional Agile Coaches.

What is striking as of 10/12/2011 is the total lack of conversation in the Agile community, worldwide, about this topic. That leaves the door open to all kinds of sorrows for coaches and clients alike.

See also:

Previous Posts on Agile Coaching Ethics

 

 

Posted on

Agile Coaching and Authority

Agile Coaches have broad latitude in how they operate inside a client. The client is bringing the coach in as a trusted adviser. The coach is presumably coming in with a heart of service and a mission to help the client achieve what might be called “free standing Agility”.

One way to achieve “free standing Agility” for the client is to STAY AWAY from taking up essential and authoritative roles in the client organization. Specifically, the act of assuming the role of Scrum Master is to be avoided unless specific circumstances exist. Why?

If the ‘coach’ plays Scrum Master and is occupying that role for more than a few days, the following conditions need to be in place:

1. The client has no one willing or able to do the job, and is actively recruiting to fill the role with an employee. Here the Agile coach fills a (temporary!) gap.

2. The Agile coach is modeling how to occupy the Scrum Master role as he or she mentors a specific client employee (or employees) in how to do it. Here the Agile coach is mentoring and modeling and teaching.

Absent these conditions, having a coach assume the Scrum Master role is a very bad idea, for the following reasons:

1. No one at the client is learning anything by experience about being a Scrum Master

2. The coach is in a position to extend his or her stay, by creating a real dependency

3. Teams and organizations tend to convey authority to the Scrum Master. This sets up the coach and the team and the org is a set of distorted alignments. Teams defer to the “Agile expert” coach, the Agile coach is encouraging dependency, the organization is not learning essentials, etc.

In this scenario, the ‘coach’ is functioning not as a coach but as a consultant. The truth is the ‘coach’ is acting as a mere contractor, essentially doing for the client what they can and must do for themselves if the goal of free-standing Agility is to be achieved. This is OK when the client and the contactor call it what it is. When contracting is called Agile Coaching, there is dysfunction.

Coaching is not consulting or contracting, and there is no place for these functions in coaching. Agile coaches who take up the Scrum Master role for ‘some time’ are in fact setting up an extended-stay, and a stream of predictable billing. That is what contractors and consultants do.That is NOT what sincere Agile coaches do.

When a coach takes up the Scrum Master role on an extended-stay basis, that is contracting masquerading as coaching. The Agile coaching community as whole gets a black eye when the definition of Agile coaching includes this kind of behavior. There are some voices in the Agile coaching community advocating the inclusion of ‘consulting’ in the Agile coaching definition.

Guidance: If you are a Agile coaching client, pay attention when your ‘coach’ suggests that they take up the Scrum Master role for more than a week. In most cases, this is a very bad idea. If you are an Agile coach, stop doing this. Short term, your client suffers.  Long term, your reputation suffers.

As Agile coaching matures as a profession, it is inevitable that we discuss what is in and what is out of the definition of Agile Coaching. The time is probably here to discuss the ethics of Agile Coaching. There is plenty to talk about.

 

See also:

Previous Posts on Agile Coaching Ethics

 

 

 

 

 

 

Posted on

Agile and Open Space

Open Space is being used in the Agile community for education. We sit in a circle, we lay out the basic idea, and off we go. In this sense, Open Space is not much different than a BarCamp or a Unconference.

At most Open Spaces I have attended in the Agile community, proceedings are not produced. The definitive book on the subject entitled Open Space Technology, a Users Guide, from Harrison Owen, clearly states that proceedings are part of the canonical Open Space meeting form.

A good introduction to Open space is at  www.OpenSpaceWorld.org

In Boston on September 29, 2011, we convened the Agile Day in Boston event in collaboration with Agile NYC. Our Open Space theme was “Freedom At Work” and over 245 people attended. We produced a full proceedings. The proceedings we produced were transcribed so as to be searchable. The PDF we produced included over 45 Open Space sessions on all kinds of Agile topics. You can downlaod and examine these Open Space proceedings in full searchable PDF format here.

Open Space is a wonderful meeting format, and useful for so much more than just  education and socializing. In the Agile Coaching, I use Open Space to help my clients get better and better. In the posts that follow, I plan to explain in detail the role that Open Space can play in an effective Agile Coaching practice.

The Opening Circle, Agile Day in Boston, 245 attending
The Opening Circle, Agile Day in Boston, convened 09/29/2011, 245 attending under the theme: "Freedom At Work".
Posted on

Toward an Agile Coaching Code of Ethics

Agile coaches usually assist organizations that know very little about Agile. These organizations actively seek authoritative guidance. It is safe to say that in almost all cases, the Client is in a vulnerable position. The client can very easily be taken advantage of. Now, to be very clear: The overwhelmingly vast majority of Agile Coaches in our community genuinely serve Clients, each and every day. Most folks in Agile Coaching are of high integrity and seek to serve. That said, the potential does exist for abuses of the role of Agile Coach.

A Coach may, for example, choose to take up the Scrum Master role or even the Product Owner role for ‘some time’.  This is called ’embedded’ or ‘integrated’ coaching.  It creates an ‘extended stay’– and some very real dependence. There are some in the Agile community who promote embedding as a completely normal aspect of Agile Coaching.

But wait. Is this something we are willing to validate as professional coaches?

The practice has several issues. First, the practice promotes an unhealthy level of Client dependency on the ‘coach’. Second, no one in the Client organization is learning anything useful about being Scrum Master, because the role is ‘occupied’. Third, when the ‘coach’ leaves, it is over, because little if any Client learning took place. The Client is not in a place of free-standing Agility.

We can do so much better than this.

The standards body known as the International Coaching Federation publishes the ICF Code of Ethics for Coaches . I believe this is a excellent starting point for discussing the construction of a Code of Conduct for Agile Coaching.

Take a look, especially pay attention to Section 2 Item 9:

Section 2: Conflicts of Interest
As a coach: 9) I will seek to avoid conflicts of interest and potential conflicts of interest and openly disclose any such conflicts. I will offer to remove myself when such a conflict arises.

I wonder if it is time for us in the Agile coaching community to begin having a crucial conversation … about Agile Coaching Ethics.

What do YOU think?

 

Here is some food for thought:

“What you tolerate, you insist on. What you insist on will be supplied.” – Michele and Jim McCarthy, SOFTWARE FOR YOUR HEAD

 

See also:

Previous Posts on Agile Coaching Ethics

 

Posted on

Scrum Values

Genuine and authentic Scrum strongly supports the values of Respect, Commitment, Focus, Courage, and Openness. Genuine and authentic Scrum is in fact powered by these values. The good news is: you do not have to be perfect at them. Just do them now, as best you can. Good stuff happens immediately regardless of where and when you start.

Respect

Respect denotes both a positive feeling of esteem for a person or other person, and also specific actions and conduct representative of that esteem. Scrum absolutely supports and encourages respect. Without respect, there is no meaningful positive communication. Instead there is high potential for miscommunication, disrespect, low (or NO) communication frequency, and hurt feelings. Authentic Scrum requires respectful interactions.

Commitment

Commitment is the act of binding yourself to a course of action. Scrum encourages commitment. If you cannot commit, you cannot act. You are in a state of do-nothing limbo, a state of inaction. Scrum binds you to commitments. Genuine Scrum displays high levels of commitment. Authentic Scrum is not possible without everyone involved paying attention to and keeping commitments.

Focus

Focus is the concentration of attention. Scrum encourages focus. If you cannot focus, you are not paying attention in any meaningful way. If you cannot focus, you cannot learn to any meaningful level of depth. Authentic and genuine Scrum is always focused. Scrum encourages and requires focus to be effective.

Courage

Courage is a quality of spirit that enables you to face danger or pain without showing fear. Scrum supports courage. Often, truth about reality is obscured when no one has the courage to say it. Often, teams feel unsafe to describe reality honestly in the workplace. They are afraid to get fired or otherwise damaged for saying what everybody knows. Courage is necessary in Scrum. It takes courage to call out problems, identify impediments, ask for help, receive help, and offer help. In an authentic and genuine Scrum implementation, courage in evident in the way people behave. Courage is honored and encouraged in Scrum. Scrum without courage is Scrum that only goes so far. Authentic Scrum requires courage.

Openness

Openess is characterized by an attitude of ready accessibility (especially about one’s actions or purposes); without concealment; not secretive. Scrum strongly encourages openness. instead of asking “why should I share this information?”, ask: “why wouldn’t I share this info?”. Authentic Scrum generates a high level of ‘transparency’. Everyone knows everything about the work in a genuine and authentic Scrum implementation. Real and genuine Scrum displays a huge level of openness on the part of everyone participating.

 

Organizational Culture regarding Respect, Commitment, Focus, Courage, and Openness.

You may find yourself in an organization or team that does not value Respect, Commitment, Focus, Courage, and Openness. If you honor these five values, and “they” don’t, you are in conflict with the organization or team you are a member of.

A good policy for teams new to Scrum is to write the five Scrum values on a big poster and place it where everyone can always see it. After a while of attending to these values, things can start to get better with your team-wide interactions. If your company’s culture does not already strongly support these values, you may start to notice the difference when you are ‘inside’ and ‘outside’ your Scrum team. The main difference is in what is valued. Genuine Scrum shows you, right away, what level of value your company places on Respect, Commitment, Focus, Courage, and Openness.

 

Summary

The Scrum values of Respect, Commitment, Focus, Courage, and Openness.are part of the heart of Scrum.

A personal decision to live out the Scrum goals of Respect, Commitment, Focus, Courage, and Openness in all of your work, play and interactions can greatly improve the quality of your life. It does not take long. As soon as you do this your team, your department, division, organization and yes, even your world, gets better.

Take a shot at this. Consider implementing punctuality as an entry point into the world of Scrum values.