As Agile coaches, it is not uncommon for us to encounter companies that have made adopting Agile a priority in their organization but have come under scrutiny for not delivering any specific business value - despite what was promised. In many of these cases, we have seen these organizations revert back to their traditional ways of delivering projects, while others take a mix and match approach relegating Agile only to small co-located projects.
This pattern has caused me to step back and consider why this is happening. In the end I think it’s because we are setting the wrong goal.
"Valuing people more highly than processes or tools is easy to understand because it is the people who respond to business needs and drive the development process."
(#1 of 4 critical Values of the Agile Manifesto)
As an Agile Coach, I am concerned whenever I hear that an organization has Agile adoption as their goal. Let me highlight why in this fictional conversation which is based on a few actual client discussions I have had.
Let’s suppose that Sharon Wilson, Director of Corporate Strategies for Integral Investments, came to my coaching desk and asked me to help them achieve their goal of 100% Agile adoption by the end of next year;
“Why does your CIO feel that adopting Agile is so important for Integral right now?” I asked.
“Well, we need to get products into the market quicker which has not been happening like we would like. And we also need an approach that lets us be flexible with our requirements,” Sharon replied.
“That’s a pretty common reason.” I delved deeper,” Have you thought about WHY you need to do this?”
“Because we are trying to stay ahead in the game,” she replied. “For the last two years, we’ve lost some market share to one of our competitors, a start-up, because our products are not,” she paused, “modern enough,” she said holding out her fingers in the quote-unquote manner.
“Not modern enough?” I asked.
“Our marketing team did some research and found out that our users thought that our systems are really bulky to use. We have some designs which we think will be well-liked by customers, but you know how slow we are in sending new releases to the market. Our processes are so bureaucratic.
We think that Agile methods like Scrum will help cut all the red tape and improve delivery speed. We know that our competitor is using Agile and they are getting releases out quickly.”
I nodded. “Agile can be very helpful but I do not think in your case, it will guarantee you the results you want.”
Sharon looked at me inquisitively. “Do you think Scrum is not the right methodology for us? Are you worried that because of how we are structured we won’t be able to adopt Agile?
“I don’t think the concern is with the methodology or your culture.” I explained. “It’s the mindset. Too often companies make the mistake of establishing ‘Agile adoption in I.T.’ as their goal. Instead the goals should be more business-driven, such as to increase market share by $X million or improve customer satisfaction from a rating of 3 to 4, etc. When you are focused on business outcomes, Agile is a natural delivery tactic that will help you achieve your goal, but it shouldn’t be viewed as the ultimate secret weapon.”
“So, you do feel that Agile I.T. delivery is the right choice?” Sharon asked in a definitive manner. “What is the harm then in setting such a big and important step as our goal?”
After giving the above challenges some thought, I've outlined three reasons why Agile adoption should never be the goal:
1. You will never be able to measure success.
Agility is not a process that can be adopted from a book. It is an organizational quality. Think of it as a way of doing business with certain set of principles, instead of a box you check off that reads: ‘We’ve Adopted Agile’. These specific principles are outlined in the Agile manifesto.
Your organizational policies and procedures have a big say on how closely you can align yourself to the Agile principles. Organizations can fall anywhere within the scale of a total monolithic delivery model to one that is perfectly aligned, but you have no way to measure how Agile you are or how much more Agile you can be.
I have seen organizations who have been doing Scrum for years but release their products only once a quarter because of stringent quality policies. Although they achieve transparency through Scrum, they never get to market quicker.
2. Potential value conflicts across departments.
When you adopt an Agile framework, it quickly exposes the barriers in your organization that prevent you from maximizing your delivery effectiveness and efficiency.
Some of these barriers will show up in bureaucratic systems or “red tape”. Consider the impact of any one of the following examples:
• the marketing department does not do the right research
• business owners do not create the proper business cases
• there are not adequate investment plans for product innovation
• a traditional discipline-based resourcing model does not allow you to achieve a cross functional team, etc.
To mitigate these barriers, you must work with other groups who may not put the same priority on “being Agile” that you have. In most cases, they may not even understand how to apply the concept of Agile in those departments. Unfortunately, much of the industry still thinks of Agile as a development process, rather than an organizational quality.
In these situations, you will be forced to make compromises and work around the
barriers of creating a customized Agile process. These can actually counter any benefits that you may get from your Agile delivery. This is when some organizations get back to their traditional processes whenever they have multiple department involved.
3. Can everyone succeed with the change?
Is your business ready to review shippable product every two weeks? Are your consumers ready to receive changes every two weeks that they didn’t ask for? Would your operations team be prepared to support a new release every two weeks? Are your third-party service providers Agile enough to match your delivery needs? Do you have streamlined gates that may become bottlenecks?
All of these questions will impact the Agility of your delivery. Simply changing your delivery process to Scrum is not going to make you Agile. Agile will bring cultural and procedural changes across the entire organization, especially the support teams. When you are setting a goal for your IT team to become Agile, you are basically forcing that goal on all the other departments that liaise with the development organization.
How will having a business-driven goal help in Agile adoption?
Let us assume you have a measurable goal such as increasing your website traffic by 20%.
That is measurable in hard data. Right? Your technical experts have put their heads together on this and devised several strategic changes to your website which will increase traffic.
Now, you can start your Agile adoption journey taking a step that can be easily adopted without lot of change management. For example, introduce the basic Scrum practices for the development team that will be making the design updates, such as small time-boxed sprints, user stories, sprint planning, daily scrum, etc.
Remember, being Agile is not your goal. In this example, achieving 20% increase in site traffic is.
You can experiment with some of the practices. For example, if you feel that your team is not able to adopt story point estimation; just go with the normal effort hour estimation. What you will end up having will look something like Scrum but may not be Scrum by the book.
You may opt for a 4-week sprint and make a release after every two sprints. Again, not something most Agile projects will do, but that’s ok.
As you start releasing a new build to production every two months, you will certainly start seeing some value.
Just the fact that you are releasing new designs every 2 months, will give your customers something new to look for, and your site traffic may see a rise. Meanwhile, as you continue this model, you will come across issues that will pose challenges to your delivery. These issues were always present, but your new delivery model will now expose it upfront.
Some issues may also surface due to the inexperience of your team in delivering Agile projects, but can be quickly solved by employing an Agile coach or an experienced Scrum Master. While your team will be able to sort some of these issues internally, for many of them, you will need to work with all of your departments.
#4 of the 12 Agile Manifesto Principles:
"Collaboration between the business stakeholders and developers throughout the project – Better decisions are made when the business and technical team are aligned."
This is yet another benefit of identifying Agile accurately as an organizational adjustment, and not a system that affects only some departments. Everyone is accountable.
Even if there are extremely complex issues that require changes in organizational behavior, you will be able to utilize a temporary solution or live with the challenge, provided it does not debilitate progress towards your goal.
You may be able to compensate the impact of these issues with other productive measures. For example, if you can’t get 100% allocation for your testers, you may be able to automate
your testing to take some of the load away from your testers.
At the end of the day, you may not become an Amazon or a Spotify with your Agile delivery framework overnight, but you have enough agility to increase your website traffic by 20%. As the Agile processes continue to identify barriers, and you keep on resolving them; your overall productivity and efficiency will increase.
It is a virtuous-cycle.
The Conclusion
Ultimately it is not about becoming ‘Agile’; it’s about providing value to business and using Agile is just one of the many important contributors. Agile can be a key identifier and enabler that helps deliver value most efficiently.
Connect with an Agile Coach today to have a customized conversation about your organizational needs and goals!
Submit a Comment