Agile Adoption – Why should we adopt agile?
As an Agile coach and scrum master, I have often been asked how other companies go about adopting agile. While every organization has its own journey to go through, there are some major themes or commonalities that arise when you look at what people do. So for the first post in this series, I want to look at the reasons why companies decide to adopt agile. Because let’s face it, if you don’t know why you want to adopt agile, or don’t have any idea of what problem you are trying to solve, then agile is not going to help. Figure out the why first, and then we can talk. ☺
Most companies have a problem that they are trying to solve and they are looking to adopt agile as a potential solution to that problem. If a company is simply talking about agile because they heard that it is a silver bullet, or because someone read a book, or because the CEO went to training, then that is a major red flag for me as a coach. Agile will not solve all of your problems. However, it will make it easier to spot the problems, because of the fast pace and focus on transparency.
Most companies tend fall into one of three problem categories: they want to make software development faster, simpler or better.
Faster – many companies are interested in speeding up their development processes. A recent client that I worked with was interested in adopting agile because their projects were simply taking too long. A note of caution on faster – you may not finish the project faster, because of the changes and detours you will take along the way – but you will get results and value faster, which is still a pretty good deal.
Simpler – Simplify the process and the product. Make it easy to get what you want. Many companies have software development processes that are complicated, antiquated, and often just painful. One company I worked with recently had a checkpoint process for software development. There were 8 different checkpoints, each with a series of meetings and documentation that needed to be completed, including a pre-checkpoint meeting review! Hundreds of hours were spent per project, just getting together the information for these meetings and filling out documentation. While I’m not saying that processes are unnecessary, doing documentation and processes because ‘we’ve always done it this way’ doesn’t seem like the most efficient way to develop new software.
Better – Your software will be better. Better meaning more of what people want (meeting the needs of the customer) and better quality (tested, validated and approved every step of the way). Sometimes wanting better software means “Anything is better than what we have now!” because things are going so badly that people are willing to try anything to make things better. Just be careful if you fall into that last group, because agile is not going to make everything better. It can make some things better, and expose what the underlying problems are, but anyone who tells you that agile will solve all of your problems is lying to you.
You don’t have to know all the reasons you want to adopt agile, or know what specific benefits you are looking for. But unless there is a problem you are trying to solve, how will you know if agile can help?
Agile Adoption – How Do We Start?
Clients often ask me if they are going about adopting agile the ‘right way’. While I truly believe that there is no one ‘right way’ to start doing agile, it does reassure clients to hear that most organizations usually fall into one of three major groups when it comes to starting agile. I like to refer to them as Top Down, Grassroots, and Meeting in the Middle. Each group comes with advantages, as well as its challenges.
‘Top Down’ is when someone in upper management hears about Agile and decides that the whole company should be agile, often right now. On the positive side, this normally means that there is significant support for agile from the top of the organization, and that there is usually money for training and coaching as well. On the negative side, this approach often doesn’t take into consideration what is currently working in the organization, and can be very disruptive to teams who are already working well together. Additionally, the teams who will be most impacted by this transformation to agile may not have been consulted at all, and their reactions will run the gamut from elated to cautious to downright hostile. Coaches who walk into this type of situation often face an uphill battle, because they end up spending time convincing teams that this is not just some new flavor of the month idea from upper management, rather than being able to focus on how agile will help their teams.
‘Grassroots’ is the opposite scenario. One or more teams have started doing agile, usually under the radar because it was something they heard about, read about, or were exposed to on their own. I also think of this as “Stealth Agile” because the teams are often quite cautious about not telling people what they are doing, in fear of being told to stop. This is an interesting scenario for a coach, because obviously you can’t be brought in to coach a team if no one knows that they are doing agile. However, success breeds interest, and what often happens is the stealth agile teams start showing significant improvements, and people want to know why. Eventually the word gets out that agile is the secret sauce these teams have been using, which leads us to the third group.
The third and final group is ‘Meeting in the Middle’, and in some ways it is the best of both worlds. This scenario happened when there is already a Grassroots effort to use Agile, and it has been successful enough to catch the attention of upper management who hopefully learn more and decide that this agile thing is something that the whole company should try. This can work very well because there already exists evidence within the company that agile is working, and with the recognition from upper management can come additional resources and support. This can be a great scenario for a coach to walk into, because the first teams have already laid the groundwork and can be your evangelists.
However, since they have been through the trenches and had to bear some of the biggest adoption challenges, often on their own, it is critical to acknowledge their contributions. In addition, it is also critical to consult them in order to learn what has worked well so far within their organization and use that as a template to build on for other teams. Coming in and deciding to ‘do agile right’ now that there is a coach involved is a great way to burn bridges, lose champions and fail badly, and agile will be blamed for it in the end.
So while the Meeting in the Middle scenario can be challenging, I still think it is the best scenario to walk into as a coach, because you have people who have been living agile who have demonstrated that it can work for the company, and you also have the support of management to help agile spread throughout the organization.
So now that you have an idea about how most companies start their agile journey, the next question is “What do we do?” (Hint – telling everyone to read a book and be ready to ‘go agile’ on Monday is not a good way to start!)
Agile Adoption – What do we do?
So, you have decided to take the plunge and go agile…but what should you do to make it happen? Here are a few common scenarios, as well as the challenges associated with each one.
Options:
Wing it (have everyone read a book and be ready to go agile on Monday).
Not recommended. To be clear, I think that reading about agile is a great way to learn more and figure out if it is something that might work for you. I also believe that people learn best by doing, so being able to jump in and going with agile is great. But the problem with doing it on your own is that it can be overwhelming. People usually try to do everything new at once, and then get discouraged when it is too much. Additionally, if everyone is new to agile then it is hard to tell when something is just a normal bump in the road, or a sign of something more serious, because you don’t have the experience to know what to expect from an agile transition.
Go to training (better)
Starting with training is a great way to get everyone on the same page, and to make sure that you have a common vocabulary when it comes to agile, as well as a common understanding of what it means for your organization. This approach can work very well if you train the whole team, including the product owner and any stakeholders from the business. Jump-starting a new agile project with training can get things off to a great start. The challenge comes when you work to implement what you learned at the training, and things don’t go as expected. This is when people start to blame agile and say that it won’t work for your organizations. That’s why I recommend option #3.
Bring in a coach (recommended, but not just because I am one)
Bringing in an expert can help for several reasons. They have had experience with a variety of companies, and are aware of the common pitfalls, as well as what to do about them. Second, the coach can be the voice of authority. Sometimes people won’t listen to someone inside the company, but they will listen to an expert. Enlist your coach to help with those who need convincing. Finally, people do better when they have a support system. Like training to run a marathon or losing weight with a nutritionist, working with someone who specializes helps to set you up for success.
Agile Adoption – When do things go wrong?
Now it’s time to talk about when new agile projects run into challenges – at the beginning, in the middle, and at the end.
In the beginning
Suffice it to say, there are a number of things that can go wrong at the beginning of an agile adoption, including (but not limited to):
Silver Bullet – Agile will solve all our problems!
This often happens in organizations where they are doing a Top Down implementation of agile. Someone in upper management read an article or attended a workshop and decided that going agile would make everything better. While agile can solve some problems, what it is more likely to do is expose your real problems sooner. This can leave teams discouraged and overwhelmed, instead of empowered and energized.
Flavor of the Month – Agile is just another new fad, it won’t really help us.
This issue comes up with teams that have been through too many management fads and changes. They have seen new initiatives come and go, and in their experience everyone gets excited for a few months, then things go back to normal. This type of team will need to see real change and progress happen quickly, as well as over the long term, before they come around to the idea of adopting agile for good.
Read the book and be Agile! – Not getting enough support
When teams are thrust into the world of agile without enough training and support, things can go downhill fast. Change is difficult, and people can easily become overwhelmed with trying to do too much too quickly. A good coach will help teams who are new to agile adopt practices in a way that makes sense for them, adding value rather than adding new rules to follow.
As I mentioned before, how you go about implementing agile matters, both from the perspective of how it is positioned to the teams, and in terms of the level of support you provide for your teams. Since I’ve already covered much of that in earlier posts, let’s assume that you have gotten off to a good start with implementing agile and want to know when to expect challenges moving forward.
In the middle
Often once the initial hurdles of adopting agile are overcome, things start going well and the team becomes more comfortable with this new way of working. And then, something happens. It could be a technology problem, or a requirements issue, or something with team dynamics. While I don’t know what bump in the road your team will encounter, I do know that these bumps in the road are normal. Unfortunately, this is the point where people start to worry, panic, and blame agile.
Teams tend to start worrying when stories aren’t getting done, or when a big technology challenge arises. Teams start to worry more if management challenges the agile approach, or wants to know why we can’t tell them when the project will be done, or what the final product will look like. Usually the panic happens when agile exposes the real project problems.
To be clear, it isn’t that agile created these project problems. They were here all along, but were often buried under the usual project planning and execution. But with agile, all of the project problems and issues are exposed as part of the transparent nature of agile projects. Even thought that level of transparency can be pretty painful at first, it is also part of what allows us to fail fast with agile, and iterate and improve. Once you can see the problems, fixing them becomes a much higher priority than when they were buried under the usual project overhead.
The biggest challenge with these middle of the project issues is that they frequently coincide with people falling back on old habits. Change is difficult and people often revert back to what they know and are familiar with. That is why it is so important to having ongoing support for your agile adoption, either in the form of internal champions or external coaches, because they have seen the pattern before and can provide different strategies for how to overcome your team’s particular challenges.
At the end
Finally, at the end of an agile project a new kind problem comes up, the need to ‘just get it done’. There is usually a lot of pressure to get a project finished and out the door, especially if there is a big deadline. What sometimes happens is that there is a push to treat the project more like waterfall, just to get it out the door. I have clients say to me, “We know that this is not the right way to do things, but we just need to get this project done. We can do it the agile way later.” The problem is that this just emphasizes all of the challenges and disfunctions that made you want to do agile in the first place. Only now, you are undercutting the effectiveness and value of what you have done so far by saying you are willing to throw agile out the window to get the project done.
I think one of the most important things to realize about agile adoption is that there will be challenges – change is rarely easy, and usually doesn’t go smoothly. However, having the right coach to help you weather the challenges of adopting agile can make all the difference. Stay tuned for my final blog post in the series about how a great agile coach can help you through these challenges.
Agile Adoption – Who can help?
Agile is about helping teams work together to produce great software. As I have discussed in previous blog posts, there are a number of challenges that can come up when a team adopts agile. Agile coaches help teams by targeting specific problem areas that are preventing the team from performing at their best.
Agile coaches do four important things:
- Observe and give feedback
- Educate and encourage learning
- Facilitate and smooth the path
- Support and energize the team
An assessment is often the first step in a coaching engagement, to determine where you are and where you want to be. By better understanding the frameworks, practices, tools, and processes currently in place, coaches can tailor their approach as needed by taking into account the goals, risks, environment, and culture at your organization.
This assessment should include observing current day-in-the-life ceremonies, surveying team members to assess the organization’s adoption of agile practices, and conducting small group interviews with key executive and management roles within the organization. After the assessment, the coach will identify and assess the impacts and potential risks and impediments to current agile adoption and determine recommendations for agile practices, frameworks, tools, training, and assistance needed for the subsequent coaching effort.
After the assessment, the coach will work with the team to educate them on the areas of agile that need improvement. This could take the form of formal training sessions or just in time training, taking advantage of teachable moments as they occur during the normal workday. As part of supporting and encouraging the team, an agile coach will provide insight and encouragement, helping to remove impediments along the path to agile advancement. This includes determining how to tailor and apply appropriate best practices in agile to your organization. While there are many common patterns in agile adoption, every organization has its own unique challenges, and a good coach will ensure that agile is adapted to work within the organization. While some agile purists may take exception to this statement, I believe that part of being agile is always improving, and part of that improvement may include tailoring agile practices. I think of it as knowing what the book says on agile, and knowing what will work for your organization. However, if you do something different from the book, you should know what risks you are introducing by doing (or not doing) things differently than is recommended.
As a final note, a coaching relationship should be like parenting, where the purpose is to make the coach’s role obsolete. A good coach will evaluate how the team its doing against their goals, and plan for a gradual transition, allowing the team to spread its wings more and more within the supportive context of coaching, until they are ready to go out there on their own. This doesn’t mean that there won’t be problems along the way, or that the team won’t have setbacks. But by providing ongoing support as needed, such as additional training or access to a periodic check-in with a coach, you can give fledgling teams the ability to learn and grow and make mistakes on their own, and ultimately succeed at making great software.
If this blog series has piqued your interest in agile, or if you would like to learn more about how SPR can support your agile adoption, please contact us.
