Table of Contents
How Do We Encourage Agile Thinking in Non-Agile Organizations? - SSA
Or:
- “How do we improve our effectiveness?”
- “How do we become Agile when there is no one here to help?”
- “How do we do DIY Agile?”
Summary (For Those Who Do Not Want to Read The Whole Article)
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:
- Set up the best organizational structure for success: Create small (less than 10 people), autonomous, cross-functional, teams with compatible soft-skills. Create virtual Teams; no need to go through a re-org to make this happen.
- Set the appropriate expectations for your people so they will improve: Be clear that your business need for the Team is “… running, tested, ship-able solutions, built according to an evolving view of customer and solution, on a regular basis (say every week or two).” Leadership defines the “why” and “what”. Teams figure out the “how”. This statement supports “do it right, do it fast, do it on time.”
- Support your people by:
- Removing systematic impediments that slow or stop their work: Constantly ask “When you last talked about improvements as a Team, what experiments came out, and what issues can I help you with?” Be prepared to take on and resolve the most thorny of issues.
- Providing space to improve by allowing experimentation and failure: Establish the mantra “Improving daily work is more important than doing daily work”. Encourage tactical automation (continuous small investments in automation) of the deployment pipeline.
- Hold your people accountable for improving their results. Ask “How will you know …” questions. For example, ask “How will you know you are improving your ability to produce solid testable solutions?” or “How will you know your customer is happy?”
Want to know more?
What Steps Do I Take to Help My People Improve Value Delivery? (Long Version)
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:
- Support your people by:
How Do I Create the Best Organizational Structure for Success?
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:
- Cross-functional: Cross-functional means that this Team is constructed in such a way that they have, in most cases, all the skills needed to take a requirement from the customer and get it delivered.
- Soft-skills: In addition to hard skills such as expertise in a particular area, Team makeup needs careful consideration. After all these people will be working together for a long time and if they really are to improve then they need to be able to work together effectively.
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:
- Someone is usually made responsible to defining and prioritizing the requirements (i.e. “what” the customer wants). In Agile implementation this role is often called the “Product Owner”.
- Someone is usually made responsible for helping the Team improve (i.e. the “how” a Team works together). In Agile implementations this role is often called the “Scrum Master” or “Facilitator”.
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.
How Do I Set The Expectations of My People So They Motivated to Improve?
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:
- Do it right: A happy customer; quality deliverables
- Do it fast: Respond quickly
- Do it on time: Be able to make and meet commitments
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).”
- The “evolving view of customer and solution” speaks to happy customer
- The “running, tested, ship-able” speaks to quality
- The “on a regular basis” speaks to meeting commitments and being able to respond quickly
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.
How Do I Support My People So They Improve?
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.
How Do I Help My Team by Removing Systematic Impediments That Slow or Stop 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:
- Stresses your awareness of importance for the Team to take time to focus on improvement
- Sets expectation that the Team will be experimenting
- Establishes the leaders role to take on and work issues that slow or stop the Team but which are beyond the capability of the Team to address.
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:
- The issues you will deal with will typically be long standing issues of the organization and will often have political implications that need to be addressed to resolve. This means that you will have to take a professional risk to address some of these impediments.
- You should be very transparent about how these impediments are being resolved. How you work the issues will determine how the Team works the issues. This is leading by example. If you expect your Team to improve, you need to show how you are not only helping then, but also how you are improving how you help them. Track the impediments in a tool, with changes in status, comments, etc. Track metrics like “mean time to resolution” and show improvements. And so on.
How do I Provide Space to My Teams to Improve?
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:
- You will need to protect the Team’s time to do improvements and not, for example, push more work onto the Team when customers demand for more, more, more features. You have to back your Team up in the face of the rest of the organization’s demands on their capacity, so they can improve.
- You have to be OK with the idea that not every experiment will lead to improvement, that some will fail. And you have to be comfortable with potential failure even if you suspect something might not work out; let the Team try it anyway. This allows the Team to maintain responsibility for improvement while fostering true learning.
- You have to trust that continuous, relatively small improvements will lead to big results as a result of compounding (exponential) improvements and so lead to high performance.
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.
Want to Know More?
How Do I Hold My People Accountable?
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:
- Asking specific questions aimed at encouraging data and metrics. For example, “How will you know you are improving …?”
- Asking open ended questions aimed at revealing more of the behind the scenes thinking. For example “Could you explain that a little more?” or “Could you draw a picture of this to help me understand the issue?”
Summary (Re-stating the Beginning)
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:
- Set up the best organizational structure for success: Create small (less than 10 people), autonomous, cross-functional, teams with compatible soft-skills. Create virtual Teams; no need to go through a re-org to make this happen.
- Set the appropriate expectations for your people so they will improve: Be clear that your business need for the Team is “… running, tested, ship-able solutions, built according to an evolving view of customer and solution, on a regular basis (say every week or two).” Leadership defines the “why” and “what”. Teams figure out the “how”. This statement supports “do it right, do it fast, do it on time.”
- Support your people by:
- Removing systematic impediments that slow or stop their work: Constantly ask “When you last talked about improvements as a Team, what experiments came out, and what issues can I help you with?” Be prepared to take on and resolve the most thorny of issues.
- Providing space to improve by allowing experimentation and failure: Establish the mantra “Improving daily work is more important than doing daily work”. Encourage tactical automation (continuous small investments in automation) of the deployment pipeline.
- Hold your people accountable for improving their results. Ask “How will you know …” questions. For example, ask “How will you know you are improving your ability to produce solid testable solutions?” or “How will you know your customer is happy?”
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!
Now Just a Minute, Don’t We Need Coaching?
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:
- A sense of urgency resulting in continuous, probably gentle, pressure applied to the organization to change.
- A different point of view when it comes to assessing how things are going and where we should go to next, based on the wider understanding the coach has of base agile, lean etc. thinking as well as their experience in working other organizations.
- A set of individuals in your organization will be developing their skills based mentor-ship and coaching of the coach.
- A wider set of ideas on how to work specific situations that arise in your organization as a result of their wider experience.
- A cheerleader that can help drive the transformation as a result of their experience at seeing things improve in other organizations (they “know” agile will help) which can help overcome obstacles.
- A point of stability as, when things do not go as expected (big or small) there is someone in the room that is calm and helping you through the situation.
- A way of explaining new concepts that may be difficult for the organization to accept. For many, agile and lean concepts applied to knowledge work are counter intuitive or worse, simply unbelievable. But people need to make the change in mindset to really get the business results they need. A good story, a good metaphor developed by working in previous transformations can help the organization get more quickly to understanding and application.
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.
Want to Know More?
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.
Approach
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.
- “Explaining Agile” by Steve Denning. Forbes Magazine article that explains common characteristics for Agile from a business perspective.
- "How to Impose Agile"? by Ron Jeffries. Tongue-in-cheek title for a thought experiment about how he’d “impose” Agile on his organization, if he was the boss and knew that Agile works, but didn’t want be not Agile by dictating how people work.
- "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka. One of the original inspirations for Scrum, this (is the influential) HBR article discusses research findings of common principles used by leading companies to innovate knowledge.
- What Google Learned From Its Quest to Build the Perfect Team by Charles Duhigg. Report on research from Google that showed that emotional intelligence of all Team members and psychological safety of the Team were better predictors of a Team being high performance than other more traditional approaches such as building a Team using all “best” people at specific jobs.
- How Do Small Changes Lead to Big Improvements?. Blog posting to help you understand the effect of compounding, small improvements in your quest for high performing Teams.
- How Much Coaching Do We Really Need?. Blog posting to help you understand the pros and cons of using an Agile coach.
Books
If you have time, there are some excellent books out there that will help broaden your understanding:
- Essential Scrum by Kenny Rubin. If you go the Scrum (one of the Agile practices) this book is the best, most pragmatic introduction.
- The Phoenix Project by Gene Kim. This is an easy to read “business novel” that helps people understand how to improve the delivery process.
More at Recommended Reading.