Or:
To help your people improve how they do it right, do it fast, and do it on time the steps you should take as a leader are:
Want to know more?
One word of warning before we get started. You will often see terminology on this page such as “product”, “project”, “every two weeks”, and so on which are associated with the traditional application of Agile to software and IT systems. Know that these approaches have been applied to all kinds of knowledge work, from ticket driven systems, to hardware development and installation, to teaching, marketing, finance, and HR; anywhere there is knowledge work and where we need to become more effective. The approach and advice here is generic. As a leader you need to establish, to be clear about, what it means to be a great, high performing Team in your context.
It is clear that Agile (and Lean) practices and mindset are effective. However there are often situations where coaching capacity is at a premium and you want to start reaping the benefits now.
As leaders (I am going to be using the term to mean “manager”, “leader”, “supervisor”) you want to want to know “how do I encourage my people to become more Agile so that they become more effective, but also so they don’t end up doing something regrettable or wrong?”
Historically Agile is a grass-roots movement. It arose out the notion that there had to be a more effective way doing knowledge work than pretending that that knowledge work is just like a manufacturing operation. As people worked through this they discovered principles and practices that proved to be more effective; that allowed groups of people to become Teams. These Teams produced more than the sum of their people would indicate. We called these Teams “high performing”. They found leadership approaches that improved a Team’s chances of becoming high performing.
As a leader you can set set things up so that your people can discover these principles and practices. The good news is that your people can leverage existing knowledge rather than inventing everything for themselves. Improving performance should happen faster that if they had to start from scratch.
To create the right environment for your people you will need to set things up so that your people head in the right direction. You need to provide clarity on what you are expecting. You need to support your people so they can do what is needed. You need to provide them with space to try things out and even fail sometimes. You need to help, removing systematic impediments that will slow or stop their work. And you will need to provide the organizational structure so your people have the best chance to succeed.
In other words, as leaders we need to:
Of all the things that a management can do to help your people become more effective this is probably the area where you will be most comfortable. Management, after all, usually defines the organizational structure of their people.
There is a twist with Agile though. The unit of execution for Agile is not a person (or a full time equivalent or FTE). Instead it is a small Team where small is defined as “less than 10 people”. Steve Denning in his blog post "Explaining Agile" calls this “The Law of the Small Team”:
The first universal characteristic of Agile organizations is the Law of the Small Team … work should in principle be done in small autonomous cross-functional teams …
This is not done by simply dividing up people into groups of 10 (say) but rather requires some careful consideration:
In the end, these soft skills are probably the most important requirement for a successful Team as Team members can usually develop hard skills. From recent research at Google:
“As the researchers studied the groups, however, they noticed two behaviors that all the good teams generally shared. First, on the good teams, members spoke in roughly the same proportion … Second, … they were skilled at intuiting how others felt based on their tone of voice, their expressions and other nonverbal cues. ”
Note: although not necessary, typically Teams identify some special roles to help control the flow of work:
Creating Teams in this way does not need to go through a “reorganization” process. You can start by creating virtual Teams with clear roles. Over time you might want to consider more formal structuring but it is not necessary to get started.
One of the base principles of Agile is that as a leader you provide ambitious goals to the people doing the work and then support them in achieving those goals. The influential HBR article calls this principle “built-in instability”:
“Top management creates an element of tension in the project team by giving it great freedom to carry out a project of strategic importance to the company and by setting very challenging requirements.”
Leaders provide the goal, the “what” and “why”. Teams figure out the “how.”
It is therefore pretty funny when one of the leading Agile thinkers, Ron Jeffries, writes a blog article called "How to Impose Agile?". This is a tongue-in-cheek title for a thought experiment about how he’d “impose” Agile on his organization - what would he do if he was the boss and knew that Agile works, but didn’t want be perceived as “not Agile” by dictating to his people “go Agile.”
The blog post is instructive in that it lays out the challenging business goals that he needs as a leader, framing it as “what we need our people to achieve.” Interestingly the framing is such that adoption of Agile practices and mindset is natural.
But let’s step back for a moment. If I were to ask you what you really need for your organization to be successful I could imagine you’d list out characteristics like:
Converting this into a statement for your delivery Team you would say:
“What I need is running, tested, ship-able solution, built according to an evolving view of customer and solution, on a regular basis (say every week or two).”
Now you probably should expect there to be a fair amount of push back on this statement. This is normal and, while it might not help you right at this minute, just know that every Team that ever moved to Agile did not see how it was possible when they first started. That is where Agile practices and mindset come in. They provide a good tool-set that you and your Team can use to help them to achieve this business goal.
You’ve set the business goals. You’ve defined the structure. Job done, right?
Even with awareness of Agile practices, you should not expect your Teams to be able to become high performing immediately. For example your Team might not know who the customer is and so will need time to establish the appropriate level of contact. Or your Team might not be able to deliver a running tested system every two weeks and so will need time to reach that goal. Or Team members may never have really worked together (they’ve been a team in name only) and so have to work through how they become more effective. Or perhaps there are organizational impediments which stop the Team from delivering effectively.
As a leader, you need to help the Team. Firstly, you really have to repeatedly remind the Team about the business goals they have. This not a “once and done” activity. Increasingly they will absorb the goals, recognize that you are serious about them, and they will make progress, provided you help them.
The two basic ways leadership can help Teams is by providing space to improve through experimentation, and by removing organizational impediments that slow or stop their work.
One way leaders can help is by working impediments that slow or stop the Team as they deliver. Teams are expected to identify and work impediments themselves. But sometimes the issue goes beyond the Team’s capability. For example, perhaps the Team doesn’t have the political clout to work the issue to completion.
As a leader you need to both be seen to want to improve and actively participate in removing these systematic impediments.
A great question for you to ask the Team is:
“When you last talked about improvements as a Team, what experiments came out, and what issues can I help you with?”
This type of question:
You can, and should, volunteer to take on a Team's impediments. One perennial complaint of Teams is that they feel like they report on issues “over and over again, but nothing ever changes.” This is where you need to step in a lead by example, showing that you are interested in helping. This will also ensure that you establish you role as the leader.
Now let me tell you this is not going to be easy for you. You can expect to be uncomfortable:
There is no chance of the Team becoming more effective, becoming high performing, unless they take the time to focus on the improvement effort. This means you will need to recognize and support the idea that Team improvement is “real work” as well.
To help establish the right mindset you might want to repeat the mantra:
“Improving daily work is more important than doing daily work” - Gene Kim, The Phoenix Project
Improvement will take many forms, such as how the Team works together, how they work with their customer, removing impediments they have to delivery, improving how they deploy work, and so on.
For software Teams, one area you should encourage the Team to work is automating their deployment pipeline. If most of the Team’s deployment processes are currently manual there is a huge potential for return on investments made here, both in terms of freeing up capacity to do more value added work, and in terms of improving the reliability and quality of the deployment process preventing re-work.
Even small investment can lead to big results. One Team recently invested one hour researching automation of a deployment process which lead to 78 hour saving for that process, or a 780% ROI. Further:
“In less time than it took to do the work once, they were able to implement automation, so they never have to do it again manually”
While this idea is obvious for software Teams, it should be noted that it is also worth reviewing for non-software Teams. Ask “what is tooling we can bring in to enable use to provide this service better, faster, cheaper?”
This is called “tactical automation.” In particular you don't need to wait for the mega-automation project. Space to innovate, willingness to invest, and a little encouragement from you will produce this kind of result.
You will feel uncomfortable because:
To help both you and the Team a great question to ask the Team when they talk about improvements is:
“How will you know that you have improved?”
This will encourage the Team to generate data and metrics as they are improving and will provide you the data you need to become comfortable and support their efforts.
In addition to supporting your people you will also need to set high expectations. You need to do this even in areas where you don’t have domain knowledge. For example, it’s important that your team has solid testable solutions; that is one of your driving goals. You therefore need to get comfortable asking some questions that would tell you that the Team is making progress toward that goal even when you don’t have a solid understanding of the underlying technology or how it’s done. If answers you are hearing do not make sense, then it is on you to drive accountability to an answer that does.
As a leader you do not have to be expert in the areas the Team is working on. But you should know enough to understand when someone 100% sure of what they are doing. You do this by:
What you should do if you want your people to move to Agile? The “short version” of the steps you should take if you want your people to move to using Agile is:
To help your people improve how they do it right, do it fast, and do it on time the steps you should take as a leader are:
Done properly, you will see success. As John P. Kotter says in his book “Accelerate”:
“… when you find energized people producing effective change, you almost always find people who want to do just that and feel they have been given permission to do so.”
Your job is to create this environment for your people.
This will not be easy for you. You will be uncomfortable because there is risk here. You will need to take a leap of faith. You will need to lead-by-example. You will be watched by your people. Your behavior will be reflected by the Team.
And you will need to adapt the generic advice here to something that is concrete, clear in your context of what it means to be a great, a high performing, Team.
But you can expect to see results, and as you and the Team learns, you will find the knowledge generated is applicable in many areas.
Good luck!
The short answer is “you really don’t NEED coaching.” You will be able to get to where you want to go without it.
Don’t get me wrong; there are benefits to bringing a coach in as they can provide:
But these benefits will not stop you from being successful. It may mean that improvements don't happen as fast as they would have if you had a coach. And you will benefit in that you will know how to improve without having a coach as a crutch.
Before you start encouraging your Team toward Agile, you probably should improve your understanding of what to expect. There are literally thousands of books, blogs, podcasts, articles, etc. out there and, by all means feel free to research them all.
Let’s assume you don’t have time to do the research, and just want to understand a little more about what you’ll be asking your people to do as well as have the background so you can defend your ideas and requests. There is no need for you to be expert at everything. You can learn as your people do.
Here are a couple of articles that I used to develop this approach that will provide good background.
If you have time, there are some excellent books out there that will help broaden your understanding:
More at Recommended Reading.