Archive for the ‘Teams’ category

On Hiring An Agile Coach, How to Setup for Success

August 9, 2017

Hiring agile coaches is still very much a standard practice. Many organizations hire a cohort of coaches spread around the organization to help teach, train, and lead the teams towards their specific goal of agility (usually related to: better quality products delivered in a shorter increments).  There are indeed many benefits to agile coaching in the right circumstances (i.e. the team wants the outside help). The most critical time for ensuring success with a coach starts before the engagement – the pre-contract setup meeting in which current state, obstacles, and expectations are shared.  The team or its leadership asking for a coach must reflect on its current state, the state of the product (direction or strategy for the future), the dynamics of the team, external factors, the governance and software development processes, and its main points of pain (quality, speed, effectiveness – ROI). The team needs to have a sense of where it wants to focus its improvement so that it can become more responsive in its delivery of high quality software. It will hire a coach accordingly.   In a general sense, the team will have reflected enough to know that – with respect to agility – it is 

  • stuck in one or more patterns, that prevent quality or productivity, or general effectiveness. 
  • needs additional clarity about specific goals; and ways to reach the goals.  
  • has either communication or motivational issues which require individual or team coaching
  • wants to own the change….and the results

Given the above, the setup meeting I envision will encompass the following two topics: Goal Setting and Investment Thinking

Goal Setting: The coach and coachee (e.g. leadership and team) generate a common understanding of the specific goals as well as the skills, training, and facilitation needed of the coach to reach those goals. 

Goals should be measurable.  For example, if code quality is the burning issue preventing frequent delivery of features, then a coach versed in quality issues, software craftsmanship and Test Driven Development (TDD) will be suitable. The goal might be to reduce escaped defects by 50%.  Each agile coach has her own ‘book of knowledge’  on topics in the following areas (not an exhaustive list):  team dynamics, psychology, communication, organizational learning, management, agile methods (e.g. Scrum, XP, Kanban), processes and tools, systems thinking, software development, product ownership, lean startup, technical practices (e.g. TDD, ATDD, CI/CD), and scaled methodologies (e.g. LESS, SaFE, DAD).  It is important to find a fit that suits your situation well.  Find out more about the coach candidates and their strengths.  Broadly speaking, we can divide coaches into process coaches, technical coaches, and leadership coaches (focusing on communication and motivation) – but all coaches will be versed at a high level in many of the listed areas and have depth in a smaller number of areas.  

When needed, a coach should be able to call on other coaches in the organization to fill in any gaps.  For example, an agile coach focussing on process and methodology should be able to find assistance with CI/CD – DEVOPS expertise and bring in a short term trainer to fill a gap on the team they are coaching. A technical coach who is less comfortable with running retrospectives, should be able to ask someone with that experience in team facilitation to fill in.  The coach should be able to measure the goal and help you achieve it.

Investment Thinking: The coach shares with potential sponsor/hiring manager of the agile coach the ways in which they and the team will need to invest in the coaching. 

 If this step is skipped, you will encounter many bumps.  It is not uncommon for there to be some resistance to coaching involving change.  Many times it is due to pre-existing schedules and deadlines that are said to be ‘fixed’.  It can be due to fear that some might have of losing their jobs.  If we assume that ‘learning’ is the biggest impediment to a transition to agile, and that learning takes time, and we know that ‘there is no time’, no coaching will help. A coach running behind the busy people telling them what to do, just in time, will also fail.

Agile coaching involves the team learning new habits, and communicating in different ways about the work. Initially there will be knowledge transfer through training; knowledge acquisition (cementing the classroom knowledge) will come through the hands on work.  Doing is believing. A team that is willing to drop their own resistance and invest in some new ways of working together and communicating together will succeed. Management must support this. 

A coachee (leadership and team) will benefit most from a coach when they can recognize and verbalize their own resistance patterns and be open to talking about it.  A good coach will help them recognize these patterns early on.  Any team undergoing change will first experience a dip in productivity before the gains begin to take hold.  The timeline of a coaching intervention will be heavily dependent on the context, culture, and the size of the team.  Expect to have the team spend some portion of their work on learning and improvement.  Expect to experiment, and learn from failing too. This is learning.

General Principles of Coaching

If then, the initial improvements and goals are agreed to; management is invested in its own and its team’s ongoing learning activities;  and the skills of the specific coach are aligned to the desired improvements, the coach will come on board with a higher likelihood of success. The very best coach will seek to minimize the touch time with the team over time, and leave them in their own best state for learning on their own.   

The coach will be a powerful observer whose general stance will be to keep the team on track and to help them stay accountable to each other.  Although the coach will often wear the hat of a trainer and facilitator, she will, as much as possible, apply the general principles of coaching, namely:

  • A coach focuses on the agenda of the coachee (the goals and improvements they wish to achieve). The coachee decides which goals or problems to work on, not the coach. The coach can help them discover what they want most.
  • A coach uses powerful questions to generate new learning. The coach does not teach or advise, but asks questions and listens.  During coaching, the coach will help the team by facilitating sessions to find out more about the goals and areas where the team is stuck.  Many questions will be asked and orient the team towards finding solutions.
  • A coach encourages action. The coachee develops his or her own action steps, rather than waiting for assignments of the coach.
  • A coach supports change. A coach follows-up to support personal learning, growth, and change.

The reason we want to see general coaching principles applied to agile coaching is quite simple:  a team will feel more ownership, and the coach will be helping the team to generate its own best way forward.  Specific skills and knowledge of the coach can and should be brought into the mix when absolutely needed. However, it is much more powerful for a team to become a learning team, not reliant on the coach for spoon feeding answers.  A coach can help the team feel confident in its own choice, or steer them to select a new option if the first choice is not in the team’s best interest.  Only when the team is stuck, unable to think of options – should the coach provide an answer.
It is no wonder my recent tweet 
got so much attention.

There is so much work to do to teach people how to learn on their own again. It’s an art they have somewhat lost in the top down style org

This is what using the coaching principles can add.  If you have read “The Goal”, by Eliyahu M. Goldratt, you will understand the power of these principles.

_________________________
This post was written from the vantage point of my own prior coaching experiences, many of which did NOT work out or align in the best way possible.  I have just rolled off what I hope is my last ever gig in an organization where agility is mandated and the teams do not genuinely request the coaching.

In the coming year I will be investing in Systemic Modeling training with Caitlin Walker who has achieved major cultural turn arounds in organizations seeking change with as little as 9 days of training, spread over a year with off and on remote coaching after that. I credit much of my thinking around the Setup process described above to her ‘Clean Setup‘ technique.

To hear an account of the effects of Systemic Modeling coaching, watch this video.  This type of work inspires me, and I hope that in the very near future, I can find engagements to do exactly this sort of intervention.   I am not giving up completely on agile coaching, but I will apply the above Setup criteria to whatever opportunity comes my way to ensure I am not ever in the position in which managers and leaders feign wanting the coach in a mandated agile program and then fail to invest in the coach when the coach is present.

Temenos Retreat – Finding Humanity in the Workplace

May 9, 2017
Temenos Retreat 1

We laughed in amazement towards the end of the retreat after we posed to take this group picture with my selfie-stick. Why? Because we only had to take one shot to get a perfect one. There was no awkwardness or hesitation in creating this picture. Everyone is at ease, smiling, eager to create the memory of our together time.  

My first Temenos Retreat facilitation took place on May 7th, 2017.  Seven participants joined with me in an intense day of reflection, sharing and learning.  I am grateful and honored to have hosted so many amazing people who were willing to be vulnerable in order to learn with others. I’ve written this post to reflect on seven ways in which the Temenos Leadership retreat improves our ability to experience humanity at work:

Connections with Others

The foundation of connection in Temenos is the story telling we do with Influence Maps at the beginning of the retreat. From this we find the rich threads of shared experience by recognizing and acknowledging what others have done, how they have been influenced, and how they have overcome their struggles.  Temenos takes us back to quality relationships as we practice sharing our personal history and building our shared vision in small group settings.  Taking these practices back to the workplace means that we can now model this connection-making in the teams we work with, manage or coach. 

Intuition/Feelings/Self Awareness

The biggest taboo in business is to expose one’s feelings. Businesses and people could thrive if there were safe ways to express emotion. Organizations that wish to thrive need the kind of leaders who can pave the way for this. Such leaders must learn to become self aware and confident in sharing their feelings and intuitions. In addition these leaders learn to listen for for what is alive in others. Temenos participants become more able to do this as they witness others doing so. 

Meditation

We can think of Temenos retreats as a way of rebooting ourselves, meditating with others about our own life and work/life. It’s an emptying of our past disappointments and an appreciation of what is happening right now.  Breathing in and out, and cleaning the slate for renewal.  

Confidence Building

Temenos ‘containers’ are the spaces we create in relationship with others in a pair or group. Much as a child learns to walk (falling, and trying again) with the loving surrounding of parents and siblings, adults can also be more influential with the support of others.  A workplace that fosters love is one where the network of support is strong, people know each other like a family and also support each other without blame or placating.  We gain confidence acting in an environment of support. 

Risk-taking

Leadership means going beyond what might be ‘normative’ at work, and taking a risk to do something a little differently. When we encounter stress at work, we might often revert to past habits that are not effective.  In my version of the Temenos retreat, we learn about the work of Virginia Satir and her Congruence Model to explore this angle. At the end of the retreat we practice scenarios from work, learning how to improve our responses to stressful interactions.

Doing the Right Thing

Congruent Leadership meshes well with the idea of ‘Doing the Right Thing’.  Congruence means that we act and speak in accordance with our feelings, our intuition, as well as in balance with the context of our environment.  In Temenos, the context is the social container we are in and considers our self-acknowledged strengths and the feedback we get from others as well.  Doing the Right Thing means not only listening to one’s own feelings, but listening to the needs of others and striking a balance – but not running from conflict, discomfort, or uncertainty.  In the end, in any toxic, rigid, or politically plagued office environment, we learn to have more joy when we have ‘agency’ – meaning the power of choice in how we react to other people.  

Collaborative Mindset

In Temenos and with other tools that I care about such as Clean Language and Non Violent Communication, sharing and listening lay the basic foundation of collaborative work. The more personal sharing we do, the more supportive, empathetic and creative we can be with one another. We can dare to build on each other’s great qualities and to experiment with our ideas when we are bonded and aware of each other’s humanity.  

Agile Assessments as a Burdensome Weight or a Guiding Enabler

January 28, 2017

A few years back when I was a coach in an enterprise wide agile adoption program, I had my first head-on collision with a mandated agile assessment program.  At that time, I decided to get all my thoughts into a drawing which I’ll show you here, unaltered from that time.   You can see my view that assessments can be seen as either a burden imposed from above or as a supportive tool for the evolution of the team’s capability. You don’t have to read the text of the drawing, as I’ll cover each item below.

assessments-in-agileLet’s parse the Burden Side. This is where the two folks holding up the assessment say: ‘Feel awful we’re not good enough, and we’re not sure how to get there’

Hard to support in its entirety – a huge questionnaire may point out so many gaps in maturity and it leaves a team with the sense of overwhelm. We know that change does not happen all at once. It can’t.  If unpaired with dialogue and a strategy for improvement, the assessment is of no use.

Not outcome oriented – an assessment is devaluing  the business value/metric of what was delivered  by examining predominantly the process/methodology by which that increment is delivered. That seems backwards.  The delivery should be in support of the business outcomes – which is what should be measured.

Not Context Sensitive – one size evaluation fits all. Usually these types of assessments are not combined with narratives or qualitative interviews, and so we are assuming that we could be comparing like things via this numeric approach.  We know large organizations host systems that are so wildly different from one another that forcing a like evaluation should never produce a side-by-side comparison. Yet, these assessments are used for just that, in many cases.

Misses mindset –  the human element of change – the mindset shift that is so critical in causing an organization to change its way of working – is not elevated.  Assessments will always miss mindset – there’s no way to codify that other than through storytelling, the vibe, the cooler talk, the openness and engagement that manifests in a healthy organization

Cognitive Overload – an assessment with a huge number of prompts will be immediately forgotten by those to whom it is administered.

Misunderstood as a Rating – even if the issuer of the assessment believes in their own positive intent, the teams having to take the assessment see it as a measurement.  Measurements provoke a ranking system which is almost always seen as judgmental, evaluative, and unrelated to the needs that those in the improvement program have to actually improve

Appears as a Mandate – well no need to explain this one. It wouldn’t be a burden if the team had self-selected to take its own assessment, by choice!

Without Conversation, May Cause Misunderstanding – my head was in the sand when I wrote this- in fact I should have written ‘May’ as ‘Will’.  There is nothing easy about working in an agile manner at first without support, leadership, love, hope, and belief in the people doing the work.  Leaders and executives mandating assessments without having conversations and opening up channels of communication with those they are assessing are burying themselves in the myth of big data.

Let’s parse the Guiding Enabler Side – this is the side where the two folks standing on the strength of the assessment are saying ‘Now we know where we are heading’.

Supportive – we see the breadth and depth of what’s possible in an agile project and can use the ideas to self reflect on what improvement to make next.

Foundational – we can use the assessment framework to fully vest in the whole enchilada over time such that we don’t forget areas of improvement we might not initially consider.  Without a foundation, each person may have their own pet improvement projects, but we need to vet all options and agree on the way forward together

Provides Focus Points – we don’t have to do everything at once. We pick a few related items to work on before we move to the next.  

Used As a Launch Pad for Conversations – this means that we can take one assessment prompt and talk about what it will be like when we have that, what it will take to get us there, why kind of support we can ask for from each other and from management. We never shelve an assessment, we have conversations using it.

Agnostic As to How Assessed, by whom, when, with whom, for whom – it isn’t mandated. The team uses it voluntarily whenever they decide to use it.  With great coaching and willing learners, and opt-in view, this can’t go wrong or be gamed

Understood as an Improvement Baseline – this means that we can track our progress over time if we choose to continue to look at the assessment as a means of self-reflection

Views Follow-up Support For Learning as Critical – everyone acknowledges that assessments are not the point, the learning that happens in-between is.  Therefore, the surrounding organization should be happy to provide whatever is needed to help the team reach the next level

Can be Tailored-Narrowed to Context – we can choose to not focus on or even to not fill parts of the survey depending on where we want to focus energy.   We want to eliminate waste, and that includes eliminating survey elements which don’t apply at a given time.  They are there, but we don’t use them, for now.

Launches New Practices – for learners who love to create great products that meet client needs, the assessment is a way of reminding the team that we can do more, that we have a never ending supply of ideas, practices and experiments to address in our agile journey. The assessment can help launch those.  That could be an exciting prospect.

What would you add to either side of this analysis?

_________

I am VERY LUCKY to be an Agendashift partner, with an amazing Slack community where the challenges of coaching well are discussed very openly with a lot of mutual support.

Mike Burrows has developed the most wonderful Agendashift assessment tool that is used in exactly the way I describe above – it is supportive of generative discussions on how best to create a change strategy that is context sensitive.  [If you are interested, let me know and I can help you get this launched in your organization]

In the Agendashift community of coaches, we teach coaches how to use Clean Language questions to explore the assessment prompts and what people would most like to work on next.  It is a generative approach that builds on the energy already latent in the organization.

These assessments are not used to compare teams, or to provide executives a hands-off data driven view of their agile adoption progress.

This is an amazing community trying to shift the way agile transformations are initiated so that they may be truly transformative.  It takes courage to stand up for what you believe when you are in an organization that wants to go in the other direction.

Thank you Mike, Suzanne, Jussi, Olivier, and Thorbjørn for your support last week!   I am glad I remembered my old drawing!

The Limits to Treating Only ‘the Parts’

November 15, 2016

Often the symptom shows up in one place but is caused in reality by a different part of the system.  

Question: What domain am I talking about?  

If you are a consultant or coach, or even a PM reading this blog, and you have read something about systems thinking, you’ll realize I am talking about projects or teams that run up against systemic or organizational impediments that affect their work

If you are my chiropractor, you’ll know I am talking about the body.

Why do I like this metaphor?

I have spent over $1000 this year treating myself to frequent sessions with a very good chiropractor and to excellent massages with his associated massage therapist.  I initially went to this doctor complaining about my right foot.  He discovered very soon, that treating the right foot would not resolve the issue.  He noticed that on that same side, the quad muscles were too short.  They were pulling at my back (which also had pain, but is now gone), and causing me to walk a little funny.

While the foot isn’t yet 100%, I do feel treating the whole system (body) is leading to better results. [I thought of this post while lightly jogging on the treadmill – proof of my better state]

Another thing I learned is that the way I had used chiropractors in the past was incorrect. I had gone a few times for a specific issue, and then stopped going when the local issue went away. I did not have the foresight or knowledge to understand that ongoing maintenance could be incredibly beneficial.  That means regular visits – whether every two weeks, or once a month. I prefer every two weeks.  His sessions last a full hour with a mixture of electric stimulation, ultrasound (full body), adjustments, and massage.

The analogy to the workplace and using a consultant is this: when you have had a coach help you set up a relatively stable agile way of working, with an established cadence or planning, working, demos and retrospectives, you still need to have the coach come in every now and then to help you redirect your attention to other parts of the system .  A coach helps you see the parts that you are biased in some way to overlook.  So does the chiropractor.

 What things are you working on that might benefit from a more global view?

Remotely Audacious At Agile Atlanta Conference

July 27, 2016

sococo_2016-Jul-26

You can see the Kubi on the table…

This week I participated remotely in the Audacious Salon at the Agile2016 Conference in Atlanta. My friend, and fellow coach, Mark Kilby was leading a session for attendees to to brainstorm solutions to the many challenges teams face when some of the team members  are not all in the same place (i.e. working at a different office, from home, in a different country, etc.)

 

 

At the audacious Salon, I connected via a tool called Sococo – which has virtual rooms, in which you can connect by chat and video conference with  co-workers, spontaneously.  I was one of about 7 to join, including two from London.  

2016-07-25 10.58.28

The view for me of the other remote participants and the slide deck used at that moment. 

We could hear each other as well as the conversation at the table, and we were included during the introductions, but it became apparent how easy it is for the in situ people to forget about those who are joining remotely.  It takes some practice and discipline to overcome this hurdle. When one person is remote, act as if everyone in the room is remote.  What I love about Sococo though is the ability to spontaneously connect with co-workers and know where they are. Easier than email, cell phone, text, and much more effective for making connections, and getting information quickly. It is no silver bullet for all the issues on remote teams, but an interesting newish way of connecting remotely.

Me_Kubi_teleporting to the Netherlands

Teleporting to the Netherlands to see Lisette’s office space on a Kubi

I was also able to join at the ‘table’ in Atlanta, by ‘tele-porting’ into the Revolve Robotics Kubi device, which I could control remotely to check out who was at the table.  I could swivel it up and down and left and right. This enabled me to see all the people at the table without bothering them. Scroll left and right to swivel. Up to see the ceiling, down to the floor. For a fantastic example of how distance learning can be enhanced using the Kubi, watch the first few minutes of the video entitled Zoom On Kubi webinar at the Revolve Robotics website.

In a conference interview with Josh Fruit, of Solutions IQ, Mark Kilby shares that success with remote teams is not really about tools, but rather, the degree of connection between people.  He asks: 

          How do you make sure you have connection on your team?

This is not just an issue with remote teams, but one that exists on many teams. My company,  Connections At Work, has the explicit goal of improving connection no matter where the teams are located.  A few of the goals your leadership or your teams would be striving for if you asked me for help can be gleaned from this collaborative teaming article in the Harvard Business Review.  It is all about team emotional IQ.

There are a growing number of people who are collecting the body of knowledge about teams that work remotely.   One is my friend Lisette Sutherland who works in the Netherlands. You can visit her Collaboration Superpowers website and her podcast for a wealth of information. Her co-conspirator on many projects is Pilar Orti, working from London. You can see her activities, podcast, and blog posts at Virtual Not Distant.  Judy Rees is also highly qualified to help teams get the connections going remotely and has a wonderful blog post on this topic here.  Thanks to Mark Kilby and Jesse Fewell for continuing to explore, experiment with, and promote a distributed way of working in the agile community. 

As I’ve just completed the Collaborations Superpowers course, I’ll be able to start giving the same training to others who need it.  So if YOUR team needs help with the challenges of partially remote teams or connections on any team, do be in touch – contact information is also on my Connections At Work website.

Collective Intelligence with Mob Programming

May 8, 2016

 

2016-04-30 16.19.08

I returned on May 2nd from the first ever Mob Programming conference in Cambridge, MA.

Many people from around the world (US, England, Finland, Denmark, France, Africa, China, India) gathered to learn from Woody Zuill, Llewellyn Falco and others about a relatively new phenomenon in the IT world – that of groups interacting in the same (head) space to maximize the (coding) results while using the collective intelligence of those present.

The premise of  mob programming or ‘mobbing’ as it is sometimes called, is that people will learn together how to ’turn up the good’ in the team and in each other to the benefit their customers. The result is less time spent churning, estimating, waiting for answers, deciphering someone else’s code, fixing bugs. The greatest possible intelligence is collected into the code in a focussed and collaborative manner with the whole team (analysts, testers, programmers, and other specialists, as needed). When paired with solid tests, written first, this technique is a great way to produce high quality software that is more easily maintained. It operates more like a great team of scullers on the Charles River than a traditional IT shop.Harvard Crew

What happens in the majority of organizations that produce software is that most code writing is done by individuals using different styles at different times, at different desks, without much consultation – yet with the hope that the disparate parts will be able to be integrated.  In the status quo organization, there is not much attention paid to the ecosystem that the code ‘lives in’. Sometimes people are moved from team to team like chess pieces for short term gains.  Teams are treated as temporary constructs. The resulting software may appear cracked in places, and mis-understood, poorly formed in stressful situations.

If one developer wrote it and no one else understands it, the future ability to modify such code will be diminished. Therefore, the best way to have great code now and in the future is to put many minds at the same task, at the same time, in the same room (virtually or physically). The likelihood is higher that the best ideas from people will emerge and be used when people collaborate this way. 

2016-05-01 11.31.39I got to experience this first hand myself. I took part in a small group of coders who had to code the solution to a small problem together. Only one person ’the driver’  is allowed at the keyboard at a time and this person is not allowed to type anything other than what others in the room agree to have them type.  The screen is projected so that everyone can see.  All ideas and code must be verbally expressed and transmitted to the person in the ‘driver’s’ seat. The first time we did this, we had one designated navigator – who could direct the driver. The driver stays in the driver seat for a very short time – perhaps 5 to 15 minutes, after which the person who was driving can become a navigator and contribute again to the ideation about what to work on next, taking input from the others.  I very  much enjoyed learning and participating in this, and certainly felt there was no hesitation in people sharing their ignorance or their knowledge. Everyone learned.  In the conference setting, there were numerous opportunities to do this at beginning, intermediate, and advanced levels. The beginners used simple coding katas, and even some ‘koan’ lessons for learning to code in a new language.  Everyone had fun.

We also used simulations using other tools to teach about mobbing. One group, that I participated in briefly, produced an article for InfoQ as a mob, writing together in a very short time.  Another group used the card game ‘Set’ (which was invented by Llewelyn’s mother) to simulate a mob session for solving the puzzle.  Done in several rounds, once with a single navigator, then later with no single navigator (giving directions), it clearly shows how messy it can get -when first starting out – to have a group of people giving directions all at once.  But I observed that the time constraints work well in combination with a self-organizing team. The team learns best with trial and error how to moderate itself and inquire of each other before directing the ‘driver’ to take action.  In fact, after each change in the driver, we held a mini retrospective: each person contributed their ‘aha’, or passed.  Mobbing groups are encouraged to experiment.  Some teams are even working this way when not co-located, using video and screen sharing software.  As others have pointed out, great teams develop implicit and/or explicit protocols – you can read more about such teams here.

Whether with coding, or with non-coding simulations, the best individual performance on a challenge is almost never as good as the performance of a team of possibly less ‘able’ individuals. I took this lesson away at a wonderful simulation activity at Amplify Your Effectiveness conference in 2010. We compared the performance of individuals at estimating ten ‘Guinness Book of World Records’ to the performance of teams that worked on the same challenge together.  We observed that it is never the team with the best individual scorer that wins the team competition, even with the same 10 records repeated. 

I am quite sure that I experience both peaks and troughs in my productivity throughout the day.  I would be thrilled to be able to lean on other teammates and vice versa to ideate and produce the best possible products and deliverables.  If only managers could give up a fixation on ‘time spent’ on code, in favor of frequent delivery of valuable code for the business, I bet they would experiment with Mob Programming and find it very beneficial. And ‘valuable means too that it will be more easily maintained in the future – it won’t only be the tech lead who makes decisions and knows the history of the code’s back-alleys.  It will be collectively understood.

Finally, as you will read from Woody’s writings, and from his talks on mob programming, this technique should never be something anyone can or should mandate.  Teams should be left to choose their best way of working and be encouraged to experiment with their collective intelligence.  

I really appreciated the people who travelled from afar to talk about and practice the principles of mob programming and I would definitely attend this conference a second time.



If you need a facilitator to help you get started, please reach out to me. If you wish to read more about Mob Programming, you can read Woody’s book and Llewellyn’s books here and here and watch the time lapse of a day in the life of a team that mob programs.  On May 18th, I’ll be giving a workshop on The Core Protocols (another great team productivity enhancer) with an open discussion about mob programming at the end. These two ways of working and interacting are quite awesome for the audacious and courageous self-organizing teams.    If you are in DC, you can RSVP here. You do not have to be a woman to attend.

A last note: at the end of the conference, I offered up the idea of creating a community book about teams that are coding using the Mob Programming principles. It would involve interview questions and answers about the teams’ experiences, perhaps modeled along the lines of the Who Is Using Clean Language, Anyway? book. (That book is itself modeled after Who is Agile? book that I helped edit years ago). I would need a co-author and a couple of teams to volunteer for interviews to get started. It would evolve as a Leanpub book until we had a great cross section of teams from around the world representing different domains and challenges, perhaps 20 or 25 teams.  If you are interested, please leave me a note below or contact me via Twitter at @andreachiou

McCarthy Bootcamp and The Core Protocols – Experiencing a Team with Shared Vision

June 30, 2015

I attended Jim and Michele McCarthy’s team-building workshop – in April 2015.  It was an amazing experience learning how to create great teams within the span of one week using the The Core Protocols.  If you’ve never read of them before or want to familiarize yourself with them, you can download or print the Protocols here or buy a small printed version here.

I went to Bootcamp because I am tired of workplaces where I cannot see the innate energy, skills and gifts people have.  I see lifeless disengaged employees and I want that to change. I wanted to experience working in a different way, for a week, where people feel connection. I want others to benefit from what I learned is possible.

In this Bootcamp, experimental learning requires an individual commitment to use the protocols, including all of the built in safety features. One of the first instructions to Bootcamp participants is: You are entering a simulation and you must pretend that the Protocols will work during the simulation.  There is no doubting their efficacy during bootcamp. Use them. Experience them. You will see the results.  It’s like entering a new building. You cannot appreciate fully from looking at the floor plans alone.  I believe it is in the doing that we learn how and why.

Before Bootcamp, we had a 100 page pre-bootcamp reading assignment to prepare us for this journey. We came from about 7 different nationalities and continents – we were about 15 people in total including a 13 year old. Below I share just a few salient aspects of Bootcamp and below that some other links for those who are still curious. 

Personal Alignment

During the Bootcamp itself, before working on the product that we were assigned to deliver by the end of the week, team members get to know each other.   The Personal Alignment itself takes the the form of articulating a virtue (love, courage, trust, presence, joy, health/self-care)  – one that if the skies rained down this virtue in abundance, all the ‘blocks’ to your personal achievement would be removed.

This aspect is about individuals discovering what they want, disclosing it, and then asking the team for support in the form of a signal/response pair.   Supporting each other in getting those virtues allows the team to be be strong!

I see a lot of analytical, technical, engineering type problem solvers slaving away at their day jobs. I wonder if they find joy, connection, support, and a sense of being ‘in’ with their team on a daily basis… I wonder if they know that over time, they will burn out from not feeling connected to others at work in a deeper way.  One of the reasons I value the Protocols, specifically Personal Alignment, Check In and Ask For Help so much is that they bring this me a strong sense of being connected to each member of the team.  Work should bring joy, and with the connectedness and safety, people will produce at their best.

At camp we used the Investigate protocol to learn more about each other. It is a time of deepening relationships on the team as the Alignments are explored. One person on the team at my Bootcamp wanted more Courage.  When he shared his signal throughout bootcamp: ‘I want Courage’, anyone present at that moment would yowl like a wolf as that was the response he asked for!  Alignments allow for personal growth.  Folks are encouraged to write down the evidences they will have when they know they are exhibiting more of their virtue. They are encouraged to report those evidences to team members, and ask for help when they need it.  This is incredibly powerful.

Web of Commitments

After personal alignments, the team performs a  web of commitments ceremony in which all the alignments, signals and responses are shared. We also share our desired evidences.  It’s a beautiful creation – coming from the increased bandwidth, self-disclosure, getting to know one another.

Shared Vision

Before making products, we create a shared vision. This is a brief statement about what we want the world to be like as a result of the product we are making. We create the vision before we even know what product we will be making… it is very aspirational, very inspiring as well.  One feels lifted above the dross and worry of procuring the stuff we’ll need…. and we did need stuff – read more about that later in the Managers section.

Making Products

After the Web of Commitments, we go to work producing. Now that we are more deeply connected with one another, we will reflect our best selves in our products.

We continue to use  Ask For Help, Check In, Check Out, Investigate, Intention Check, Decider, Perfection Game, Resolution, Protocol Check liberally as we produce stuff – in addition to to sharing our alignment prompts. We are completely self-organizing using our communication tools and discovering and sharing our talents.

Our team made a lot of cool things. There were sub teams of people creating things like a Gong stand, a robotic proximity sensor with stuff bought at Radio Shack, paintings, a Greatness Manifesto, an emotion/check in cube, a game, music and so forth.  By the end of the week, our goal was to showcase our best product to the ‘Managers’.

Managers 

Jim and Michelle McCarthy who hosted the Bootcamp I attended played the ‘Manager’ role.   They showed up at times, as managers normally do, seeing how things were going, to see if we were using ‘Ask for Help’ protocol.  One of the big things folks get wrong with respect to management is not asking for help enough!  This is true on every Bootcamp they’ve ever run – and I’ve been noticing this a lot as a cultural phenomenon back at work. People who need things are afraid to ask for them! We had several team members who had been to a handful of bootcamps before, and they were not shy – and whatever support we needed (stuff to make our products), we asked for from Jim and Michelle, or just procured the items ourselves. Like some of the other newbies, I fell short of asking for help enough at Bootcamp by my own admission, but I’ve been practicing more since then. For example, I asked for a new laptop at my coaching gig and got it (the desktop I had was horribly outdated and slow, but I hadn’t thought to ask). 

I’ve been observing this lack of asking by others at work. It is a pervasive phenomenon that I had not really noticed much before. 

Closing Ceremony

At the end, we presented our best product to the managers.  We had everything available to see, but getting to unanimity on the product to showcase was HARD work.  Folks had invested a lot in some of the products, but because we had the ‘Decider’, ‘Resolution’ and ‘Intention Check’, ‘Check in’ and ‘Check out’ protocols, as well as our alignments, we were able to get all onboard and the best product out the door on time.  You can see our product, the Greatness Guild, and follow it as it continues to grow as an outcome of our team’s work.

McCarthy Bootcamps  demonstrate that installing ‘software for your head’ (the Protocols) magnifies a team’s capacity by helping people communicate!  See this invitation to the Fall 2015 Bootcamp and sign up now if you want to experience it.  

If you want to dig deeper on your own after reading this post, read Software for Your Head or listen to the McCarthy Show podcasts. A good podcast to start with is an interview with a Bootcamp grad who started using The Core Protocols at Microsoft.