This content is part of the Essential Guide: Making the Agile development model current again
News Stay informed about the latest enterprise technology news and product updates.

Agile2017: What the Agile development model needs to do next

It's more than 16 years old now, but Agile still struggles to achieve broad enterprise adoption. Here's what Agile2017 speakers and attendees are suggesting for the future.

More than 16 years after the Agile Manifesto was written, "Agile is still hard," admitted Tricia Broderick, the chair of Agile2017 in Orlando, Fla.

Just released data from a survey of more than 150 managers by CA Technologies underscores that fact -- only 12% say their entire organization is on a path to achieving an Agile development model, even while 70% say they know it's the process that can help them be organized and respond faster.

At a time when many feel the Agile development model is at a crossroads, the annual conference offers an opportunity to bring concerns and triumphs to light. The keynote speaker, David Marquet, author of Turn the Ship Around and a former nuclear submarine commander, spoke about how he "turned his ship around" by moving his crew from a thinking organization to a thinking and doing organization, and how those principles can be applied to distributing the Agile development model throughout a company.

He focused on the tricky role that leadership has to play. "The most important leadership attributes are the ability to say 'I don't know,'" Marquet explained. Agile thought leaders need to "lean back" so that their teams can lean forward. "You've got to let your team own it so they can move forward," he said.

But as the CA survey data shows, that's sometimes easier said than done. Managers know why the Agile development model is important and invaluable to an organization: 51% said it reduces project derailments and "fire drills" while 47% agree it increases visibility and improves communication among groups. But 38% said they couldn't scale Agile because of inconsistency and siloed groups while 42% said the barriers were within certain departments. 

It's definitely a leadership thing, said Jeffrey Hammond, Forrester Research vice president and principal analyst of application development and delivery professionals in an interview before the conference. "Agile has become telling people how to do things right but then not necessarily doing those things themselves," he explained. The challenge is for management to try to get out of the way. "When I talk with our clients to help with digital transformation, it's really about becoming more Agile in spirit. They need to understand the cultural barriers and that will help them refocus on delivery and measuring results and customer engagement." Stop thinking about the Agile development model process, Hammond said, and think about the results instead.

Dave West, CEO and product owner of, acknowledged that there are lots of challenges when it comes to Agile and Scrum, but it's time to get smarter about how Agile is done and not do band-aid type fixes like renaming it. "We need a reboot in a lot of cases, but we don't need a reinvention," he said. In his ideal world, you'd empower the people who know what they're doing and get middle managers on board.  "The future of Agile isn't 3.0 or renaming it, but instead it's making it consumable for those groups. The biggest challenge is to take a high-level instruction and convert it into a series of understandable instructions and then make sure people are doing it."

Next Steps

How to do large-scale Agile

Compare Agile2017 to Agile2016. What's changed?

Is Agile the real deal or a risky choice?

The benefits of an Agile approach to content management

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What needs to happen in your organization to make Agile work better?
The Agile community has been its own worst enemy: it has "dug in" on practices that don't always work, despite evidence that such practices are not applicable in all situations - the open team room is the best example. It has also tended to focus on process and ignore engineering - even though XP started with an engineering focus. And the whole "be Agile, don't do Agile" is so useless - because the natural question then is "how do we do that?" but the Agile community has had no answer for that, expecting the organization to change its culture - but culture change experts will tell you that changing culture is the _hardest_ thing to do, and only occurs _after_ you first change behavior.

The DevOps movement took off because the Agile community was not answering these kinds of questions. Instead, the Agile community has focused on team level process, ignoring automation or technology issues - which are important - and being stuck in its team-focused paradigms and not embracing organization level approaches that have been developed outside of the Agile community.

So the change that is needed, is that the Agile community needs to start thinking outside of its established paradigms, and become more open and inclusive with respect to other ideas, and not hold on so fastly to its cherished practices.
Thank you for the article.

I think that one of the most common obstacles that comes with implementing Agile is how people react to change. Do they embrace the change or do they look for repeated bottlenecks to happen again and again.

I think that coaching agile and principles of implementing such methods of project management and business development is one of the most important steps any organization can undertake.

Show Agile value though visuals and drawing provides a comfort zone for the unknown for people who have never experienced such principles.

Setting high expectations is unrealistic for at least 2-3 sprints (by 3-4 weeks each) to get people in the groove of new methodologies to be embraced.

But also providing an avenue to explore his/her own potential when it comes to measuring a level of effort / estimation points on individual basis up on which improvement and professional growth will happen!

Thank you once more for the article. Greatly appreciate it!

If you want Agile to take off, then stop defining it as incremental intervals called Sprints.  First of all, design is not incremental at all  but iterative refinements, and "Sprints" are a sports term for a race, which is totally and completely inappropriate for designing or programming.
The main reason Agile has not caught on is because usually it is a fraud to cover up for incompetents unable to plan well ahead of time.  The ONLY advantage of Agile is that it saves time if some major blocking impediment is discovered in the original plan, and much of it has to be scrapped.
The way to tell if Agile is being use to cover up being lazy and disorganized is what they end up with after the project is over.   Regardless of what way a project is managed, you should ALWAYS end up with a Waterfall Project Design after it is over.  That is because once the project is over, there no longer can be any unknowns or potential blocks.  And if the project manager is too lazy to document the final path, then they know nothing about software life cycle or the need for project documentation.
There's emerging technology, live on the web, that may help. See Think of it as the beginning of the end of coding.
No, we do NOT want executable English.  Anything complex, like an operating system, network protocol, web browser, or even anything with a graphical user interface, requires the speed of an optimized programming language.  The point of programming is to optimize the hardware.  So the lower level the language the better.  The only reason to not go too low is only because then you would start to become machine specific.  C/C++ are the ideal languages.  Anything higher level is just scripting, and runs so much slower that it is a waste of time.
Thanks for your comment Rigb5. 

Here's an example indicating why it's important that people should be able to understand results from a program, and be able to get explanations:

We actually get the best of both worlds, by automatically comipiling from EE to SQL
Adrian Walker, except that spreadsheet modeling is about the highest level language one uses with computers.  The problem with high level models and languages like SQL is that they hide and don't show all the details like looping and branching.  It is not that they are too low level, but that they are an attempt to be too high level.
If instead one uses a system where lower level script is used, such as Python or lambda calculus, then these unintended mistakes can be avoided.
I don't mind the idea of executable English because there are times when a high level language is necessary because the data is remote.  But ideally the lower the level of language the better.
One of the easiest things to do is to adopt CQRS and event sourcing. This forces a good approach to gathering requirements in the first place via Event Storming (see Alberto Brandolini).