Coaching works great for change. Coaching is asking the right questions. It is not about providing answers. Every time you provide an answer to a person or team you take away an opportunity for them to self-organize, grow and learn. You take away an opportunity for them to take ownership of the change and get engaged. In the role of the coach your task is to create awareness and responsibility. Your goal is to help them discover what needs to change, how to change it and to help them actually implement the change.
Illusion Of Control
“The illusion of control is the tendency for people to overestimate their ability to control events, for instance to feel that they control outcomes that they demonstrably have no influence over.”
An interesting research on this topic, by Langer, Ellen J. published in the Journal of Personality and Social Psychology, Vol 32(2), Aug 1975, involves a lottery. People would either receive lottery tickets at random or were allowed to choose their own. Although the lottery is random, when people were asked to sell or trade their tickets, the people who choose their own numbers were less likely to trade their tickets then the people who received a ticket.
The interesting part of this research is that it shows that by having people choose their own lottery number the ticket became something of their own. The experiment showed that Illusion of Control encourages people to take responsibility for the actions they do. And that is exactly what you want people to do during the change. You want people to be the owners of the changes. And you need coaching to achieve it. People change at a much deeper level when people discover themselves what is best to do and decide themselves to take the appropriate actions to change.
Coaching on competences
In most of the companies I work with the development of hard skills is quite good. Often the necessary soft skills and behaviors required to work effectively and joyfully in teams are missing. In the Lean Agile adoption journey the people need to be supported in developing these soft skills. The coaching efforts should therefore focus on helping people develop specific competences. Some interesting competences in an Agile transformation are relational sensitivity, cooperation & teamwork, and results & performance accountability.
Relational sensitivity competence requires the following behavior:
- Notices non-verbal signs and asks about them;
- Reacts constructively to verbal signs that are emotionally loaded;
- Shows empathy and understanding of others’ perspectives on issues;
- Is aware of irritations and reacts constructively;
- Gives feedback and demonstrates understanding of information and communication;
- Demonstrates understanding and acknowledgment of others’ interests.
Cooperation & Teamwork
Cooperation & teamwork competence requires the following behavior:
- Provides feedback on team results;
- Values team results;
- Makes sure relevant information is shared among team members;
- Starts and actively supports improvement initiatives of teamwork.
Results & performance accountability
Result & performance accountability competence requires the following behavior:
- Helps team members where needed, so the team succeeds;
- Assesses team members and oneself on keeping commitments and the manner in which the commitments are met;
- Takes accountability for one’s own work and the overall work of the team.
In order to stimulate the coaching sessions you need some starting material. In life coaching, the coachee comes to the coach asking for help. Based on the questions of the coachee, the life coach starts to work. Sometimes the people involved in the change come to me with questions but most people do not. Those who are opposed to the change are especially unlikely to do so. You therefore need to create the need for coaching sessions. To have a basis for your coaching sessions, 360 feedback is used.
Competence coaching with 360 feedback
In 360 feedback people receive feedback from the people they work with, such as team members, customers and leaders. The feedback is on the person’s behaviors. A person receives feedback on the desired competences of relational sensitivity, cooperation & teamwork, and results & performance accountability. Based on the results of the 360 feedback you can start your coaching sessions. As a coach you discuss the results of the 360 feedback with the person and investigate what the person wants to work on. You then coach him during his change. The goal of the coaching sessions is to help the people to change their behavior so that they create and take ownership of the needed changes.
Lean Agile adoption can only be successful when the people themselves create the necessary changes and therefore are really committed and feel accountable for it. The path to Lean Agile adoption can therefore not be planned in full detail upfront. But the path towards adoption can only emerge, the path can only emerge by walking it!
In my little booklet I am writing called Emergent Transformation I discuss how you can go on your agile transformation journey. One of the things I use to make an initial adoption plan is a set of questions and possible answers that I call the Emergent Transformation canvas. The canvas is your guide to create your adoption plan by going through all the building blocks and answering the questions. By filling the canvas you create your transition backlog. After that you can order it by business objective and there you go; your first adoption sprint plan is ready! You can now use Scrum in your adoption journey.
In this blog I will only discuss the set of questions you can use to make up your plan. See below an explanation of the canvas.
Emergent Transformation Canvas
What are our business objectives? Why are we doing this?
The Business Objectives building block defines the objectives the organization aims to achieve. The business objectives are the reason why an organizations is going on the lean agile transformation journey. As the transformation leader you have to ensure the business objectives are crisp and clear so people can identify with and work towards them. Missing or vague business objectives gives poor sense of purpose and direction to those involved.
In the context of lean agile adoption the business objectives are formulated as a vision story including goals and forecasts.
How do we measure progress towards our objective? Are we moving in the right direction?
The Measures building block defines how the organization is going to determine if the transformation is on the right path. The measures identify how you are going to assess success, measure progress towards the business objectives and learn. In addition the measures are used to discuss whether the transformation process should stop, continue or change direction. Thinking about good measures and quantifying them is very powerful because it forces you to discuss exactly and precisely what you mean with success. This discussion increases understanding among all involved about what you are striving for.
Measures are defined on outputs and on outcomes. For example your transformation could produce shorter release cycles which is an output. The outcome could be that the business can successfully react to opportunities.
How does management support the transformation?
The Lean Management building block describes what management needs to do in order to support the transformation so you can achieve your business objectives?. What is it about our working agreements, policies and organizational structure that has to change? What is it that management needs to do to become a coaching manager and to manage knowledge. What are the changes that need to occur to focus on creating customer value and see high performing teams as a key asset?. You need to assess your current way of managing, decide what changes you are going to make and create your transformation backlog.
From the a lean agile perspective the way to go is to start learning as quickly as possible and use that learning to increase results.
Which practices align with our objectives? How do we build the thing right?
The Agile Development building block describes your plan to be able to build the thing right. It is about the practices you need in order to shorten the feedback cycle and support the business objectives.
Below some example practices for software development
- Test Driven Design
- Emergent Architecture
- Pair programming
- Exploratory testing
- Inspection charts
- Collective ownership
How do we co-create our innovative solutions?, are we building the right thing?
The emergent innovation building block describes how you are going to engage with your employees and your customers to really understand their needs. What do you need to do so the people feel comfortable to innovate their ways of working and the company can learn how to do agile?
The teams and organizations have to learn how to apply the practices in their specific context. How are you going to support them to learn and share their capacity to act.
The days that innovators could sit in a team disconnected from development, had enough time to analyze, think and propose grand innovation plans are over. The assumptions that you can predict customer interest, reduce risk by extensive marketing analysis and have the wisdom to know what customers really want are fundamentally flawed but are still common practice!
Working from these assumptions brings us long lasting, high risk, high costs innovation projects.
According to Jeffrey H. Dyer in his paper The Innovators DNA there are 5 essential innovation skills.
Five “discovery skills” separate true innovators from the rest of us.
According the Jeffrey H. Dyer the innovation skills are
Discovery Skill 1: Associating
Associating, or the ability to successfully connect seemingly unrelated questions, problems, or ideas from different fields…
Discovery Skill 2: Questioning
…Innovators constantly ask questions that challenge common wisdom ….
Discovery Skill 3: Observing
Innovators carefully, intentionally, and consistently look out for small behavioral details—in the activities of customers, suppliers, and other companies—in order to gain insights about new ways of doing things…
Discovery Skill 4: Experimenting
Like scientists, innovative entrepreneurs actively try out new ideas by creating prototypes and launching pilots…
Discovery Skill 5: Networking
Devoting time and energy to finding and testing ideas through a network of diverse individuals gives innovators a radically different perspective.
Innovation Scrum Team
True innovation progress starts once real customers experience your ideas and provide feedback to validate your experiment. Innovation should therefore be done by teams that cover the whole stream from customer engagement to delivering customer value. Teams that understand the customer needs, experience how their lives are affected and are able to create the solutions.
We therefore need to shorten the innovation cycle of
2. Developing and
Co-creation can be done in numerous ways. A fun and agile way for beginning with Co-ceation are Innovation Games®. By playing Innovation Games® you can practice all of the innovation skills mentioned above. The Scrum team itself can do the observations and process the results of the games. This will increase customer empathy and customer understanding among the people developing the solution.
Scrum gives you a framework you can use for developing and validating your experiments at low risk to get high value. The Product Owner can be the driver of low risk high value innovation.
I recently witnessed a leaner version of doing a norms of conduct using the concept of red cards, yellow cards and green cards! This approach focusses on the most important of all values… TRUST.
It goes like this:
Ask the team members to think about and write down on a sticky note issues, problems, actions, used language, anything that would harm the trust they have in the team. Three to five stickies is enough,
Next put a big red card and a big yellow card and a big green card on a whiteboard or wall. Explain that the cards mean:
A red card means totally unacceptable and therefore trust is broken. Do not do this!!!
A yellow card means pretty bad and trust is damaged. If you do this it is costly for me!
Green card means great that is the way I like to see things. Please do this!
Then ask each member to put his stickies at the red, yellow or green cards and explain what they mean. Use affinity diagramming along the way.
Finish the session with a group discussion writing down the top red, top yellow and top green stickies. There you are, first version of the norm of conduct done.
Moving from a hierarchical command & control organisation to an entrepreneurial networked organisation is quite a challenge. It is difficult step when a manager has to stop telling people how to do things, stop providing ‘answers’, stop making decisions for people, stop wanting to know everything that is going on and it is especially difficult to stop overruling people when things start getting out of ‘control’.
Below some frequently encountered issues that managers face that have to do with decision making and empowerment.
The manager goes past the team and gives a direct assignment to an individual of the team.
A manager that addresses and gives special assignments to an individual in isolation distorts the common purpose of the team and is breaking the trust within the team. The managers therefore impedes the team’s ability to self-organize. Trust within the team is fundamental because trust improves the quality of interaction and connections between individuals of the team. And we know that, from a complexity perspective, the quality of interactions and connections is of direct influence on self-organization. A common purpose is also fundamental for successful self-organization because it makes sure all individuals align in the same direction and balance each others mistakes.
Example: A manager notices that the quality of the system is not what it should be. He invites one of the team members to his office and gives him the task to make sure quality goes up and stays up. Now this individual goes back to the team and feels and is personally accountable for the quality. He needs to make sure it works and will probably check other people’s work just to make sure. Trust is lowered, common purpose is blurred, communications costs rise and self organization diminishes.
The team is not allowed to decide for itself
A self-organizing team must be allowed to make decisions themselves using some kind of voting technique. This is also true when the team is included in the decision making process of something outside the team. If a team is not allowed to make decisions using a voting technique for themselves the team looses the contributions from some of it’s members, undermines it’s collective knowledge and therefore is not self-organizing.
Example: A manager appoints a team leader or Scrum Master or Architect that has the authority to make decisions in the team. Just in case the team makes a stoopid decision or in case the decision making process takes to long or some other excuse.
The manager asks for input from the team and then makes decisions based on additional knowledge that the team does not have.
A self-organizing team should have all the information available to make it’s decisions or answer it’s questions. Radical transparency as Steve Denning calls it. If a manager asks for a recommendation or answer to a question from a self-organizing team it should give the team all the additional knowledge it has. The team can now consider all variables that the manager takes into account. If a manager withholds additional information the self-organizing team does not receive the correct feedback and cannot correct itself and co-evolve with it’s environment and self-organiztion fails.
Example: A manager asks a self-organizing team how much functionality they can deliver by the release date. The manager knows that the deadline can be extended and that there is budget for additional resources of any kind. The manager is going to use this information to decide which functionality he can drop, what to communicate to stakeholders and how much extra resources he will ask for. Please make the information available to the team so they know what is going on around them.
The other day I was in the expert panel at the Scrum Day Europe.
One of the questions from the audience was
If you could only choose one Scrum event, what would you consider the most important event?
People in the expert panel ofcourse disagreed to have a interesting discussion. Ken Schwaber said the Retrospective is probably the most important event because improvement is key in Scrum, others said the Sprint Review is the most important one and so on. I was left with the Daily Scrum and argued that the Daily Scrum is probably the most important event in Scrum. Let me tell you why I think so.
The Daily Scrum is used by the team to determine the plan for the day. If there is a problem or impediment reported during the Daily Scrum all the problem related data is right there, it is at most half a day old! The understanding of the data is still easy, the problem is still small and can therefore be handled easier and there is still a chance that a counter measure helps you in the current sprint.
The Retrospective gives the team time to reflect on the past sprint(s), work on team building and improve what and how it develops. The team comes up with better ways of doing things, defines experiments to try out the next sprint and utilizes it collective problem solving intellect. A disadvantage of the Retrospective in comparison with the Daily Scrum is that it takes place at the end of the Sprint. And that could be too late! The longer you wait to handle a problem the harder it is to come up with good solutions. You loose context while time goes by.
You can better deal with a problem while the problem trail is still hot! The longer you wait the more time you spend in the retrospective establishing a common understanding of what happened or ‘Gathering Data’ as it is called in the retrospective circles. Most teams don’t even gather any data as they start their retrospectives right away with “what went wrong and what went right” questions… and that is a serious problem!
So next to having a big PDCA cycle every sprint, I like to also have multiple smaller PDCA cycles during a sprint which gives a better continuous improvement. The Daily Scrum makes having the small PDCA cycles possible. And that’s why I think the Daily Scrum is the most important event.
I would have chosen another if I had first pick in the panel discussion 🙂
At my training classes the students get actually a bit disappointed when I tell them that Scrum does not solve many of their problems. Most of the students expect that Scrum will solve most of their problems and quality, productivity, predictability and value will be greatly improved. Well unfortunately Scrum does none of that!
Introducing Scrum in your organization does a lot of other things. The main thing it does is that it gives you a lot of very valuable insights. In fact what often happens is that you embark on the Scrum roller coaster and after a few sprints you realize that Scrum does not work in your organization for various reasons.
Scrum is very very hard and it just does not work here because we are special.
You are for example just not able to:
- Create small cross functional teams;
- Deliver tested, integrated and accepted software in short sprints;
- Handle all those disturbances that pop up from the outside during sprints;
- Have specialized people help each other on different specialization areas in a team;
- Deploy to production frequently;
- Produce code according to your well known quality standards every sprint
- Have teams dedicated to a product for longer time periods;
- Create real improvement actions during retrospectives;
- Find a good Product Owner to lead Scrum Teams;
- Steer development on value;
- Produce reliable forecasts and plans;
- Detail your requirements Just In Time;
- Get developers involved in visioning activities;
- Have performance testing be part of a sprint;
- Have architects that know how co write code;
- Have developers understand the domain;
- and so on
There are so many reasons why Scrum just does not work in your organization.
Well if you have so many reasons why Scrum does not work in your organization then Scrum is in fact working perfectly at your organization!
When you introduce Scrum you can suddenly see, if you are willing to face it, numerous dysfunctions or as I want to call them potential improvements everywhere.
Now the question becomes “What are you going to do about them?”. If you are not willing to do anything about them then there is no use in adopting Scrum!
Management, as always, plays a very important role. Is management continuing to work around the problems, that is doing a lot of rework and firefighting? or is management going to work on improving the processes and focus on problem solving?
That is the main question!
In a continuous improvement culture, management sets challenging goals. Once those goals are met and things stabilize and teams become happy and feel there is nothing worth improving, management changes something and creates unstableness upholding the same goals or even setting more demanding goals to achieve. That is what Scrum gives you, challenging goals you can use for continuous improvement. The goals must be very challenging as described in The New New Product Development Game.
The thinking behind this is that you need to create product to beat your competition today but that you need to improve to beat your competition tomorrow!
So there is no point in taking on a easier approach because Scrum is hard. Scrum challenges you to be perfect and that is, although you will never be perfect, exactly what you need for improvement.