Team Tips - 5 {Trust me!}

We're having a snow day; first of the season.

So it's a good time to tackle this challenge for teams from Jose R.:

"How can you recover trust inside a team that has lost it?"

Trust between team members and between the team and their boss is critical for great teams. In fact it is a deciding factor, we have learned, between great teams and those other groups. When we see individuals on the team trusting each other to uphold their commitments and decisions, then we know the team has moved into that “sweet spot” or the “greatness zone”. This is because the energy freed up from dealing with the emotional drama of lack-of-trust issues can be directly applied to producing a great product on time. It is the difference between team energy being wasted in a downward spiral, and having that energy provide creative ideas, the perfecting and execution of those ideas, and the upward spiral of success.

Additionally, that trust releases everyone from managing each interactive transaction as if there were a high risk of misunderstanding, mistakes, waste, and allows that time and energy to be spent where it is most productive.

We call this model “Trust versus Control”.

This becomes very obvious with a boss that is “micro-managing”. If the boss believes he or she has to be involved in everything the team does, then the team can almost be replaced with machinery. They end up doing each task under close supervision like robots. Alternatively, if the boss has confidence in the team's ability to perform the basic tasks, that can be extended to the team determining their own workflow, quality, deadlines, etc. In the ideal case, for example after attending a Great Teams BootCamp*, the team is proficient in managing their own affairs. All the boss need do then is accept the team's status reports, confirm to his or her satisfaction that the product is on time and will be great, and... take the rest of the day off.

Whenever that level of trust is lost then we are back to the more common case of groups in organizations everywhere.

So to Jose's question: What can we do to build or recover trust?

What we have observed over 15 years in the Simple Rules and Tools for Great Team Immersion* – a.k.a. BootCamp – is that the adoption of the Rules – the Core Commitments – and the use of the Tools - the Core Protocols – is a great starting point. These provide a foundation for the desired end result which is a persistent track record between team members, and between the team and the boss, of successful personal interactions. That is: commitments kept, ideas shared, support provided, results delivered, etc., all of which indicate that trust has been earned, like deposits in a bank account.

A significant starting point is the team agreeing on a shared vision. The ideal method to get to this state is the development of personal goals, or wants, by each individual on the team that each team member agrees to support. The sharing of these personal alignments leads to a state of shared vision – people in alignment with each other – and enables the development of a shared vision statement. What we have experienced is that individuals in a state of shared vision have the basis of trust between themselves which can then be amplified across everything they do.

By individuals keeping their Core Commitments, supporting each other's Personal Alignments, and going further to engage each other regularly by Asking for Help, Investigating, sharing and Perfecting ideas, etc., the team members keep making trust deposits. The nature of these deposits is: I can be counted on to act responsibly as an adult, to avoid emotional drama, to meet my promises, to engage with others in every question of product delivery and quality.

If trust needs to be recaptured, these same tools are effective. Particularly Ask for Help.

Individuals following the Core Commitments can be depended upon for adult, engaged behaviour. Asking these individuals for help, on any question, develops a relationship with him or her based on respect and inclusion. This exercise supersedes just getting information. This is an act of connection which starts to rebuild trust. Keeping promises, being open to diversity of ideas, including others in gathering information, sharing ideas are all positive influences for regaining trust.

And based on our experiences with great teams you can trust me on that. :)

Click here for your own copy of the Core Protocols – the Simple Rules and Tools of Great Teams.

To add your team challenges to the list add a comment below or message me @ReevesResults on Twitter.

Team Tips - 4 {Is this for me?}

Another challenge for teams comes from Jose R.:

“Can everybody work in teams?”

I am so very tempted to reply with a sarcastic answer, except that wouldn't be helpful, and this is a really tough challenge.

Some people I have observed over the years just don't seem suited to work with others at all. I leave it to psychologists to analyze and guess why. But most of us have encountered those who simply like to work independently or even have a difficult time making conversation with one other person, let alone a team.

In fact, some people, like myself, chose to work in fields like computer science to reduce the amount of time needed to deal with other humans, their emotional states, their foibles, etc., and maximize their time dealing with the pure, rational, logic of computing.

And some, like myself (again! ?), find themselves so disappointed and de-motivated working in organizational groups where there is no clear vision, objective, approach, sharing of ideas, focus on results, etc. that they can't function effectively. In those kinds of organizations I am un-employable (and have the severance packages to show for it.)

So if we view the challenge as “Can teams provide a work environment for everyone?” we can see why team building, team work, team success is difficult for lots of organizations and anyone who is stuck on those teams.

For those teams that can demonstrate success through the delivery of great results on time every time*, we can revert back to the original question and ask: “Can anyone at all become part of that team?”

And unless the product or service that your organization delivers to its customers can be built by one person only, never interacting with anyone else, we need to address this challenge.

What we have found in our work with teams using the Simple Rules and Tools of Great Teams* is that no, not everyone will want to be part of a given team's shared vision, and adopt the rules and tools to deliver great results. Some just aren't ready to step out of their comfort zone, give up their previously learned models and behaviours for mediocre results, accept the responsibility and accountability to be their best. This isn't a judgemental statement; it's just fact.

We all become ready to be our best in our own time, at our own pace. Unfortunately, in my opinion, some run out of time before they get to a decision.

What we have also found so far is that the best way to know if one IS ready to be part of a team is to attend the team building session known as BootCamp from McCarthy Technologies. There one is immersed in the Simple Rules and Tools of Great Teams and can discover for themselves if they are ready, and what it means to be part of a great team. As covered in the previous posts, this also allows the boss to recognize which people are creating which team, and for an existing team to determine their members.

Another choice is to join a great team for a probationary period to see if one is up to the challenge. An important team work practice is prototyping: building versions of the required product or service to be “perfected” (using the Perfection Game tool). Similarly, a probationary period for a new member is a use of prototyping.

Being part of a team isn't about group hugs or being in constant agreement with the rest of the team. Sometimes independent behaviour by a team member is the best choice for the team in a particular situation. Further, if the team's shared vision isn't shared by someone, then it is best that they leave the team – to possibly form their own team.

So if you are one of those extremely rare people who never needs to work with anyone else, you don't have to concern yourself with team work. Happily for the rest of us there are really excellent options.

Click here for your own copy of the Core Protocols – the Simple Rules and Tools of Great Teams.

To add your team challenges to the list please add a comment below or message me @ReevesResults on Twitter.

Team Tips - 3 {Who gets to play?}

The next challenge for teams I have chosen is from Ben N.:

New member ?

“How to select members for a great team?”

The smartest way we have seen people get selected for a team is to have all potential team members attend the team building workshop: Simple Rules and Tools for Great Teams. This session is also known as BootCamp by the originators of the event, Jim and Michele McCarthy, and is based on their book Software for Your Head.

By inviting potential team members to participate in this workshop the boss* is setting some initial conditions which help define the basis for the team. (* see Team Tips - 1)

1. The workshop is NOT mandatory. Accordingly, the people who attend are only those who want to be there; hence, want to be part of the team
2. By participating in the session attendees are immersed in the Core Protocols – the Simple Rules and Tools. This helps everyone involved get to experience and practice these foundational behaviours for great teamwork, and some will invest energy in this learning and thrive in it, and some may choose not to
3. During the session, the team members develop a Shared Vision for that team. If someone doesn't wish to share that vision they are free to follow their own dream and so move out of the original team
4. The team members that find that the Core Protocols as used by the team deliver on the promise of high band-with communication, fast decision making, the development of trust, a focus on results of high quality, etc. become their own self organized team. Any attendees who don't are again free to not participate, possibly forming their own team working in other ways

The boss gets the result: a self organized team, following Simple Rules and Tools that are repeatable in any situation, scaleable for any size of group, reliably working to produce the best results on time every time. Any attendee who chooses not to be part of this, effectively self-selects themselves off the team.

Our experience with this approach is that:

   a) bosses have used the session to “do the hiring”. That is the immersion becomes the hiring process, and the check for personality chemistry, and the probation period, and any other scrutiny one wishes for in a hiring process. (And the cost of a “normal” personnel search, interview and hire, and possible failure after three months of probation more than pays for the session.)

   b) or alternatively, they have seen after the session who should be, or remain, “on the bus” [Good to Great, Harper Collins, Jim Collins] and can identify those who don't wish to work on the team using the Core Protocols. (Again this saves considerable energy and cost dealing with employees who have turned out not to be a good fit.)

Team

The quick answer then is: Have the team select their own members.

If the team already exists, then they are the best people to determine who will fit well on that team, who can aspire to the team's shared vision, will use the team's commitments to responsible behaviour, and follow the team's protocols for information sharing, decision making, self improvement, development of great products or services, etc.

And just as the great teams work with a bias toward action instead of discussion, and incrementally building prototypes, and perfecting them, they can do the same thing in confirming new members. That is, work with them over a probationary period for everyone to confirm that the newly expanded team is functioning as well or better, and similarly the team is a good fit for the new member.

Great teams learn to let ideas go, and similarly can accept that their world isn't perfect for everyone. Sometimes the shiniest, prettiest, smartest new hire just shouldn't be on this team. The Core Protocols provide the tools to deal with that.

Again, the underlying premise in all these answers is that the team is using the Simple Rules – the Core Commitments in the Core Protocols – and the Tools – the Protocols themselves for their day to day operation. This is simply the smartest approach for any team that we have found.

So here is the “catch”. If what I am suggesting doesn't seem workable in your situation, then you need to use the Simple Rules and Tools for Great Teams (or something better).

To add your questions to the list add a comment below or tweet me @ReevesResults.

Team Tips – 2 {Where's the Boss?}

Assuming you've read the previous post – Team Tips - 1 – you know the definitions I'm using for “teams”, “boss”, etc. and can guess that I will be relying on the Simple Rules and Tools for Great Teams – the Core Protocols – in my answers.

Indeed, the underlying premise in all these answers is that the team is using the Simple Rules – the Core Commitments in the Core Protocols – and the Tools – the Protocols themselves, for their day to day operation. This is simply the smartest approach for any team that we have found.

So here is the “catch”. If what I am suggesting doesn't seem workable in your situation, then the organization needs to use the Core Commitments and Protocols (or something better).

Let's start with one of the most complicated situations Vickie and I have had to work on with a team, the question Jose R. asked:

“Does the boss belong to the team, or he just must work for it?” (I believe for the last part Jose meant “or does the team just work for the boss?”)

(Remember: “boss” as used here is defined in the prior post Team Tips - 1).

Boss

The simplest rule is NOT to have the boss be part of the team. The team works for the boss, and delivers the product or service the boss requires, in the timeframe the boss requires, with the quality the boss requires. And in large enough organizations the boss is on his or her own team with other bosses of other teams.

Team

In fact the teams working for a boss ARE THE PRODUCTS of the boss, and the teams across the organization are the products of the team of bosses. In the purest arrangement the bosses don't produce any final product or service for sale to their retail customers – their teams do.

And to get even more precise, the boss sets the initial conditions for the team – what must be produced and delivered by the team, and when, and within what constraints (resources, values, legislation, policies, etc.). The most experienced and mature teams can take responsibility for deciding what can be produced and delivered against a given deadline, or alternatively, what deadline they can meet for a given product requirement.

All of this works smoothly when there is a high level of trust and a high level of communication both ways between the team and the boss. And, of course, individual commitment and responsibility from each team member. (We'll explore trust and commitment more in future posts.) These elements are all comprehended and provided for in the Core Protocols.

But the situation gets trickier when the organization is smaller and, for example, the owners of the business are the bosses AND are also contributors to the team and its products.

In this special case the boss or bosses have to operate in two modes: explicitly as the boss, and explicitly as a team member. The modes have to be crystal clear at each moment in each transaction between all parties – that is why I emphasize “explicitly”.

In all cases, the boss's job is to have the team produce a result on time that is great in the opinion of the team and the boss. The boss does not have to be concerned with how that is done, what tools or methods are used, etc. as long as the initial conditions – the non-negotiable items – are met. If the result exceeds expectation or is finished early – fantastic. If there is any doubt that this will happen, the team should be reworking their methods, their focus on deadlines, their quality, etc., without expecting the boss to intervene or rescue them, unless they specifically ask the boss for help.

Similarly, in daily operation, the team relies on the merit of the best ideas from any team member at any time to proceed to producing the team result. The boss as a team member cannot have any special standing or influence, otherwise the other team members will eventually stand back and wait for the boss to propose all ideas and make all the decisions, and the huge opportunity for individual leadership, innovation, and energy is lost.

Accordingly, as the boss the business owner states the end result required or the deadline, then steps aside to let the team get on with it. As a team member, the owner acts as an equal with all the other team members to determine how best to produce a high quality result, or when the result will be completed as appropriate.

To be crystal clear about what mode the business owner is in – boss or team member – he or she may use a special name, put on a particular hat, etc. or simply say: “As the boss I need...” or “As a team member I propose...”

Needless to say, this special case can add a layer of extra effort and confusion, and so we recommend the simplest scenario for teams that are just getting accustomed to using the Core Protocols for team building and operation. But if there is no choice, we have a number of ways of accomplishing the special case.

If you already are knowledgeable about the Simple Rules and Tools of Great Teams – the Core Protocols – then you can see how this boss / team model works.

If not, then you will probably have many more questions on how this model can possibly work! So please send in your questions via the comments section below or @ReevesResults on Twitter.

Team Tips – 1 {Some challenges}

Since my partner, Vickie Gray, and I have been working with Jim and Michelle McCarthy on developing Great Teams over the last 8 or so years, it occurred to me to collect the things we have learned observing successful teams and create a series of blog posts.

These observations might be called Team Tips.

(They are actually recommendations for team members collected over the 15 years that the Simple Rules and Tools for Great Teams – the Core Protocols – have been gathered and used. But “Team Tips” is more catchy. :-) )

And then I thought: Why not ask my Twitter world for suggestions for posts – what are the challenges that people have about team work?

Here are some replies so far:

From Jose R.: 

“Can everybody work in teams?”
“Which is the best road to high performance teams?”
“Does the boss belong to the team, or he just must work for it?”
"How can you recover trust inside a team that has lost it?"

From Ben N.:

“How to select members for a great team?”

Nothing like starting off with some really important questions!

So while I am working on the answers to these questions (and setting aside all the other recommendations I have for the moment) it seems worthwhile to get some terminology straight so we are all clear on the words.

Here are some definitions we use:

“Team”: A team is a group of two or more people working on a common goal. Immediately that moves us beyond groups at work into any situation: sports obviously, community groups, church groups, families, couples, etc. There shouldn't be any circumstance where the team practices we use – the Core Protocols – won't work. Nor have we found culture, language, arbitrary social class rankings, etc. prohibitive.

“Boss”: A generic term covering all the organizational words for someone in authority over the team, e.g. manager, director, team lead, project manager, etc. The boss represents the power that sets one or all of the goal, resource budget, time deadline, etc. In Human Systems Dynamics terms the boss sets the “initial conditions”. We often refer to these items as those that are non-negotiable by the team. In a typical workplace the boss represents the owner / president / CEO who has the final decision making authority. In a family the boss is the combined and agreed decision making authority of the parents or couple.

“High performance teams”: In my corporate career I previously used this term very loosely as meaning any team operating with some awareness of their own performance and having some techniques to intentionally direct their own work. (And I thought it was a big deal to get that far.) Having since experienced what excellent teams can do I now use “high performing” to refer to teams that are committed (scary word!) to intentionally (not maybe) delivering great results (as considered by themselves and their boss) on time, every time. In other words, teams that consistently and continually use the Core Protocols (or better).

And finally, for now...

“Member”: Any one who considers them-self part of the team, and whom the team agrees is part of the team, not because of any assignment by organizational grouping or task, but because of their behaviour. And that behaviour includes their own commitment to intentionally great results from the team.

I'm sorry if you were hoping for quick and easy answers instead of this preamble. In Human Systems Dynamics (HSD) terms a team, as any group of people, is a complex adaptive system. That is, it is a system constantly adapting to a chaotic environment. Which is why self help books and blogs, weekend retreats, climbing ropes in the woods, facilitated intervention can help momentarily but typically doesn't last or grow. These things are not maintainable, repeatable, scalable for the chaotic, dynamic world we live and work in.

HSD also teaches us that simple rules and tools are important for people in complex adaptive systems. (Simple means a short list that is clear and concise – not necessarily easy).

That is why Vickie and I refer to the Core Protocols for team building and operation as the Simple Rules and Tools for Great Teams.

And why I'll be referring to the Core Protocols in the next posts as I answer your questions about teams.

To add your questions to the list add a comment below or tweet me @ReevesResults

ITIL in The Cloud - 3

ITIL in The Cloud (part 3)

In this series I have been discussing the usefulness of the ITIL Framework when dealing with the model of computing referred to as “the Cloud”. (Definition provided in part 2).


It's always interesting to see a tidal wave of articles about a phenomenon where the terminology or jargon is readily waved about, positions are staked out, bets placed, opinions posited before we even come to terms with what the topic actually is about.


For example:


From “CIOs lack adequate cloud computing knowledge"
http://www.itworldcanada.com/news/cios-lack-adequate-cloud-computing-knowledge/143661?sub=390801&utm_source=390801&utm_medium=dailyitwire&utm_campaign=enews
By:  Stephanie Overby    -   02 Aug 2011

A survey of cloud providers and outsourcers returns some embarrassing scores on the cloud skills of IT executives. 

Traditional IT outsourcing customers are struggling with cloud computing, according to IT service providers and outsourcing advisors surveyed by KPMG Sourcing Advisory. IT service providers and advisors rated their IT executive customers' facility with various aspects of cloud computing on a scale of one to five, where one represented "very unskilled" and five represented "very skilled." IT executives earned embarrassing scores from their providers and advisors: None garnered even a middling score of three. 

When it comes to managing and governing cloud initiatives, IT leaders earned their lowest scores from respondents: 1.69 from advisors and 2.19 from providers.

(Note the precision in the scores of two places of decimal – very scientific indeed! Unfortunately we aren't given the sample size or information on the demographics.)


The article continues to point out that it is the pace of technology change, including the development of the Cloud environment, that is a big difficulty, and that the IT management skills required need to be learned and practiced more.


Hmmm. Smells like a framework of best practices in this area could be helpful.


A framework like, say, ITIL (Information Technology Infrastructure Library)?


And how could that learning and increased used of the best practices help?


According to the National Institute of Standards and Technology in the U.S. the Cloud has

• five essential characteristics (On-demand self-service, Broad network access, Resource pooling, Rapid elasticity, Measured Service)
• three service models (Cloud Software as a Service (SaaS), Cloud Platform as a Service (PaaS), Cloud Infrastructure as a Service (IaaS))
• and, four deployment models (Private cloud, Community cloud, Public cloud, Hybrid cloud)
• key enabling technologies include: (1) fast wide-area networks, (2) powerful, inexpensive server computers, and (3) high-performance virtualization for commodity hardware

Compared to that list of essential characteristics, ITIL practices can be applied

• in understanding the customer demand for self-service, profiling the IT Service Provider's resources and capabilities to meet that demand, managing the customer & supplier interface
• in determining the network access policies, procedures, security requirements, contingency planning
• in managing capacity and availability not just of the technical infrastructure but of all the resources and capabilities of the organization
• in ensuring changing customer requirements are well managed through responsive change management and deployment
• in determining and monitoring service levels and performance to those targets

With respect to Service models, ITIL is all about IT Services – understanding all the customer's interests and requirements, and the corresponding capabilities of the IT Service Provider.


Finally, ITIL doesn't speak to enabling technology choices because the IT Service Management thinking isn't altered by the choice of technology.

And all of the ITIL practices apply to whichever side of the Cloud edge one is on – Customer buying Cloud services or Cloud Provider delivering services. We just have to sort out who does what for whom in the steps of each process. Which is pretty darn important in any business deal whatever model one uses.


So if your score was in the 1.69 range, don't despair. Help is available!


For more about ITIL and IT Leadership please contact me via http://www.BusinessImprovementResults.com

ITIL in The Cloud - 2

ITIL in The Cloud (part 2)

In part one I introduced the notion that taking advantage of good business practice in all its forms like ITIL just makes sense, and even more so as one considers operating in, or with, the Cloud.


But when we talk about “the Cloud” what the heck do we mean?


How about this definition from the National Institute of Standards and Technology in the U.S.:
“Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.”


Aha! We are talking about a model for the use of computing resources.


How does that fit with the Information Technology Infrastructure Library (ITIL)? Well, on a scale of 1 to 5 where 5 is best probably about a 10.


Why so high?

• ITIL is indifferent to the device technology used because it is concerned with the strategic, design, transition, operations, and improvement levels or layers working above the technology. ITIL deals with the thinking, organizing, and procedural aspects of running the IT business.
• It recognizes the most critical resource left out of the above definition – the people involved, as both a resource and a source of capability.
• Rapid provision of services depends on strong design, controlled transition, sound operations, continual improvement (particularly keeping in mind that fewer lifecycle errors leads to higher overall speed of provision).
• Being able to release with minimal management effort / service provider interaction hinges on sound, well executed process as encouraged by ITIL.
• And, availability (as well as the other warranty areas of capacity, contingency, and security) are well covered in the ITIL practices

In general, the more complicated the situation, the more benefit can be derived from other's experiences and best practices. Why make all their mistakes – again?


So then if an organization has a solid foundation of ITIL practices and processes, their various roles and responsibilities across the organization figured out, their IT Services catalogued, change and deployment activities under control, etc. then everything is perfect?


“Perfect” is a stretch (unless I am their Advisor). :-)


But I think the question boils down to:
Would you like to take advantage of the terminology, common understanding, thoroughness of checklists and process steps, clarity of roles and responsibilities, and structure of the lifecycle perspective that the best practices from ITIL have to offer, or be mediocre on purpose?


And that can be the difference between seeing the sun above the Cloud or getting rained on.


For more about ITIL and IT Leadership please contact me via http://www.BusinessImprovementResults.com

ITIL in The Cloud - 1

ITIL in The Cloud (part 1)

At the risk of sounding like one of the Four Yorkshiremen in the Monty Python sketch talking about how rough their childhoods were...


When I was a lad I had to get up before going to bed, walk barefoot through ten foot snowdrifts, and write Assembler code and such for mainframes such as the IBM 360, DEC PDP-10, and Xerox Data Systems Sigma 7. (Yes; Xerox Corporation was briefly in the mainframe business after buying Scientific Data Systems. And their research facility really did inaugurate desktop networked Personal Computers etc. long before anyone else. All fascinating stories for another time.)


And in those days of mainframes closeted in well protected data centres we had to play by the rules – for access, usage privileges, changes, etc. - because the strict governance of these million dollar babies was crucial to the owning organization, and careers.


Today we have, ta-da, the Cloud.


So as we begin to operate “in the Cloud” should we toss away everything we learned fifty years ago, including solid business practice for managing computing resources and services such as the Information Technology Infrastructure Library (ITIL)?


A business associate, Will Shook, writes as he starts up another information technology and services company [Accelerence, LLC]:

The issue at hand for me is this:  we built a model around computing many years ago and very good practices were developed in the glass house.  Then we went to client / server computing and everybody forgot everything about controls and processes.   Skip forward to the cloud and it seems everyone has forgot about good governance once again as they get focused on the technology, but not predictable results from the technology.  Good governance is more important than ever now, given the sharing of workloads, the mixed model of asset ownership and operation, and the preponderance of devices, data, and access methods.  ITIL should be a huge win in the world of the cloud.

Absolutely should be!


As the technology gets more complicated, and the management of it gets more complicated, and the difficulty of understanding what is done for whom, by whom, and under what circumstances increases, doesn't it make sense to take advantage of good business practice?


In fact, for those organizations who have developed thorough IT Service Management processes with ARCI tables, Service Portfolios and Catalogues, strong Operating Level Agreements and Service Level Agreements (just to note a few) moving to the use of Cloud services is easier.  At least they know what services they are talking about, can plug in new roles and responsibilities readily, and pinpoint service level requirements and dependencies.


If you are about to change some or all of your computing model isn't it nice to know in detail what you do today, how you do it, and have insightful and directed questions for your new Cloud suppliers?


Beats walking barefoot through ten foot snowdrifts!


For more about ITIL and IT Leadership please contact me via http://www.BusinessImprovementResults.com

Simple Rules and Tools - Ask for Help

Asking for Help even when you (think you) don't need it.

I just cleaned out one of the eves-troughs on our house. It seems hardly worth a blog post to announce that. Nor was it particularly remarkable in any way:

• it wasn't higher than the reach of our standard ladder
• it was above the deck at the back of the house so the footing for the ladder was solid
• the blockage was ordinary – just some accumulated leaves
• and the spot requiring attention was self evident because that's where the water was overflowing the lip of the trough on to my feet on the deck

On the other hand, yes, it was pouring rain at the time. (After all a hole in the roof only leaks when it is raining.)


So why did I go out in the rain, in a rain slicker and boots, scramble up a wet ladder with the slicker's hood blocking my vision, reach over backwards to grope blindly in the eves-trough, in very cold water, to find the blockage of soggy leaves, to deal with this problem?


Well; the point of the eves-trough is to direct water away from the basement wall so it doesn't end up in the cellar, and that clearly wasn't working very well. And the waterfall from the trough onto the deck made this disconcerting “water-is-running-into-the-house-and-all-is-lost” sound.


But, of course, the underlying reason is that I hadn't cleared the leaves away during the lovely warm sunny weather this past weekend. In fact I hadn't even checked to see if there might be leaves in the trough, even though I have to do that for my Mum almost every time I visit her at her house.


Aren't humans fascinating? We have the capability and resources to plan in advance the most outrageously complicated stuff, but we still wait until its raining to fix the roof – or eves-trough.


We see this effect when it comes to Asking for Help. It's startling clear when there's a problem and a solution is needed that asking someone else for thoughts or advice is a good idea. In our Simple Rules and Tools for Great Teams Immersion session that becomes obvious, particularly when we tell folks at the start of the session that the tool “Ask for Help” is the single most important and valuable one to learn.


But it's trickier to appreciate that Asking for Help is even more valuable when it is not raining problems. Because the steps in the tool aren't simply ones to get answers, but are also ways to open oneself to others – their knowledge, insights, experience, and contributions. And that helps us to put our own knowledge into perspective, take ourselves a little less seriously perhaps, and forge a stronger more meaningful connection with that other person.


And you don't have to wait until it's raining to do that.


Find out more about the Simple Rules and Tools for Great Teams at http://www.BusinessImprovementResults.com/news.html and get a free copy of all the rules and tools known as The Core Protocols at  http://www.BusinessImprovementResults.com/whatresults.html

Simple Rules and Tools - Perfection Game

Making something better and better

The other night at the Aikido dojo some members were tested and successfully achieved their next level of ranking. Immediately before the tests all of us worked through a regular class which usually has us start with practicing a very basic and simple technique and build on it towards a pretty startling movement.


To the casual bystander this approach can seem odd. If I am learning to spin my opponent around me almost horizontally, force them to the mat, and then secure them immobile, why should I spend time practicing having them grab my wrist over and over... and over?


Where's the cool drag them one way, clothes line them across the neck in the other direction, take them off their feet using their own momentum, and have them slam down on the mat, all with a flick of the wrist, twist of the hips, hardly needing a deep breath?


Well, of course, Aikido isn't about being “cool”, or slamming your opponent, who is actually more your partner in an intricate dance than a real threat. At least in the dojo.


And the whole development of these intricate moves occurs step by step, just like learning to fly an aircraft, or any other criteria-based instruction. When one can demonstrate satisfactory performance of one task or movement, then one can progress to the next step.


In particular, at each step one can review, evaluate, and improve to develop a firmer foundation for the next step.


This continuous building and adding to achieve a startling amazing result is one thing Great Teams practice doing during the the Simple Rules and Tools of Great Teams Immersion. The Tool is called the Perfection Game. The initial “movement” is simply whatever idea or proposal is suggested for the team to consider from one of the team members. That person asks one or more of the others to “Perfect” it, and the protocol begins.


It's a very special, structured, and positive form of feedback:

• it only occurs at the requestor's asking
• it indicates how much value the responder is hoping to provide to improve the suggestion
• it covers the aspects of the suggestion the responder likes with only positive comments
• it indicates any improvements the responder would like to see to make the suggestion as close to perfect for them as it might be – the value the responder is adding

That last step is where the continual building, improvement, and adding value occurs, particularly when the whole team is involved – either at the same time or in stages.


So if you like the opportunity for continuous improvement – kaizen – in your martial art, your flying, driving,... whatever, or are just looking to make an idea better in any situation the simple tool the Perfection Game protocol is ideal.


Find out more about the Simple Rules and Tools for Great Teams at http://www.BusinessImprovementResults.com/news.html


Get a free copy of all the rules and tools known as The Core Protocols at  http://www.BusinessImprovementResults.com/whatresults.html


See our example of the Perfection Game at
http://www.youtube.com/watch?v=40a4Lf0hsaI&NR=1

Effort vs. Results on a Great Team

There's another interesting and important exchange underway in the Core Protocols Group forum (http://tech.groups.yahoo.com/group/TheCoreProtocols). This one is about the relative merits of effort versus results.


As with all these discussions – in this forum or any other medium – a lot of the debate revolves around the meaning, and the implications, of the words used. For example, from Peter A.:

I think we're getting caught up on multiple interpretations of "effort". On the one hand effort refers to "the number of hours spent doing something", which is how it's being used in the results/effort ratio. On the other hand, I think the article is primarily using effort in the sense of "applied oneself diligently against a defined standard with realtime feedback" (i.e. Deliberate practice). While more is better in some sense here, the key point is that this kind of practice is a good thing vs. not practicing or ineffective practice.

and:

... there are multiple interpretations of what "results" mean. If results include the ability of the individual/team to produce more/better output in the future at less cost, the strategy/math for optimizing results/effort is different than if you only value output for the current time interval.

The “article” referred to above is The words that could unlock your child (http://www.bbc.co.uk/news/magazine-13128701) which has the punch line

This reveals a radical new approach to the way we engage with children - that we should praise effort, never talent; that we should teach kids to see challenges as learning opportunities rather than threats; and that we should emphasize how abilities can be transformed.

and even a comment left on behalf of Einstein!: 

This from Einstein:

"I know quite certainly that I myself have no special talent; curiosity, obsession and dogged endurance, combined with self-criticism, have brought me to my ideas."

Since my operating slogan is “It's not about effort – it's about results”, I can't avoid weighing in on this issue.


Let's set aside the unanswered questions from the article about how we encourage children versus adults, and whether or not we praise talent, or ability, or hard work, etc., and the words we choose in each situation, and with each personality – all complex adaptive systems!


My slogan is to make the point that in any enterprise, effort that doesn't finally produce a satisfactory result isn't truly effective and hence worthwhile. We can't get distracted by claims of hard work, and even true hard work, if it doesn't deliver. And please note I added the word “finally” to cover the obvious examples of practicing, failing, recovering, trying again which are all necessary efforts for most of us to build skills and competence to achieve a goal.


The real point is that effort all by itself with no achievement except fatigue is not a valuable  commodity. At least in the exercise gym fatigue is an indicator of potential muscle development. 


Nonetheless, when did you last go to the store to buy “effort”?

Well, Mr. Reeves, our company employees worked night and day to design, fabricate, and ship this product. We didn't actually get it operational, but we worked really hard at it. How many would you like?

Jeez, boss, I was here till midnight working on that analysis for you and I know you needed the answer for that important client sale this morning. Although I didn't get it done, I really worked hard at it.

You know I haven't taken a vacation in 3 years!

It is certainly NOT that effort isn't required. We don't go to the “Results Tree” and pick results off the low hanging branches. But if we praise effort without results, or in place of the required results, then we are not being smart. At the worst we are deluding ourselves that somehow hard work (and what is truly hard?) is an acceptable alternative to an actual achievement. (Scan all the news reporting from the United Nations, and governments in general, to see examples.)


And if we are in business, and only concentrating on effort, then there will definitely be a final result and that will be failure.

Leadership on a Great Team

In the Core Protocols Group forum (http://tech.groups.yahoo.com/group/TheCoreProtocols) Jose Ramón Diaz started an interesting thread on the question of leadership on a team using the Simple Rules and Tools of Great Teams – the Core Protocols.

His question is:

“What's the role of leader on a team of this kind [one using the Core Protocols]? I am thinking that a true team using ... the Core Protocols, doesn't need a leader, but on the road to perfection, it will be needed, I suppose.”

After some answers from other forum members, Jose Ramón continues:

“The work of a leader in this kind of situations, is to not be necessary. I agree, but I find much resistance to this idea.

For you, that I suppose have experience with *great teams*, is it negative to have a leader? If there is a leader, is the team in pursuit of a shared vision, or could it be that some people follow the leader instead of their own (shared) vision?"

Since the Simple Rules and Tools of Great Teams – the Core Protocols – provide for dynamic leadership behaviour from any team member, the issue of the boss / manager / leader role can be a sticky one.

Particularly before one attends the Immersion session and learns the Simple Rules and Tools.

Particularly for the team leader!

To answer Jose Ramón, I find it helpful to be more precise and explicit about the use of the term "leader". We often use the word to mean a role in a hierarchy, and also to mean a behaviour with outcomes, such as people following.

In the Simple Rules and Tools of Great Teams Immersion (aka. BootCamp) the Managers in the simulation play the role of leader in that they assemble the team, hire consultants to help, provide the team the assignment, and monitor progress and quality of the product. At the same time, anyone on the team can behave as a leader by, for instance, proposing a course of action in a Decider (the Tool used by Great Teams to make unanimous team decisions) which the team decides to follow or not.

So the first is a leader position in an organization chart sense, the second is dynamic, changing, emergent behaviour.

The resistance Jose speaks of is usually organizational position protection. For example: I declare myself the team leader, or I have been appointed the team leader, and am going to protect my position and resist being declared unnecessary. And usually with good reason, since in most organizations teams want and wait for the leader to tell them what to do. Or at least are expected to – by the leaders!

In the Great Teams Immersion session, it is ideal to have the organizational leader present. This lets them realize that they can share the leadership behaviours with the team and be an equal with the team members in matters of developing and improving the vision, ideas, product quality, etc. It's like getting the leader's paycheque without having to do all the work.

The hard part is often getting the leader to accept that meritocracy (starting with them learning to listen well, and not get in the way), and sometimes just as hard, getting other team members to step up to the responsibilities and accountabilities of the Core Commitments to let their leadership behaviours emerge.

So having the leadership behaviours in the team is wonderful; they just don't have to come from the organizational leader on the team.

Agile vs. ITIL

A little while ago an associate in the Agile Coaching community, Yves Hanoulle, asked me about the contention often raised that Agile software development practices don't mesh with the ITIL Framework.

On the surface, Agile practices are a solution to provide faster speed of software delivery than alternative development techniques, and the ITIL Framework with its focus on process appears to slow things down.

For example: Yves had a conversation on Twitter where someone said that continuous deployment is not possible with ITIL. Yves wrote me to say that he thinks that is “horsefeathers” [my word] because they don't understand ITIL. He continued: “I think a lot of ITIL people are using it as a prescriptive way of working. And I don't think it has to be like that.”

I agree.

We have always believed there is no discrepancy between Agile and ITIL. In every conversation with Project Managers and Agile folks about how Agile is not “waterfall development” and therefore doesn't fit with ITIL processes, we have shown them that this makes no difference.

Consider the questions of automation or traceability.

Both the Design and Operations books in version 3 of the ITIL Framework are very clear on the interdependency of Design & Development and Operations, in terms of:

• the design meeting specifications,
• that all of this can be confirmed by tests,
• and that Operations staff need to be able to provide input to Design to ensure the systems are operable, robust, and maintainable.

It is much more than the question of automation or traceability - it is a mindset / mental perspective of the integration of knowledge - and finally teamwork.

Let's break this down into more detail:

1. continuous deployment is of course possible, even if one, incorrectly, took ITIL as prescriptive.
2. even the so called "ITIL experts" argue about "implementing" ITIL word for word from the book which is not the intent
3. ITIL recommends using - adopting - the best practices, as they suit the organization and its needs. Again it is not law, it is a Framework. One uses the best practices as they make sense, just as you do in Agile. And where an ITIL practice can make an improvement one should use it, just as in Agile.
4. it all boils down to keeping the Great Teams commitment to not do anything dumb

Often people believe that rapid deployment / continuous deployment / daily builds etc. can't work in a an environment that is highly process oriented, where rules and process have to be followed. (Usually they just don't like someone else's rules.)

Well, the process is there to ensure consistency, responsibility, accountability, communication, traceability, etc. and of course it CAN be designed to be a hinderance. It. alternatively, CAN be designed to allow quick passage of releases. People blaming process or ITIL are just being immature. They may as well blame the weather.

The meaningful question in such environments is: What has caused the development of process controls to ensure such an approach for the management of risk?

• are the controls in place to reduce the error rate?
• was the previous situation causing buggy software to be released which impeded the business?
• has someone mis-interpreted the intent of the ITIL Framework and used it as law?

I'd be delighted for someone to find me an example of how ITIL recommends that the process gets in their way. So far in these conversations I find the combatant has yet to read the ITIL books.*

How does Agile play with other frameworks in your experience?

*By the way: I haven't read books on Agile either. However, the Core Protocols include the Intentional Development Protocol (an Agile foundation stone), and I am informed by Agile coaches such as Christophe Thibaut, Gino Marckx, Yves Hanoulle, and Esther Derby who recently posted STILL NO SILVER BULLETS (http://www.estherderby.com/2011/03/still-no-silver-bullets.html) on Agile methods.

Software for Your Head 4

Finishing the project team kickoff meeting story from Software for Your Head by Jim & Michele McCarthy.

(from page 8):

Well, hell, if he did all that, you would consider him to be all the way checked in. Hmmm. What’s more, you think maybe, just maybe, that scenario might just do the trick for the whole damn team. Tell you what, you’d bet your bottom dollar that his teammates will at least respond with their fullest, focused attention. That’s just what people do whenever someone reveals himself a bit. If he’s talking and acting with just the least little bit of enlightenment, something new, they’re going to listen up and watch closely. As long as the person says what he says and does what he does with thoughtfulness and truth. But if it is true, you’d predict that the team, just by witnessing a more honest, genuinely new engagement level, will then be much more likely to act on questions of shared vision (which, you remind yourself, is the top-level symptom). At least, you figure, they’ll be more likely to act on things they care about, anyway, and that would be all to the good. Moreover, everybody who watched this thing unfold from just one person will have been really informed, and maybe even inspired, by the difference made by his acceptance of personal accountability for how he has been spending his own life. Really, not only for his own results, but for the results of all.

You half listen to the team struggling to cram everything in the agenda in the last few minutes. Maybe the others would also begin to experiment with the new power they are seeing and feeling (and there is tremendous power in accepting individual responsibility for achieving results together). If your guidance would help one or more of them to engage more deeply, and not to waste any time and never to do anything dumb on purpose, why, you’d have made a huge difference. Hell, the dumb quota can always be met by doing things you thought were smart to begin with. You don’t have to do anything dumb on purpose to meet the quota.

You imagine that a newly awakened team member would see a whole bunch of things, maybe all at once; the problem is not a case of a team without a shared vision, a case of just another stupid project, or another example of bad management or poor leadership. No, when he thinks it all the way through, he’ll see that the trouble is not “too few people,” or “not enough time,” or some other cockamamie story about how the mediocrity was out of his control. The crux of the thing is that he, personally, has been accepting less than he wants, and less than he deserves. What’s more, he has been doing so without making any genuine creative effort to get what he requires to efficiently create what he wants. He’ll see that the problem is his own lack of integrity and his shallow engagement. The problem is rooted somewhere near his deficient caring about his own life. To persist as it has, the problem requires his repression of passion, it mandates that he fail to accept his own wisdom, and it seduces him into daily acts of cowardice that promulgate rather than abolish the general foolishness of which he is such an important part.

But should just this one person truly check in, you think, the whole team will be moved to a better ground. Even if team members backslide, and all do,they won’t forget this vivid instance of accountable behavior and the simple, unambiguous actions that supported it.

One self-respecting person, you reflect, with even a modest degree of personal engagement, is all it takes to start this team on the path toward much greater achievement. No permission is required for the pursuit of greatness, no consensus to improve your own results. All the orgs and re-orgs in the whole damn corporate universe, all the resources consumed and processes proceeding can’t stop one honest person from making sure he spends his time wisely. And that’s all that is needed to get the ball rolling.

Why not believe, you think. Pretend. OK. So from this one moment of surpassing individual and dawning team clarity, this whole group will quicken, will revive. Of course, team members will need some new supportive structures; they’ll require whatever information there is about highly effective connection and collaboration. In particular, they’ll damn well want more moments of clarity, and will be willing to adopt whatever practices create just the right conditions for genuine checking in.

They can’t hold it, probably. And would they spread it around? You have a spike of unease, but then you reassure yourself that the team you are envisioning would of course look for any behavior patterns that would achieve its goals. If there weren’t any, team members would just figure a way to create them. And put them in a book.

But first, one of them must check all the way in. Just one. Who? All this, after one of them has decided that his life, time, and creative output really do matter. But not before.

Interrupting your reverie, your nascent vision, the meeting suddenly stops as people scatter and depart, ceasing to meet rather than finishing their work. Finishing is way different from ceasing, you muse. As you gather yourself, one of the team newbies, together with the team’s most infamous cynic, approach you. You bet they want your take on things. Your help.

So that's the kickoff meeting that we've all been to, and all have wished was better.

What have you done in this situation? Thoughts? Comments?