This content is part of the Essential Guide: Making the Agile development model current again
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Agile practitioners, focus on the end result -- not the process

It's a DevOps world. So where does Agile fit in? Expert Jeffrey Hammond weighs in on the problems with Agile today and how to keep it relevant tomorrow.

If it's a DevOps world, where -- and how -- should Agile fit in? With Agile 2017 on the horizon, senior technology editor Valerie Silverthorne turned to longtime industry watcher Jeffrey Hammond, vice president and principal analyst serving application development and delivery professionals at Forrester Research, for some insight. Hammond, who was an Agile practitioner himself while in private industry, didn't hold back about his frustration with Agile and its proponents today.

Agile 2017 is just around the corner. Where is Agile today?

Jeffrey Hammond: It feels to me like there is a little bit of an existential crisis in the Agile space. There is so much focus on scaling Agile and one of the consequences of that is a lot of formalism is creeping into a lot of large organizations. I had a call with a customer in the mobile space and he wanted to know what other companies did to release mobile apps faster. After talking with him I said it sounds like he was doing all the right things and so what was bothering him? It turns out that his IT people were telling him he was not doing Agile the right way. His group was not conforming to the standards of other groups in the organization. Oh my God ... have you not read the Agile Manifesto and do you not understand it? It sounds like this company has just replaced waterfall with the Agile process.

When companies talk about what they're doing at Agile 2017, what are we going to hear?

Hammond: There are three phases of Agile maturity. The phase I see are shops which do Agile by process. They are all about the process of Scrum or XP or SAFe. These companies are missing the forest for the trees. That is never what Agile was meant to be. It was supposed to enable developers to get results by empowering them. Part of the original Agile Manifesto said companies need to do what works, measure the results and trust in the people not the process. Now there are a lot of people doing Agile that are left like the Catholic Church before Luther -- they're so focused on the process they've lost their way.

There are two additional phases. There are shops that are Agile by practice. These companies more fully conform to the Agile idea. They're doing Kanban, minimum viable product and design thinking and they're borrowing tactics from different places. If it works they adopt them. They are just trying to deliver good software as fast as they can with processes that work for their teams. Different teams get different results from the same practice and that's a hard thing for large companies that want to standardize everything. But if you think about the way movies are made, every director does it differently. The important thing is to be focused on the results and not the purity of the processes.

Let's think a little bit more about how we enable more people to develop software.
Jeffrey Hammondvice president and principal analyst, Forrester Research

The third level of Agile is the companies that do it in spirit. They're not worried what to call it. Instead they're focused on the culture and building cross-functional teams where developers sit with digital people and business people and they hire top talent. When you look at how these companies work they wouldn't think of not doing anything other than two to three week sprints or not instrumenting an app. Keeping developers separate from the business is not how they work. They create tribes, have dinner and lunch at the office so developers show up at 9 a.m. and are still there at 7 p.m. It's a social culture, as well as a work culture. It's like this: When a group started it wasn't trying to do Agile, it was trying to solve a problem and when the problem was solved they suddenly realized they were doing Agile. They weren't focused on the process or the execution; they were focused on solving the problem.

How can Agile be relevant again? What would you tell Agile 2017 attendees?

Hammond: How do you rationalize Agile with design thinking or customer centric development or journey mapping or ethnographic user segmentation? Shouldn't all of those things be part of delivering software fast? I think so. What are the important things that allow us to measure the results of actions? Agile practitioners need to evaluate how to deliver analytics more quickly. They're really important now. And let's think a little bit more about how we enable more people to develop software. There's a huge developer shortage out there and we need to think how we rationalize low-code platforms with the Agile methodology and the delivery process. Seems like there are a lot of opportunities to evolve Agile, but they don't happen. We have more folks focused on process purity and differences than results. That's why I don't go to Agile conferences now.

And there are other things from DevOps to serverless architectures to Kubernetes -- all of these help develop software faster so Agile needs to take advantage of all these new technologies. We need to be much more experimental and work toward unplanned innovation. It's not about 'Agile only' now. If someone said to me I wasn't doing Agile the right way I'd walk out of the room. It misses the whole point of the Manifesto, which puts people over process. What they can do to work more effectively as a team to deliver software is what matters.

What sessions would be most valuable to you at Agile 2017?

Hammond: I would be looking for any session that talks about integrating Agile with other thoughts, experiences or designs. Also I'd look for sessions on how to measure results and how to do new things. Look for new approaches and avoid anything coming from the high priests of process.

Next Steps

One strategy for scaling Agile that might work

Are we getting Agile and DevOps right yet? Not quite

In the Agile vs. DevOps battle, the winner is ...

Dig Deeper on Agile, DevOps and software development methodologies

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

When it comes to Agile development methodology, what frustrates you the most?
Sprint documentation is the most frustrating, because it is wasteful.  The reality is there always needs to be a single plan document, and each sprint should add to it, not create meaningless isolated goals that are thrown away once the sprint is over.
And by the way, my second most frustrating thing is calling a design/implementation cycle a "Sprint".  It is not a race, and any sports analogy is a very poor idea.
Value vs. Waste - very much depends on how things are done. Yes, it is easy to create paper that will never be read. On the other hand, failure to record key items that will be useful in the future is worse.
Specifically it is Sprint documentation that is wasteful since you don't know if that path is going to be used or not until after the Sprint is over. If programming is being done right, the main document has to be modified to what was really done, after the Sprint, so there is no point in separately documenting and keeping the old Sprint documentation. You are not producing Sprints, but finished programs.
One is (hopefully) providing incremental improvements in value; technically there is not a "finished" program until it has been obsoleted.

More to the point (and as I stated) it is all about how things are "documented". Everything I am about to talk about can be done with a robust ALM tool, or with sticky notes, and a cell phone....

1) State of the Backlog at beginning of Sprint
2) Items from Sprint Backlog NOT Delivered
3) Bugs Found/Fixed during the Sprint
4) Velocity of Value Delivery
5) User Story Mapping [i.e. operations supported at point in time]

I could add dozens (during workshops we do!)....
A life cycle development tool can be very helpful, but it is wrong to consider a backlog existing at any particular time, because depending on what progresses, much of what has already been done may have to be redone. There is no hard line between what was already done and what needs to be done, so Sprints are not at all useful metrics.
What was not delivered in a time interval like a Sprint is also totally useless. What has to happen, has to happen. And no energy should ever be wasted worrying about how plans changed.
Bugs found/fixed should never be documented. They are infinite and totally irrelevant as far as product documentation goes. There is a need to communicate bugs yet to be fixed between groups members, but only until they are fixed.
Velocity of value delivery is totally and completely wrong to ever try to quantify. That only causes people to try to focus on short term gains that reduce long term results. that is exactly what one should never do.
Never up undefined terms like user stories. There are functional requirements, and use cases to test them. There are no user stories.
Each person is entitled to their view. I will not argue with you, but it is clear that you do not accept either the Principles/Values of the Manifesto nor the various ceremonies that have been developed to support them.

All I will say is in closing is that I have dealt with over 100 teams who have had a result of significant improvement in greater than 95% of cases be following what I have alluded to and which you choose to dismiss.

Have a great weekend.
@The CPUWizard, no I understand all the concepts perfectly. The whole point of Agile is to develop the design plan iteratively along with the programming, so that time is not wasted on design detail that get changed during implementation.

My point is not subjective or a personal view at all. It simply is wrong, nonconstructive, and deliberately misleading to make up fake terminology that interferes with communications, such as Scrum, Sprints, Manifesto, ceremonies, etc. That is a attempt at a cult of fake religion, not computer science.
I fully agree with this (pragmatic) point of view. Of course, and in general, we should be as clear as possible on what is being evaluated when questioning methodology/protocol - the WHAT, or the HOW. Regardless, I think we often discover the conflict BY DESIGN in "agile strategy" - the diverse stakeholders often brought together in this process... architects on the one side, project managers on the other.
The point of Agile should be to iteratively refine a design so that you uncover potential pitfalls and stumbling blocks before you have wasted a lot of time on finer details.
In order to do so, all members must share the same design document, and it should be a complete Waterfall design plan after the project is over and there are no longer any unknown.

The problem with Agile is that many people who simply have no plan or know how to manage use Agile as a smoke screen to let their programmers thrash about until they come up with something haphazard themselves.  That is very wasteful and dangerous.  Not planning ahead far enough is the single most dangerous and unproductive methodology, and is the main thing to avoid in anything one does.
If the end result is not a complete, step by step plan as a development document, then it was a failure.  When there is no final document plan after the project is finished, then it can't be maintained and is useless.
  In reality, without a plan, it is likely a mesh of poorly implemented and badly integrated patches.  It is fine to iteratively refine the plan as you go, but the plan must be always be kept ahead of the actual implementation.
My goto for these situations is always a return to the Manifesto. Create (simple paper) way of ranking each items in terms of how well it enables (+5) to inhibits (-5) the relevant Principles. [I do a similar exercise for the value comparisons]. Trivial to do, and almost always very enlightening.