Prioritising with Cost of Delay

This week the “Meet the Coach” webinar series delved into the interesting topic of “Prioritising with Cost of Delay”. The presentation went really well and we had many people listening, once again. It makes us happy to see so many people returning to our webinars, with new faces joining all the time. We hope to see you all again soon! 

Whether it is for large initiatives or items on the product backlog, prioritising work is something many organisations are struggling with. Some choices will have different impacts for certain stakeholders. Often it is hard to keep things objective, since there are opinions, ego’s, status and emotions involved. Ordering by value is not always as linear as you would expect. In many cases we are comparing apples with oranges, for example how do you compare an initiative to attract new users with quality improvements?

In the webinar we looked at different aspects related to comparing items and I explained the concept of Cost of Delay and how it can be used as a prioritisation technique. Below you can find some of my suggestions from the webinar. 

 

 

 

If you missed out on the webinar, don’t worry! We have the recording available for you. Feel free to share it around with friends and colleagues. The recording of the session is available on YouTube. If there is anything we can help you with regarding this topic, feel free to contact us.

 

 

As mentioned in the webinar, if you want to learn more about Cost of Delay, or how to work with stakeholders, how to make choices and how to be a good Product Owner – join a training with us! 

The Product Owner journey starts here.

Take the first step on the journey by attending Certified Scrum Product Owner training.

In this training you will learn the theory of the Scrum Framework and work through tools to enable great Product Ownership. The CSPO course is appropriate for aspiring Product Owners, business analysts, managers, project managers, and organizational team leaders seeking a deeper understanding of the Product Owner role, and how to improve Product Ownership in their organization. 

If you are already a CSPO, take the next step and deep dive with Advanced Certified Scrum Product Owner training . All upcoming trainings can be found online. Please bare in mind that in order to receive an A-CSPO certification it’s required to hold a valid CSPO certification with Scrum Alliance and validate at least 12 months of work experience specific to the role of Product Owner (within the past five years).

We run all our trainings both remotely and in-person! If your organization would prefer a private training, we can even look at customising the training for you. Get in touch and we can discuss the best solution! 

And don’t forget about the coaching. At agile42 we do a lot of role coaching, and the support we can give your Product Owners will help their daily work. 

I have shared the slides used during the webinar below: 

 

Here you can learn more about the Business Value Game. The Business Value Game is a tool for estimating the Business Value in software development projects, it helps Product Owners and Stakeholders in sharing information related to Business Values in a relatively short time. It avoids anchoring by asking each Stakeholder to play their estimate card so that it cannot be seen by the others and then all cards are exposed at once.

Here you can order the Planning Poker Cards. Planning poker is mostly used to estimate the effort or the relative size of tasks in software development. The members of the project team come together and estimate each item in a few rounds using the planning poker cards until the team reaches consensus on the size of each item or task.

 

For more webinars and recordings, please look here!
Hope to see you in the next ones! 

 

Starting a Scrum Team

This blogpost will give you insights into starting a Scrum team, with a recording from the webinar and some additional information to support you with this journey.

As with Scrum in general, starting a team is easy to understand but difficult to master. I presented a webinar on this topic where I wanted to run you through the finer points of starting a team. Starting a team is not just explaining Scrum and proclaiming: “Go!”. It is a process in which the level of complexity needs to be evaluated in order to determine the right approach to move forward. Will Scrum really benefit you? Once this has been established it’s time to get into the nuts and bolts. I discussed what steps need to be taken in the first few weeks and what to expect while establishing a healthy team. 

Since we are progressively stepping into a world where remote collaboration is becoming the standard, I created the opportunity for Q&A during the webinar where we discussed some interesting questions regarding remote collaboration as well as other pain points. This can be heard in the recording of the webinar.

For those who missed the live session, don't panic! Here you can find the recording, and it is also available on YouTube.  Have a look and feel free to share with friends and colleagues. If there is anything we can help you with regarding this topic, feel free to contact us

 

 

We would also like to share a few links that may be of interest to you. We have a Scrum start-up package for kicking off new Scrum teams, and this link gives you some insights into this service. We would be more than happy to walk through with you how we can help support your teams. Please keep in mind that e.g. the Team Kickoff can be done every now and then with the teams, and we strongly recommend this e.g. after summer vacations or winter breaks. 

As we mentioned in the webinar, if you want to take your basic learnings to the next level, we recommend Certified Scrum Master (CSM) training. At agile42 we are currently running this training remotely, and dates can be found from the listing. 

For more on the topic of team dynamics, you can always book sessions with a coach, and if you want to learn how to support your teams with this, please have a look at the Advanced Certified Scrum Master (A-CSM) training or the Advanced Team Coaching Course (ATCC) where you can boost your own skills. These trainings give you, as an Agile Coach or Scrum Master, valuable support to help you with your teams. 

We have all kinds of support for the Agile teams, and many of the steps that I listed in the webinar are services we can provide, so please connect with us and we would be more than happy to help.

 

For more webinars and recordings, please look here! More  webinars!

 

 

To Scrum Or Not To Scrum

I get many questions in my trainings, and one of the most common is when to use Scrum – usually preceded by utterances of “Scrum will never work in my team…” The wording of the question below comes from the Scrum Alliance Certified Team Coach (CTC) application. So this topic is relevant, and there is no one answer.

The Question

When might you advise a client to apply XP, Lean or a non-Agile approach to workflow instead of Scrum?

Let me answer this question by describing an actual situation. Read on for my thoughts.

The Context

I once coached a program of teams at a large corporate that had to automate a manual and laborious business process onto an off-the-shelf product. This program had been working in a waterfall manner for a year and had managed to automate a small subset of the business process.

A new CIO was employed and decided that this program needed to use Scrum because it would help with faster delivery. When I arrived this is what I found:

  • Teams had been set up, consisting mostly of contractors from different contract houses;
  • Most people had received an Agile Bootcamp training focusing on Scrum;
  • Project Managers were in-house and expected to be Scrum Masters as well;
  • Teams were supposedly dedicated, but the program manager repeatedly moved contractors in and out of the teams;
  • The deadline had already been decided by the CIO.

It became apparent that the teams were not set up for success and that the program would revert to using a waterfall process. I thought that by helping the teams focus on some of the principles of Lean without giving their way of working a label, that it would start them thinking about bottlenecks to their workflow and identify wasteful activities.

 

The Rationale Behind This Approach

Major organisational impediments which due to the nature of the organisation (size, structure, and politics) were outside of the teams’ control to resolve resulted in an interrupted value-stream, but for which they were being held accountable. Here are some of them:

  • Data sourcing – each business process was multi-layered with multiple data sources which the teams did not own nor have access to. Obtaining data required a long process with multiple approvals;
  • Environments – development, test and production environments were being built at the same time that the team needed them to do their work.

Program-level impediments:

  • Teams were not stable – people moved in and out without notice to them and the Project Managers;
  • No Scrum Masters – Project Managers were expected to also be Scrum Masters – this created a conflict of interest and anti-patterns began to emerge;
  • Teams did not own their full value stream and yet were held accountable for delivery;
  • Each business process to be automated was 1 large story because they were not easy to break down into user value items;
  • Teams consisted of more than 10 people and had 3 Product Owners.

I recommended that teams adopt Lean principles and visualise their work, in its imperfect form, and start improving where they could because:

  • The Product Owners were present and involved – there was a real effort on their part to help teams break their work down into manageable chunks taking into account the organisational impediments;
  • By visualising the workflow as it was they would start to see where all their bottlenecks were and having the teams and Product Owners focus on customer value they would begin to identify wasteful activities;
  • For me, it was also important to help teams see that their current process was not value-creating, and by regularly looking for improvements they would start to look for different ways of getting around that which was seemingly outside of their control.

There are other ways of addressing this type of problem, such as using a complexity frame and the Stacey Complexity Model. As with all things that relate to coaching, the context of the organisation and the maturity of the team are important. In order to help them become unstuck I guided them along this path and brought in the learnings of complexity later. I felt that this was, for these teams, a useful place to start.

What would you do? Please tell me below.

Webinar: What is Coaching?

There’s a lot of talk about coaching nowadays. Having a coaching approach as a leader is repeated over and over again as a highly valuable competence to have in today’s work environment. But what is Coaching and what is it not? Is it always a suitable approach or are there situations where we shouldn’t use it? How does Coaching relate to Agile Coaching?

We discussed these topics on February 4th in our live webinar. If these are questions that are puzzling you in your role as a Leader, Scrum Master, Agile Coach or in any other role, this recording may be for you.

You can watch the webinar here or on YouTube.

Slides are available on SlideShare.

 

To be informed of new webinars, subscribe to our “Meet the Coach” Meetup Group.

Team dynamics

Exercise for Systemic and Relational Engagement Utilising The Market of Skills

It can be challenging to get a ‘snapshot’ of a team as well as to get the value clear that each team member brings on a relational as well as a technical level. The following describes a brief exercise that can help facilitate a session to help with this.

The Idea

  • Make ‘hard’ skills visible
  • Make ‘soft skills’ and interests visible
  • Get a physical representation of needs or wants
  • Improved relationships and insight into each other’s views
  • Highlight the value of synergy of skills
  • Make latent/unused potential of the team visible
  • Get some sort of physical representation of the communication lines in the system

The Exercise

Each team member generates a set of skills that he would like to make known to the rest of the team. A good method to facilitate this is by allowing 5 minutes for silent writing and self-reflection. The skills can include hard skills like eg. ‘I am a Java expert’ to more unknown personal skills eg. ‘I am a chef’.

  • Make sure to ask an open question to elicit this but create flexible boundaries that leave space for divergent thinking and personal exploration. You will most likely encounter resistance here since some team members will not be used to these types of open questions. Make clear that anything is ‘good enough’ and there are no correct answers.

Have each team member create a poster containing all the skills that he has written down. An example poster can be seen below.

Market of Skill example

The entire team walks the room together and each team member gets the opportunity to briefly explain his poster to the rest.

The team members now individually walk the room and make notes of the ‘skills’ that they would find useful from other team members. They would, for instance, generate an A4 page per person listing the items that they are interested in, categorized per team member excluding themselves. Each person should end up with a list specifying which skills/characteristics he would like to either assimilate or know more about from other team members.

Next, prepare some rope and a set of scissors. Make sure you have enough rope. Around 100m should do the trick depending on the size of the team.

Market of Skills example

By the team gathering together and each team member sharing what he finds valuable from other team members, the team will start to self-organize to create a ‘mesh’ representing their intertwining needs. This is how it works:

  • Person A takes his turn. If he is interested in a skill from person B, he will share the need (verbally) that he has with person B and then present him with one end of a string while holding on to the other end.
  • The team member whose turn it is will complete his entire round before the next one takes his turn. Guide the conversation in a direction that stays relevant and help the members keep the conversations concise and short.
  • One link between two people is sufficient but make sure the conversations happen when taking turns even if the link already exists. There will thus be a single link between person A and person B independent of how many ‘skills’ he is interested in from that person.
  • This will continue until every member has had an opportunity to speak.

Outcome and Value

A visual representation of the system presenting needs as well as necessary and current communication.

  • In one example the PO added all his PO skills to his poster but no PO skills were ‘purchased’. This is quite a significant insight into what the team sees as the role of the PO.
  • The same case existed with the team manager, he offered some technical skills to the team but it became clear that they expected him to resolve challenges on an organizational level.

Key team members which might present a risk to the team by either being a dependency or dominating the team can be highlighted. Simply count the number of connections to a person and it should become clear.

The team realized that they were not as needed as they initially thought and that the team had a lot of capacity available to pick up the slack.

Conversations were started which were socially focussed instead of purely business-focussed eg. “We never knew that you were a chef we need to try your food” OR “Wow, you build robots in your spare time…like Skynet.”

If a concrete outcome is expected from the session, it can be useful to note some retrospective actions. The main purpose of the exercise, however, is to have good open conversations.

Examples

An example of a team with healthy communication lines and is well balanced in terms of relational and/or technical skills.

Market of Skill example

An example of a possibly more hierarchical system where there are some possible unhealthy dependencies on a key team member. The team can decide how to address this dependency in order to limit the risk to the team.

Market of Skill example

Things to look out for

  • Someone who physically separate themselves from the pack when doing the exercise. This comments on how included they feel.
  • Individuals who do not want to make use of the skills of others. I have had someone ask: “Am I allowed to buy my own skills?”
  • Expected outcomes such as: “We would like a table or document showing ABC.” If your intent is not to use the conversation to get more insight into the system, helping the team to do the same as well as to facilitate good conversations, this is not the exercise you want to go for.

Cheat Sheet

Market of Skill cheat sheet

Download the Market of Skill cheat sheet

a microphone that is sitting on a stand

A word from our coaches

We have asked coaches Richard Dolman, Daniel Lynn, Jakob Verner, Dave Sharrock and Andrea Tomasini to sit down for a short video where they tell us about the coaching culture at agile42.

As Daniel puts it “From day one you’re both expected and welcome to join into any conversation going on in the company.”  We are happy to have built an environment where coaches have autonomy and can grow professionally. If you want to be a part, check our career plans.

You can watch it here or on YouTube.

 

clear wine glass on brown wooden table

Combatting Observer Bias in Coaching with the Team Coaching Framework (TCF)

In research, psychology, and any other field in which someone is intended to be an impartial observer, there is a phenomenon known as the Observer Expectancy Effect, or Observer Bias. This bias happens when an observer expresses their thoughts and expectations about a situation through tone, word choice, and body language in a way that influences how the people they are observing behave.

The observer expectancy effect can be subtle, but it can also be quite profound. In some research, the observer has been shown to unconsciously change the way a subject performs in a test based on whether the observer was told they were “smart” or “dumb” subjects.

Right about now, you’re probably thinking “Well I wouldn’t do that! I’m a professional!” and there I have bad news for you. We all do it. Because it’s largely unconscious, we can’t help it. The only way that’s been found to consistently address the problem is to not have any expectations, and that is really difficult. Even if we can enter a situation with none, human nature causes us to start forming them very quickly. As coaches, our opinions and unconscious biases can mislead or misdirect those we are coaching. Therefore, it is important that we are aware and careful of this effect.

At agile42, we use a structured approach to change on teams called the Team Coaching Framework (TCF) to limit or negate the impact of any observer bias we might bring to the table.

Structured Coaching through Coaching Cards

In TCF, we leverage a structure that helps us avoid jumping ahead of ourselves in coaching. This structure starts with observations, then makes hypotheses about why those observations exist, co-created with those we are working with wherever possible. Once we settle on a hypothesis to work with, we set a goal and ways to measure that goal. Finally, we select tools to use to help get to this goal. Following this structure pushes our own opinions as far out in the process as possible in order to reduce the likelihood of influencing the process accidentally.

Micro-Observations

“The ScrumMaster is the center of conversation for the Daily Scrum.”

Does this sound like an observation to you? It isn’t. It’s actually an inference about a pattern of observations. If that sounds pedantic, that’s ok – in many cases like this, it is a fair inference about a real pattern. But when we come to our hypotheses, this nuanced difference might really matter.

When we look at the actual events that occur, we may see that every person only speaks to the ScrumMaster. Or, we might see that people primarily speak to the ScrumMaster but they also update the board and occasionally speak to each other. Both of these patterns could be expressed as the ScrumMaster being the center of the conversation, but in the first, we may hypothesize that there is a structural component leading to the behavior, while in the second it is clear that nothing is blocking the team from speaking to each other – perhaps there is social pressure or a habit leading to this behavior.

Reflecting back on these “micro-observations” can free us from anchors we’ve formed in our perspective.

Pairing or Coaching Groups

Having an extra set of eyes will almost certainly result in a different set of observations. Comparing these after-the-fact can help both coaches in removing their bias from the coaching. When doing this, the coaches can either decide to both watch everything or they can choose to have one coach focus on a very specific thing while the other takes a broad view in his or her observations. This second approach is particularly helpful when you are coaching a team through a particular challenge or new skill.

Multiple Hypotheses


One of the most common problems when formulating hypotheses is that we select the hypothesis that most closely matches our preconceptions or past experiences and then look for information that shows this hypothesis to be true.

In order to avoid this, we try to brainstorm multiple hypotheses in each coaching card. We will usually pursue only one at a time, but taking the time to come up with multiple hypotheses helps break us out of our own assumptions.

Coaching Tip: If you do this as a group, other coaches may come up with hypotheses you would never have thought of.

Invalidate Your Hypothesis


“It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” – Abraham Maslow

We are bombarded with a lot of information and our brain subconsciously filters out everything that we don’t think is relevant. When we try to validate a hypothesis, we can unconsciously filter out information that doesn’t support the hypothesis. This is called confirmation bias. One way to avoid this is to specifically look for information that disproves your hypothesis. Because you’re specifically looking for it, you are less likely to subconsciously filter it out.


Note: I recommend looking at the works of Robert Rosenthal, which primarily studied the effects of biases in childhood education.

selective focus photography of green iguana

The Lizard Brain

This topic is an excerpt from “The Hitchhiker’s Guide to Agile Coaching”, where agile42 coaches share their insights. Electronic copies of the whole book can be downloaded for free, check link at the bottom.

Cover of "The Hitchhiker's Guide to Agile Coaching"All humans have a hard-wired notion that change is dangerous. Over-reacting pays off in the jungle or on the veldt — those who scram away without thinking have a good chance of seeing their offspring grow up. And so we have evolved a mechanism for getting ourselves out of dangerous situations quickly and with a minimum of thinking. In fact, thinking is high on the list of things not to do. Those who start analyzing whether the waving grass really does conceal a man-eating saber-tooth tiger are more likely to end up analyzing the tiger from the inside.

Change and fear are connected on quite a deep level in our brains. As shown in the figure, when subjected to a threat of some kind — a threat to their habits, territory, or very existence — people go into panic mode and will either fight, flee or freeze.

Like all models, this model is incomplete: it’s a simplification of reality and full of holes and errors. However, we have found it very useful. It explains some of the reasons why people fear change and also helps make sense of why people react as they do in the face of change.

The lizard brain — primal reactions

The name lizard brain comes from fact that panic reactions are handled (mostly) by a part of the brain called the amygdala, which can be found just above the brainstem in all vertebrates. We share the amygdala with all mammals, birds and — as the name implies — with lizards.

When a vertebrate animal is subjected to a strong threat, the amygdala causes an immediate primal reaction. This is not a simple reflexive action: reflexes typically only yank a couple of muscles. But the primal reaction is still well below rational thought. The amygdala in fact prevents rational thought by subverting and disconnecting the upper brain functions. People suffering from primal fear are not only unreceptive to rational arguments but actually incapable of rational thought.

Interestingly enough for an agile coach, similar patterns can be found in prolonged situations of uncertainty, fear or anxiety, as is the case in e.g. agile deployments. Case in point: “We will pilot Scrum in the organization and your team is the best candidate!” In other words: “We say you Scrum.” Ouch! How do people interpret this?

Habits Most people are initially vary agile methods as they need to change their own working habits. Harsh corporate environments cause people to form their own patterns and strategies for survival and they may be very suspicious of “team work” and “collaboration”.

For example, we regularly meet engineers who have learned not to ever give honest estimates. They have formed habits of hiding the actual state of their work, giving vague reports like “90% done but we have some technical problems” or having a perpetual “coding” task that they move back and forth on the task board (When we see a task named “coding”, this gives us the signal that the team is tracking how they spend time rather than the outcome they produce.) Others feel that the daily standups are stupid — it takes weeks to implement this feature anyway so what need is there to report every day?

Territory Scrum can also be a threat to people’s territory. Former project managers that are now relabeled ScrumMasters or Product Owners suddenly find that they have lost a large portion of their former decision power. Deep specialists are forced to open up their work to the scrutiny of others. Software architects find that teams are doing unauthorized changes directly into the code base.

Existence Some people see agile methods as a threat to their existence in the organization. These include line managers whose teams are suddenly self-organizing; testers who learn that all testing will soon be automated; or specialists who learn that they are in fact not so special.

To the vast majority that is not directly involved in driving the agile transition, Scrum is a cause of anxiety or outright fear. How do they respond?

Fight Direct and indirect attacks. Badmouthing. Spreading fear, uncertainty and doubt. Passive-aggressive behavior in the Scrum meetings. “Here, let me help you with that… oops, so sorry.” Appearing to play along for a while, then a sudden explosion of this-will-never-work. And so on — the examples are countless.

Flee Some people grab the opportunity and move to other teams or escape the company altogether. The decision to flee is often made early, sometimes as soon as the news has broken, but it can take months for the fallout to appear. By the time people start understanding and accepting the new methods, they have already made new commitments and signed new contracts, and the decision is no longer reversible.

Freeze A surprisingly large number of people seem to lose their drive and become unable to produce anything of value for months on end. They are tapping on the keyboard and moving the mouse but nothing real comes out.

In almost every team we work with, we find examples of fighting and freezing, sometimes, but luckily very seldom, also of fleeing. This model has helped us make sense of why people behave irrationally during an agile deployment. As an agile coach, it is your job to navigate people past this stage of anxiety. The main problem is how to do that when people are not thinking rationally.

You will need to start by identifying and addressing their concerns, showing that the change is happening on their own terms. We have noticed that it is good to have a brief meet and greet with the team before the coaching starts. This could happen in conjunction with some team training or as a stand-alone meeting between 20 and 45 minutes in length. During the meet and greet we go through the upcoming coaching schedule, point out that we are here to support and guide the team, and underline that things will happen on their own terms.

With especially afflicted persons, we have also had good luck with informal one-on-one coffee discussions, alleviating their fears and giving ideas for how to move forward. Sometimes the best approach is to just listen and make it clear that you have heard their concerns. In the end, agile adoption is about teamification and while you may be able to help people find their new positions in the team, there are always going to be people who need to make some hard decisions for themselves.

Download The Hitchhiker’s Guide to Agile Coaching for free from here

body river surrounded by dress

Managing Flow

My next blog post is about “Managing Flow”. So many organisations I work with have benefited from using this technique to improve how they do what they do. I also felt it timely, since this is a key practice in Kanban, and Klaus Leopold will be coming to SA in May to provide two awesome two day courses on Kanban fundamentals, and scaling.

Traditional project management teaches us to manage resources and dependencies. Making sure everyone is busy is important because our plan is based on people optimisation and cost accounting. Managing flow in Kanban is the opposite of this and therefore often counter-intuitive.

Managing flow is a principle of Kanban and is about shifting the focus from the people to the work. So instead of managing people and keeping them busy all the time, we focus on managing the work and understanding how we get that work through the system faster.

The distinction is very important.

How do you manage flow?

Visualise

Well, the first step to managing flow is to understand where all the work in the system (by system I mean a human system designed to deliver value to the business) is. You need to visualise the value stream, and then visualise all the work in that value stream. Your value stream is the flow of work through your system, from concept to cash or beginning to end. This often depends on the level of granularity of your Kanban system. A good way to do this is to use a physical board, and to map your process from beginning to end. How does work flow into your system and how does it leave.

Limit WIP

Once you have the visualisation of where the work is, you need to begin to limit the amount of work in progress. Why would you want to do that I hear you ask?

There are many reasons to limit work in progress:

    • Create focus and prevent context switching: The more work there is in a system, the less focus any piece of work is getting. Context switching has a massive transaction cost and means that any single piece of work can end up taking longer than if there was focus around getting it done.
    • Decrease batch size:  Smaller batches mean faster feedback and shorter lead times.
    • Decrease complexity: The more work there is in a system the more complexity there is. Things that are deployed on the test environment affect each other. You need to manage all the dependencies that are created and the communication efforts of many more people. This all adds complexity and the higher the complexity the greater the risk.
    • Enable flow: The more work there is in a system, the more it will look like rush hour traffic and the less flow there will be. At 5:00pm in Sandton all the buildings in a four block area empty at the same time. The result of this is that the road infrastructure can’t handle the capacity and the roads become blocked and gridlocked. The same happens in software teams, and human systems when they have too much work in progress. By limiting the work in progress you can enable much better flow of work through the system.

 

Show blockages

Focusing on where the work is in a system, can help us have better conversations about which piece of work is the most important and where we need to spend our energy. It can also help us to see what is getting stuck. When something is stuck we want to visualise that. We want to understand first of all why it is stuck and second of all we want to make sure that our energy is focused on getting it unstuck. The tendency in systems designed for people optimisation is that the person whose current task is blocked by others will simply start on the next piece of work. The problem with this is that often the work item that is stuck is far more valuable than the next work item. Another impact of this behaviour, is that the ‘blocker’ gets moved into the background and forgotten about. It’s easy to forget things like that when there are another hundred other items right behind the one that’s stuck. This also means that when the work becomes unstuck it ends up in a queue, and each queue will have an impact on lead times.

Continuous Improvement

Having the visualisation, the limited WIP and the blockages visible, will give you large amounts of information about how your system works and what is in the way of getting things done. This is now a great starting point for conversations on how your system and processes can be improved and what can be done to better enable the flow of work. Talking about the work and managing the work through the system, means that we are focused on delivering value faster rather than on keeping people busy.

Keeping people busy can lead to longer queues, larger batches, more complexity and longer lead times. Managing flow will create focus on delivering value faster, and uncovering the challenges that get in the way.

If you want to know more about this have a look at http://www.klausleopold.com/.

Why Coaching is Important

What is the Problem?

 

For people in 20th century organisations training was an obvious necessity. Just look at the still-classical organisation and see that it has a Training Department neatly tucked into the organisation chart just under Human Resources. (I hate that name…but I digress.)

 

Much changes in our post-industrial world where we think for a living, solving increasingly complex problems. Our paradigm for helping people be effective has not yet caught up.

What are the challenges?

    • We are solving hard problems. This requires the brains of multiple people to be aligned and work collectively to emerge solution options.

 

    • Failure remains stigmatised as something bad, rather than being recognised as an essential and desirable outcome of experimentation towards innovation.

 

    • We remain stuck in authoritative command-and-control cultures that fail to unlock the potential of people.

 

    • Employees acknowledge their own individual achievements, but less so their contribution to the result of a shared effort.

 

    • Managers have not yet grasped their new role as enablers rather than directors.

 

    • Most organisations reward individualism while hoping for teamwork.

 

    • …add yours here…

 

What is Coaching?

 

Professional coaching may be described as a method for helping a person or a team to achieve specific goals in their professional lives. Paraphrasing Kaltenecker and Myllerup: the coach acknowledges that the person or team being coached already has the potential abilities required for reaching the goals and the assignment for the coach is to help unlock this hidden potential.

 

An “agile coach” often steps into acting as a teacher, advisor, mentor or role model. Here she applies her own expertise to lead and guide the individual or team in specific ways. Yet as soon as possible she should return to a coaching stance to return appropriate the power balance to the relationship.

 

The diagram depicts the difference between when the “agile” coach is relying on her own expertise of the content as distinct from the systemic coach using her own ignorance of the full organisational context and applying curiosity as a powerful helping tool to build relationship.

 

Agile vs Systemic Coaching

 

Why Do We Need Coaching?

 

Ask any successful leader and she will tell you stories about the people who have helped her, formally and informally, along her journey.

 

In order to learn and grow we require honest feedback. Without enough trust, honest feedback is unlikely to be offered and received in a productive manner. Traditional work environments do not provide safety for trust to flourish.

 

And in the modern work context that requires collaboration to produce good results we need to develop new “soft” skills that we were not taught at university or technicon. Teams and individuals need to learn to be vulnerable to one another.

 

However it is not a given that we will ask for help. There are hard questions to answer, for example:

 

    • How do I recognise when I or my team needs help? Am I even capable of knowing what it is I don’t know (my blind spots)?

 

    • Why would my boss pay me a salary when I need outside help to do my job?

 

    • How does asking for help make me feel? I have to “lose face” to accept help from another.

 

    • …add your own…

 

In the South African cultural context where “cowboys don’t cry” and “boer maak ’n plan” it can be particularly hard to ask for help. And in the “controlling” and “competitive” styles of organisational cultures that still predominate worldwide it can be seen as a sign of weakness.

 

So many of us live with an unhealthy tension between needing help from others in order to grow, and the uncertainty about whether or when it’s okay to ask.

 

The coach as trusted external party is well-skilled and well-placed to facilitate the necessary conversations to help teams grow trust, deal with conflict and offer commitment that in turn lead to increased accountability and improved outcomes.

 

An Economic View

 

In work over nine years with more than 100 teams we have observed a marked difference between the extent and the pace of growth of individuals and teams that have received coaching and those who have “gone it alone” after, perhaps, a two-day training class.

 

An analysis of our own data shows a correlation between “performing” teams and the quantum of help. The sweet spot seems to be between one and two days of coaching per team member during the first year of transition. To be clear this includes all facets such as advising and organisational development. Our data does differentiate between individual and team coaching, yet clearly there is a need for both.

 

Benefits we have observed during and after coaching include:

 

    • Happier and more engaged team members

 

    • Reduced staff turnover

 

    • An increased sense of “we”

 

    • An increase in self-confidence and independence

 

    • Increases customer and stakeholder satisfaction through value delivery

 

    • Increased throughput and decreased “time to market”

 

    • Increased transparency and predictability

 

When asked how soon the benefits exceeded the costs, many clients have experienced improvement within a few weeks and the classic “J-curve” of change has not been felt. And it is not uncommon to hear “we have doubled/halved X compared with last quarter/year”.

 

Adding Perspective

 

Before we conclude that coaching is some “magic elixir”, let’s be clear that contexts differ and it is hard to attribute causality to a single element. Nevertheless we have many times heard “we should have got coaching earlier and had more of it”.

As Weick and Sutcliffe remind us in their excellent book about High Reliability Organisations, it is “a sign of strength to know when you’ve reached the limits of your knowledge and know enough to ask for help”.
¹Sigi Kaltenecker (Loop Organisationsberatung) & Bent Myllerup (agile42): Agile & Systemic Coaching
http://www.scrumalliance.org/community/articles/2011/may/agile-systemic-coaching

²Karl Weick and Kathleen Sutcliffe: Managing the Unexpected—Resilient Performance in an Age of Uncertainty (Second Edition, 2007, Wiley), page 80.