Product Development & Management

Your Team Says It’s Agile, But Is It Really?

By |

Your Team Says It's Agile, But Is It Really?

Putting the development methodology into consistent practice is a lot more difficult to sustain than many realize, and teams often have trouble sticking with it.

Plenty of patience and discipline is needed to really see results from Agile. If your team has neither of those qualities — and, given increasingly demanding timelines, that’s not unusual — you’ll likely see regression into familiar patterns. You may also end up with some sort of hybrid, homebrewed methodology that’s unique to your team and falls somewhere in between Agile and Waterfall (“Scrummerfall,” if you like) but hasn’t been optimized for success.

According to author and consultant Greg Cohen, engineering processes associated with Agile — such as Extreme Programming (XP) — need to be maintained for months and months before progress is made. We talked with him a little bit about that, as well as why Agile might not be the best fit for every team.

Jama Software: What are some trends you’re seeing within product development teams at the moment?

Greg Cohen: What’s more interesting is the negative trend. And that’s the idea that seemingly all teams at this point almost have to say they’re Agile.

Everyone’s claiming to be Agile, but what I see is that the majority of teams are really struggling with it. And I heard a great quote from one of my clients recently. They described their processes as “somewhere between Agile and the Wild West.”

What I find is that there are far too many teams that are more ad hoc and not Agile. You know, they’ve thrown away the discipline and structure of Waterfall, but they haven’t really adopted the discipline of Agile either.

So they’ve gotten rid of process and haven’t embraced the empirical process that Agile requires. And it really is a very disciplined process and requires an immense amount of work to do well. And to stay focused and keep up with everything you need to do. So I think teams struggle with that.

JS: That’s not all teams, of course.

GC: The teams that I see that are highly performing, highly productive, they really get the productivity boost out of Agile. They get the quality boost out of it. But in order to get all that, you have to do the engineering practices, which these days often include terms like “Scrum with XP,” and particularly test-driven development and continuous integration.

And I feel, in some ways, Scrum did a disservice because it’s a process framework. And they never said you need to do these engineering practices. They didn’t want to specify that to the teams.

So at the same time teams adopted Agile, they sort of took on what I would say are the easier events and rituals of Scrum, without making those deeper changes in engineering that are really required to become a high-performing team.

JS: What are some of the challenges teams run into when transitioning to Agile, where they land in between methodologies?

 GC: To do incremental development, you need to know that what you’re putting into production, or even QA, isn’t going to break the work that’s already been done. And if you don’t have that ability, it’s just not scalable to do it with standard testing or big regression tests.

I think that’s the problem teams get themselves into: they just can’t move fast. It’s hard and it gets chaotic.

From a development standpoint, there are engineering practices that are essential. Those are like XP practices, test driven development, and continuous integration. And these are what allow teams to work iteratively and safely.

So if you have a large legacy code base? It takes time to build up the test cases. And sometimes you have to create an abstraction layer so you can sort of isolate that legacy code. And slowly replace and refactor it, as you work on upgrades and new features and capabilities without risking some unintended consequence in that code base.

When you talk about older organizations, they’re dealing with legacy code, and that’s a much harder problem than just greenfield development on a new product.

JS: What are some development environments where you might say Agile might not be the best fit?

GC: I had this client once and there were two projects we were talking about.

One of them was critically important to the company and it needed to get to market quickly and it was new development.

They had another product that had been around for many years and the team did one major release a year. They followed a Waterfall method. They consistently released on time and they released with the planned scope. It was a well-oiled machine. And those releases came at an appropriate cadence for the market. It was an older code base. It was legacy customers. They weren’t out marketing and selling this product. They were just supporting their customers on it and continuing to improve it as those customers wanted.

If you’re talking about going to go through this change in process by moving to Agile, you’re going to experience an initial drop in performance. Because any time you do a big change, people have to learn new roles and skills.

For this client, would I recommend they switch to Agile for that legacy product? I think that’s a very tough sell.

Could they ultimately improve the productivity of that team? Absolutely, but they’re selling to an already captive audience. The market is static; it’s not changing quickly and there’s little competitive pressure. If you look at that, and ask which project should I apply Agile to, it’s not the legacy project.

Maybe if the entire company masters Agile development through their cutting-edge product? Maybe at some point it’s worth switching this other team over to Agile, but it’s not where I would start.

JS: No need to fix what’s not broken if they’re hitting their marks.

GC: Exactly. They’re hitting their marks, the market wasn’t very dynamic and there wasn’t a lot of competitive pressure. If that’s the case, stick with Waterfall because they were executing very well with it.

Looking for more guidance with Agile? Check out our white paper, Agile for the Enterprise.

Latest posts by Kevin Smith (see all)