Five Challenges to Adopting Agile

Moving your organization to Agile won’t be the easiest objective you’ve signed up for in your career, but the benefits of the end game will reap rewards for years to follow.

The most important thing you can do is to have a well-orchestrated plan and execute deliberately with your eyes wide open.

Remember Agile is the ability to move or change quickly, and it’s all about course correction as you adjust the system to your corporate culture, work and style.

Whether you have begun the Agile journey or just thinking about it, here are the top five challenges and guidance on how to clear these impediments to success.

My Business Isn’t Engaged

Many organizations leverage a waterfall methodology, where technology analysts interview business stakeholders to collect requirements for a new idea or product. This can be a long, arduous cycle where key decision makers are hard to engage, development immediately follows, completing months or years later, only to find that requirements have changed or were misinterpreted.

Agile solves this by placing the business right in the middle of the delivery process, and iteratively “checking off” on what is being built and adjusting requirements (user stories) as you go. The business (Product Owner) has the authority to make decisions on the spot, thus ensuring that things happen quickly.

However, many companies don’t get full buy-in on this model and find themselves in the same situation as before, where business is not readily available and the work languishes with the same side effects as a waterfall. Impressions of agile become negative and it is very difficult to recover enthusiasm.

How Do You Get the Business Excited About Agile?

"Use of agile methods has the capability to transform IT-business relationships and have a major positive impact on IT value delivery. However, the value will be delivered only if the CIO and the entire IT management team are dedicated to the culture change that is necessary for success…" -Nathan Willson, Gartner

Start small. The organization will realize when something great is happening and jump on the bandwagon to adopt a methodology that is showing promise. It’s also easy to convince the business to do something very focused and small with a minor investment; you need a pilot. The pilot must proto-type all of the key elements of your agile approach; key elements that were agreed upon by both technology and the business in partnership.

We know that everyone is a professional user experience and design expert so you want to head off this amazing phenomenon by hiring a business-owned designer. This individual(s) works with the product owner to set the path, by prototyping, demonstrating the concept to leadership, technologists and customers.

To make it even more exciting, introduce your business to Design Thinking. This emerging industry approach brings the customer/end user and the business together to create a well-grounded and innovative user experience.

Not All of Our Work Seems to Fit Agile

You may find that some work doesn’t easily fit into the Agile model and many organizations have tried to force everything into agile. Methodologies like Scrum, which usually identify stories that are relatively meaty and vary widely.

Sometimes work is small and relatively the same thing over and over again like setting up firewall rules. If that is the only activity a team performs Agile probably lays too much overhead on such a simple task, where all you need is an intake process, a backlog, and a prioritization list.

Now if your team does a number of different things that fall into “bigger than a breadbasket” category where multiple skills might be needed to complete a single unit of work, that is where Kanban enters the picture.

This methodology would be typically leveraged in a manufacturing process, where there is an eye on work in process (WIP) and cycle time across multiple steps in completing a “widget”. A good example here would be “build a server”; procure components, assemble server, load operating system, test server and ship.

Be careful when you apply Agile to anything other than building complex software and make sure you are not over engineering an already well managed and efficient activity. Agile can add unneeded overhead to this type of work.

We Are Getting Held Up by External Dependencies

Many organizations run into a brick wall as they try to roll-out Agile in a scattershot effort to bring in all teams that develop software. What about brand, infrastructure, network, security, legal and architecture? It is all too common that software delivery teams are sitting on their thumbs waiting for action from these critical functions. There is no other situation in Agile adoption that will turn your emerging Agile façade into a monolithic waterfall style.

Let’s harken back to the types of work we do. Some of these functions fall into the not-so-agile category and some fall into the Kanban category. Your program must be flexible enough to embrace the culture of the organization and the culture of the teams. Some teams will be Scrum, some teams will be Kanban, others will simply continue as they do today.

Typical Agile methodologies like Scrum or XP run in defined time increments (two, three, four weeks) for a varying body of work. Kanban runs in cycles of completing certain repeatable activities in a specified time, while other teams run at their own cadence outside of the Agile program. How do you merge these? The answer is the Scaled Agile Framework (SAFe).

If you have a big organization, you need to start here and figure out which functions you have are aligned to capabilities in this model. Properly executed, SAFe can bring many of these diversified styles and types of work together at the right times in the delivery of complex systems. There are many tools to help you bring SAFe together for the enterprise and some vendors such as CA Technologies (formerly Rally) bring entire suites that address virtually every aspect of Agile management.

Our Agile Teams Aren’t Getting the Benefits We Expected

It’s very hard to read a book and make Agile happen. Rolling out Agile methodologies to an enterprise requires a massive level of change management, socialization, evangelism and a foundational roadmap to who, what, when and where. Most companies will hire consultants in a New York minute to drive a solution to every failure on the planet (e.g. why is net margin shrinking), but will swirl in a struggle to implement Agile methodologies.

Agile requires discipline; not in the rigid adherence to process but discipline in avoiding strict discipline. It is flexible and designed to adjust on the fly, but these are big concepts for an organization steeped in the same-ole, grinding, waterfall methodologies. You need some guidance, and if you are ever going to hire consultants this is the time to do it.

You can call it an Agile transformation team, center of excellence, whatever buzz word you can think of, hire Agile coaches and experts to train your leadership on how to execute in an Agile way. But it doesn’t stop there! You need an external Agile coaching influence to hang with your teams until they get it until you can measure it and until your own people can coach the new members of the team.

Why? They are unbiased to your culture and bring in pure innovation, it is up to your teams to blend outside expertise with the status quo which will yield a unique Agile approach for your company. One size does not fit all and professionals in this field will help you determine what size you are.

Every Team or Business Area Is Reinventing the Wheel

Finally, business and technology architecture are still relevant, albeit in a different form. Agile can result in a Wild West mentality that drives technology costs into the stratosphere. This has been a primary complaint of large Agile efforts where many diversified teams have developed different versions of the same concepts.

Agile can have a propensity to proliferate many “wheels”, as there is usually nothing in place to glue the organization together or a mechanism for sharing assets.

Once again, SAFe to the rescue. Business and technology architecture are still relevant, albeit in a different form. The Scaled Agile framework prescribes how architecture, whether business or technology, can provide a runway ahead of large development efforts and influence the architectural goals of the entire organization. Architecture can be built incrementally to reach a longer-term goal, even while teams are performing in an Agile way.

You Can Do It

Disengaged business, poor strategy fit, dependency management, disappointing results and standard patterns and practice; these are all the same hurdles we jump over every day with just about everything we do in a large enterprise. With Agile, it is no different than any other organizational culture shifts and should be treated with the same diligence and focus as any initiative you undertake.

Going Agile is a game changer, and the investments you make in setting the foundation for a successful journey will reap huge rewards in output, budget and, most importantly, job satisfaction for your employees.

5 Challenges to Adopting Agile Development and How to Overcome Them