Agile Adoption – Why should we adopt agile?
This is the first is a series of blog posts on Agile Adoption. 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?
In my second Adopting Agile blog post, I will answer the question “How do we start?” by looking at how companies go about adopting agile, and what are some of the pitfalls to avoid.