Simple Rules!

"But, it's not on the list."

For years, I started a facilitation workshop by having the students come up with norms for the class. My intent was to both create ground rules for the session as well as have the students practice an activity that they would likely use themselves as facilitators in the future. The facilitation technique for this exercise varied from class to class, but the output of the exercise was usually a flip chart page with a list of do's and don'ts which we would then display prominently somewhere in the classroom.

Even with the ground rules for the class thus established, I found over time that it was not unusual for someone to do something during the class that, while not technically against the letter of norms, certainly violated the spirit... and further, it was not unusual for the someone, when called out for their behavior, to point at the poster the group had created and say, "But, it's not on the list!" From this individual's perspective, the fact that their behavior was not specifically prohibited by the norms captured on the flip chart page somehow made the behavior acceptable, no matter how disruptive the behavior might be.

On the positive side, the disruption gave the whole class an opportunity to practice their facilitation skills in another exercise, a retrospective, the intent of which was to improve the class norms — two birds with one stone, you might say. However, what also became clear over time was that no matter how valuable the activities of facilitating team norms creation and running retrospectives might be, no list, no matter how exhaustive, could possibly cover all undesirable behaviors of ingenious disrupters.

What to do?

For inspiration, I turned to something a wise man, Dee Hock, said:

"Complex rules and regulations give rise to simple and stupid behavior." 

Dee Hock's words put the class norms poster in a new light. Instead of growing the list of items on the poster, what if we considered a new approach? 

For this new approach, I drew on additional wisdom from Dee Hock:

"Simple clear purpose and principles give rise to complex and intelligent behavior."

What if instead of a long list of norms — rules and regulations, you might say — we came up with a simple set of principles that along with our class purpose statement would help guide us through the workshop?

Participate!

The first attempt at simplifying the class norms was a bit extreme. In the next class, the students decided on one principle as their norm: Participate! This one principle could inform individual choices as varied as arrival and departure times and when to return from breaks to how to use technology such as cell phones and computers during the class. We also found that the Participate! principle affected how students experienced the class. In addition to being physically present, the students tended to be more intellectually and emotionally present, as well.

This change worked so well that I decided in the next class to replace the ground rules poster with a simple poster on which was written the one word "Participate!" The team norms facilitation exercise shifted to one in which we discussed the difference between principles and rules and how using a principles approach might impact the work we did in the class. Confident that we were on to something, I decided to adopt this new approach to the class norms exercise. The principles poster with it's one word "Participate!" became a standard going forward.

For a few classes all went well... until one class, in which we learned that not all participation is desirable.  During this class, a difference of opinion between two students resulted in some unpleasant things being said by both parties. A resulting uncomfortable moment of silence was broken by one student congenially remarking, "Well... I'm not sure that's what we meant by "Participate!" To their credit, our verbal combatants chuckled and one, with remarkable humility, asked that we try out "that retrospective thing" to improve the class norms.

Respect!

With Dee Hock's advice in mind, the class engaged in a retrospective to decide what to do. After a few minutes of discussion in which having and expressing different opinions was upheld as desired, the group decided that the interactions in the class could be made more effective by adding the word "Respect" to our current one word principles list. Respect would then inform the act of participation. We made this change and the class was a great success. To this day, these two principles serve as simple rules for all my classes and workshops.

What are your "simple rules"?

Look around your team environment. How do existing rules and regulations impact your team's interactions? What principles are present? Are they explicit? How do these principles inform your team's interactions? Can "simple rules" make a positive impact on your team's effectiveness?

Coaching Beyond The Team

This post is a re-print of my article originally appearing on the Scrum Alliance website on 3 March 2011.

As an external coach, I am often brought in to teach a new team the Scrum framework and to personally coach the ScrumMaster, Product Owner and Scrum Development Team Members in their new roles. However, the coaching does not stop with the Scrum Team. Scrum does not limit its organizational impact to just the Scrum Team. Therefore, coaching must also extend beyond the team. To explore this extension, let’s look at an example of a traditional role often shaken up by the introduction of Scrum, the Resource Manager, and how coaching might impact this individual’s development path.

In organizations that use a matrix or pool for staffing, the Resource Manager allocates people to projects, while balancing capacity, availability, and demand. Resource Managers are often faced with more demand than supply. This imbalance results in the Resource Manager assigning individuals to 2 or more initiatives simultaneously. The pressure to spread people across multiple projects is increased further in organizations that reward high “utilization.” Since the individual projects start and stop on various dates, the Resource Manager has a busy job planning who is to be working on what projects at what time. The work is complex and the job thankless, but that is why the Resource Manager is paid the big bucks.

Enter Scrum. Scrum initiatives are often staffed with dedicated teams. In other words, the individuals on the core team are fully allocated to the team. If the Scrum adoption starts with a single pilot project, this dedicated team usually has a limited impact on the staffing pool and the project portfolio. Some other projects may be delayed and some people outside the Scrum pilot may take on more work — inconvenient, yes, but workable.

The problem for the Resource Manager arises when the pilot is successful and more initiatives are launched using Scrum. Each of these new efforts demands its own dedicated team. As the number of dedicated teams grows, the complexity of the Resource Manager’s high paying job dwindles to the point of becoming trivial. The role of Resource Manager as master of a staffing shell game is no more. The Resource Manager’s problem now is how to remain relevant to the organization.

For the Resource Manager, this shift can be scary. What does a Resource Manager do when the job becomes trivial? How long will the organization continue to pay big bucks for this job? At this point, the Resource Manager may be thinking only of how to preserve his or her job. The job of the coach is to help this individual work through this problem. For one Resource Manager, who we will call Paul, here is how the coaching process played out.

In a conversation with Paul, he revealed that he actually hated his job. Paul had been promoted into a management position only because he had hit the top of his pay scale and the organization was afraid that they might lose him to the competition. Paul’s real passion was in technology. He found no satisfaction in moving assignments around in a spreadsheet. Paul’s only contact with the technology now was from a distance. Dealing with the politics of too much demand for too little supply took most of his attention. The only part of the job Paul liked was getting to know the people in his staffing pool and helping them develop professionally.

With some encouragement, Paul described his ideal job. What he really wanted to do was to mentor technical employees and create a learning environment where employees could develop and share technical skills and knowledge. Paul wanted to combine his technical knowledge and his people skills to improve the technical competence of the entire organization by encouraging learning and sharing across teams.

Following our conversation, Paul proposed a new position to his manager. Noting that the creation of dedicated cross-functional teams had broken down the traditional organizational silos based on job function, he argued there was now a need for a position to support technical cohesion and collaboration across the organization. This new position would focus on individual and team professional development and organizational learning. The new role would be a sort of internal consultant who would ensure cross-pollination of technical ideas and competencies across teams. Ultimately, Paul got his new position and helped establish a new non-management promotion path for technical workers in his organization.

Paul was successful in figuring out how to navigate the changing organizational landscape. Coaching didn’t solve Paul’s problem. Rather, coaching helped Paul figure it out for himself.

It is easy to underestimate the seismic shift people throughout an organization experience as the development processes and underlying organizational structures react to changes made in response to Scrum’s inspect and adapt cycle. Paul, our Resource Manager, is but one example. People in leadership, portfolio management, operations, finance, customer support, audit, marketing, sales, and so forth all feel the impact. Coaching doesn’t stop at the Scrum Team boundary — organizational change requires coaching beyond the team.

4 things - self-organizing teams

Organizations steeped in a command and control hierarchical culture sometimes struggle with the concept of a self-organizing team. Releasing "control" to the team is a scary leap of faith and not a leap to be undertaken without proper preparation. Before setting a team loose to find it's own way, here are 4 critical things to put in place to increase the chances of having a successful self-organizing team.

  1. Shared Goal - Establish a shared understanding of the goal.  A shared goal focuses the the team members' energies in the same direction. This laser-like focus leads to quick, targeted results. The shared goal is an essential container for a self-organizing team's creativity, setting both boundaries and direction. Absent an effective container, prepare for chaos.
  2. Dedication - Ensure that each team member is fully available to the team. Part-time is only acceptable if it does not create impediments to the teams' progress (in practice, it is rare that part-time availability does not impede flow).  Dedicate space, equipment, and tools so these resources are always available without delay when needed. Waiting kills momentum and focus.
  3. The Right Stuff - Staff the team with a mix of people that in combination have the appropriate level of knowledge, skills, expertise, leadership, and accountability to get the job done. Attitude and aptitude play a big role as well. Also, provide the things the team needs to do the job including workspace, tools, and equipment. Don't starve the team!
  4. A Sense of Urgency - Give a deadline, leaning towards a shorter timeframe. Agile frameworks impose short iterations during which real, meaningful, and measurable progress is made towards the goal. Deadlines encourage action. As Samuel Johnson said, "Depend upon it, sir, when a man knows he is to be hanged in a fortnight, it concentrates the mind wonderfully."

And finally, listen and respond to the team's needs. A team starting out is never perfectly staffed and outfitted despite best efforts.  If a team discovers a way to improve and needs help to implement the improvement, give them the help they need. With the proper ingredients for success, self-organizing teams thrive and become a powerful, nimble, and effective engine for delivery.

"Draw Left": Why Communication Matters

"ROCK!!!" Despite my warning, the ominous scraping sound moments later told me we were leaving a bit of our canoe behind us on this trip down the Shenandoah River. This little encounter is an example of what my son jokingly calls "painting the rocks" based on the red vinyl marks we sometimes leave as reminders of our passage.

Normally, when canoeing, we try to avoid collisions, and at first I was puzzled and a bit upset that my son had not reacted in time to maneuver the bow of the canoe out of the way. He's a skilled paddler and a simple stroke of his paddle would have been all it took to slip by unscathed. Why hadn't he done what I expected?

Well, in the somewhat heated discussion that ensued, I discovered that I hadn't exactly been clear as to the location of said rock. Besides, I had the advantage of polarized glasses and despite being in the stern, generally was able to see submerged obstacles well before my son. Lacking this critical information, he simply pulled the business end of his paddle out of the water and let me steer assuming I had it all under control. Had I wanted him to do something, clearly I would have said so.

On reflection, admittedly much later and after much fuming, I realized that we could have avoided the rock if I had simply shouted "Draw left, now!" Never mind trying to point out the rock. Avoiding the rock was the goal. Getting the front of the canoe to shift to the left was what was needed now.

Our collision resulted from a failure to communicate. We had mastered the right paddling techniques. But, we hadn't mastered the practice of communicating in a language that would enable us to operate as a team. In the end, it shouldn't have mattered whether or not my son could see the rock. It only mattered that he know what was needed.

At the shout, "Draw left, now!", my son would have simply put into action what years of practice have make into muscle memory. He would have reached his paddle far out over the water to his left, slipped the blade into the water, and, with a quick stroke, pulled the flat side of the blade toward the side of the canoe. The bow of the canoe would have shifted to the left and aided by a stern draw or even a simple angling of my paddle on my part, the canoe would have slipped by leaving that rock unpainted.

In a team environment where a rapid response may be necessary, whether canoeing downriver with a partner or as a team member on an Agile project, it helps to have a common language or lexicon to foster quick communication. The right words spoken at the right time tend to lead to the correct action. The use of words outside the lexicon may lead to undesirable results.

It takes time and practice for a team to create a common language. Once developed, instructions like "Draw left" result in quick and efficient responses. Giving an instruction like "Rock!", which is not part of the language, is often inefficient and ineffective. Developing proficiency or fluency in the team's language is essential to the smooth flow of the team's work.

What is your team's language? How proficient are your team members in their way of communicating?  Consider both business language and technical language. What are the words that are unique to, or have a special meaning, in your environment? For example, the word "forging" means different things to a banker than it does to a blacksmith. The phrase "breaking the build" has a meaning unique to the practice of continuous integration. Knowing what this phrase means is essential to the team to know what action is required next. Investing a bit in creating and practice in learning a common team language will pay off well in improving your team's communications proficiency.

"Out of Sight Out of Mind" = "Invisible Idiot"

Translation is a tricky business.  What seems clear in one context is murky in another.  The translation urban legend*, abbreviated in the title of this blog entry, humorously captures the difficulty of communicating when those who wish to communicate speak different languages. When discussing Agile with executives, I often find that their perception of Agile differs depending on their own and their organizations’s underlying cultural values.  For example, I often hear that the adoption of Agile principles and practices is incompatible with a command and control culture.  I do not believe this statement to be true.

According to organizational psychologist, Bill Schneider, Control cultures value certainty in the attainment of organizational goals.  The organization is seen as a system built expressly to achieve those goals. While predictability, accuracy, dependability, safety are characteristics of certainty, these values are not fundamentally inconsistent with Agile.

I believe success with Agile in a command and control environment requires an accurate translation of Agile’s benefits in terms that resonate with the values and goals of the organization and its leaders.  There must be an alignment at the cultural level before execution can be successful.  To foster alignment, you must learn how to talk like a native.

I will be running a workshop helping others explore this topic (“Finding a Fit for Agile in Your Corporate Culture”) at the Quest 2011 Conference in Boston on 7 April.

* "The whisky was invisible", or Persistent myths of MT

John Hutchins, MT News International 11 (June 1995), pp.17-18]