How learning by doing speeds up learning

I talk and write a lot about co-creative leadership these days. When people ask me to name the key traits of a co-creative leader, I usually list the following five skills:

1. Being a voice among many in the conversation
2. Unleashing the leaders around them
3. Building capacity on their team
4. Dancing with the system around them
5. Encouraging learning by doing

This article is the last in a series that will explore each of the key skills co-creative leaders need to know. The fifth key skill we will explore together is how you can encourage your team to learn by doing.

Encouraging learning by doing

In many companies, the focus on results creates environments where employees believe they cannot take time to learn something new or try something different to become more efficient. This belief also exists within organizations adopting Lean and Agile practices, even though, at their core, these practices encourage teams and organizations to adopt a culture of continuous improvement.

How can we resolve the polarity in organizations between the need for learning versus the need for producing results? How can we foster a culture that allows taking the time to learn and try different approaches despite the ever-present focus on results?

This article explores learning by doing from different angles and attempts to shine a light on various ways that teams and organizations can speed up their learning curve by consciously taking action and learning from the results.

Learning with Lean and Agile

Both the Lean and Agile worlds encourage and value learning by doing. The Scrum framework pushes teams to engage in an ongoing PDCA (Plan-Do-Check-Act) cycle to continually inspect and adapt how they work and how they develop software.

For Scrum teams, the end-of-sprint review is where they inspect the increment of work they created during the iteration and examine what they have learned about their deliverables. Based on this knowledge, teams can review their upcoming backlog items and adjust when they feel it is necessary.

The end-of-sprint retrospective allows teams to inspect their current practices and challenges and then adapt accordingly by having the right conversations and creating an action plan.

A small development team I worked with was skeptical at first about how to make Scrum work in its environment, but the team decided to start and see what would happen. After the first sprint turned out to be challenging, the team adopted the following mantra: “No one is asking us to be perfect right away; they are asking us to improve every two weeks.”

That mantra created safety for the team, and at every retrospective, it found one small change it could make to improve something. Over the course of six months, the team went from being a team that mainly received leftover work from its peers because of its poor reputation to becoming a team that received more important, time-sensitive work because of its new reputation of delivering quality results in a timely fashion.

During its transformation, the team decided on its own to make a lot of changes it probably would have resisted if they had been proposed right from the start. Some changes served well and others didn’t, but by taking a regular look at how they worked, the team eventually found solutions.

When engaging with clients trying to transform their organizations with Lean and Agile practices, I often find myself telling them to expect many problems to come up at first. I also tell them they will quickly come to realize they had decided to bury many of these problems under various carpets over the years and now they need to manage them. Because the development cycles in Lean and Agile are typically short, these issues tend to resurface more rapidly and organizations are forced to handle them more often.

Learning to feel it in your bones

We can learn by doing at many different levels. Over the last few years, I have come to see that you can also learn to feel things on a deeper level, which I refer to as “learning to feel it in your bones.” I use this expression to point out that after experiencing certain situations often enough you seem to just know instinctively when something feels right or wrong.

In a business context, how can you feel something in your bones? To better explain, I suggest we explore some real-life examples.

I once coached a team lead who was working with a difficult software development team. The team members were disengaged and it was difficult for him to bring new ideas to the team without getting a negative reaction.

The team lead had an opportunity to work with a team from a different department for three months. When he accepted the role, we agreed it would be a great idea for him to use this opportunity to try new things that he could not convince his regular team to try.

He had varying degrees of success, but he remained excited about what he was doing and his new team appreciated his efforts very much. After two months, he knew how it felt to lead a team that wanted to work as a team. He knew how it felt to try new things and adjust based on what the team learned.

In one of our conversations, he shared that he did not want to go back to his regular team because remembering the negative energy present on that team made him feel bad and he knew something different was possible now. He needed to feel that difference to recognize it.

When we talk about feeling it in our bones, we need to be open to exploring a different space. To explain this, let’s talk about facilitating a brainstorming session in the business world.

What helps make a meeting feel as if it went right? In a typical business environment, we usually think of the mechanics of the meeting, which leads us to notice things such as:

• Did the meeting have a clear purpose?
• Was there a clear agenda and clear objectives?
• Was there a clear process to do the brainstorming effectively?

In a typical business environment, we could also examine the relationships between the meeting participants, which can lead us to notice observations such as:

• Who engaged in the conversations and who did not?
• Who got along in the meeting and who did not?

These are obvious points to examine and they are easy for analytical people to notice, but to explore the realm of feeling it in our bones, we need to begin noticing more subtle elements such as:

• How was the energy in the room throughout the meeting?
• Did some specific statements, comments, or words elicit a reaction from some of the participants?
• What did the body language of participants tell us?
• What did the comments or snide remarks of participants tell us? Were there things left unsaid or implied?

Feeling it in your bones is paying attention to such things as the meeting is happening and adjusting when you realize something feels wrong during the meeting.

Learning through experiments

We work in business environments where often, the focus is on quickly achieving results. In many companies, making a group decision can create long debates that can rage on extensively for the sake of making the perfect decision and not making a mistake.

In the last few years working with clients, I have discovered that when I have called attempts at resolving problems “experiments,” it seemed to empower teams to not have to make a perfect decision right away. In situations where the team just could not decide, we began by clearly identifying what we wanted to achieve and then we worked to pinpoint the first logical step to get to our goal.

With one client, we wanted to build a dashboard to better understand our project portfolio. We decided to hold a workshop to create a first dashboard and, during this working session, the team examined a team member’s proposal and wondered whether the proposed dashboard was enough to reach our goal. Instead of debating it, as an experiment, one team member proposed we build out the proposal on a wall and see how it looked with our actual project portfolio.

Once we built it, we started asking ourselves whether it met our needs. We explored what this new physical dashboard told us about our project portfolio and we also explored what each of us felt was missing from it for it to be more useful. Creating a physical dashboard on the wall allowed us to play around with different scenarios and we could see the results right away.

In 90 minutes, the team successfully designed a first dashboard all team members were comfortable with.

Experiments allow us to take a step forward toward our goal and explore something concrete. This step allows us to learn something useful, such as the real problems we will face instead of the potential ones we would just be debating. The trick is identifying how much information we need before we begin experimenting.

A good experiment has a clear learning objective and it also has a fixed time box. At the end of the time box, we need to take a moment to examine what we learned and identify the next step toward our goal based on this new knowledge. Remember, an experiment may fail, but you still get to take away what you learned from the failure and use it to identify what you will do differently in the next experiment.

Using the term “experiment” creates space for the team to fail and it also can help position some actions as temporary measures the team will put in place to explore how to address an issue.

With Agile teams, the end-of-sprint retrospective is a great place to follow up on the current team experiments and identify the next ones to explore. Some parts of the action plan the team creates as part of the retrospective may turn into great candidates for experiments to try in the next sprint.

Integration of learning

When working with Lean and Agile teams, it is important to give them time to integrate what they are learning. Integration means accepting that changing behaviors takes time and allowing time for new team behaviors to become more natural.

Working in various organizations, I often hear management teams tell me how things are not changing fast enough; how teams are not learning fast enough. This is where the value from the Lean world that says, “Go slow to go fast,” becomes really relevant in the conversation. This complaint from management teams is one of the symptoms that explains why team members feel they do not have time to learn as they are doing.

As an example of integration in action, imagine you are looking at a new Agile team after four or five sprints. In comparison to its earlier sprints, you may notice
the following:

• The team may have a better handle on the quantity of work it can plan in a sprint.
• The team may have a better understanding of the information needed to plan its sprints more effectively.
• The team may have a more fluid daily Scrum meeting.
• The team may start talking about more touchy topics in a retrospective.
• The team may be starting to take ownership of its development process and it may self-organize better.

These types of improvements come from the team learning in action and continually integrating the lessons it learns.

One common symptom that shows the team is not focusing on integrating new behaviors is when team members begin to express discouragement because it seems to them that none of their improvements stick. But when you give teams time to integrate what they are learning into their day-to-day behaviors and activities, you will find they will eventually be able to incorporate even more new things into the way they work.

Conclusion

Lean and Agile teams should expect to learn as they go by continuously inspecting their deliverables as well as their practices and adapting by changing the things they feel are not working.

Learning and truly feeling it in your bones allows you to get a better grasp on what feels right and what doesn’t. Once you have this knowledge, you can let your instincts better guide you toward reaching your goal.

Learning through experiments creates space for learning by doing something and, more specifically, it allows space for potential failures from which you can also learn. Experiments allow us freedom to let go of our need for certainty, start from where we are, and iteratively and incrementally move toward where we want to go. Learning does not have to be a major time drain for teams; they can often speed up their learning cycles by adopting a continuous improvement attitude and incorporating learning into their existing daily work.

This article was originally published as an Executive Update by the Cutter Consortium in June 2015.