Q&A: Bogus “experts” fuel the backlash against Agile development

Java Development News:


By Jan Stafford

11 Mar 2011 | TheServerSide.com

Beware of Agile software development experts who are pseudo-Masters, said Agile Manifesto co-signer Jon Kern, who will dissect today’s burgeoning “I hate Agile” movement at TheServerSide Java Symposium next week. The current backlash against Agile can be placed partially on the heads of under-trained, under-experienced Agile coaches, Scrum Masters and the like, as well as the quick-fix-it attitudes of the organizations that hire them. In general, many expect miracle results if Agile tenets are followed rigidly, an approach that’s opposite of the flexible way Agile should be practiced.

“There are about 100,000 certified Scrum masters out there now,” said Java and Agile development veteran Kern in a recent TheServerSide.com interview. “So, part of me says, ‘Great, there are people out there drumming the Agile message.’ But, then, part of me says, ‘Are they really masters? Or, do they just have a couple of days of training under their belts?”

In this interview, Kern discusses how the Agile leadership problem came to be and ways to avoid leadership-driven Agile software project failures. Kern is co-author of the Agile Manifesto for Software Development and the book, Java Design: Building Better Apps and Applets.


TSS: What are some of the causes of Agile project failures and the growing dissatisfaction with Agile development?

Jon Kern: The big thing is misinformation, misdirection in starting with and implementing Agile concepts which often comes from ‘experts’ in the field. That misinformation comes from several sources.


A lot more due diligence is needed when choosing a consultant or Agile coach or in-house expert, or following practices a team member, project manager or CIO has picked up during a weekend workshop.

TSS: What are some signs that an organization’s Agile approach is off track?

Kern: You can tell that you’re off track if a CIO, or Agile consultant, or team member or two-day-certified Scrum Master comes in and starts railing on a team for not following some specific process or set of processes. The team doesn’t need to be bashed over the head by what I would call dogmatic Agile practices. Flexibility is almost always needed.

So, the biggest problem, probably, is managers will say that you should be doing the XYZ process. Or, you’re not doing Agile if you aren’t doing pair programming or involving the customer every day, blah-blah; pick whatever ax someone chooses to grind. When the team hears that and is constrained by the realities of the situation they’re in, I think that gets very frustrating for them. So, some of them start hating Agile; but Agile is not to blame, the leader is.

TSS: What is your approach to building a strong Agile project team?

Kern: I have always tried to just do my best at getting a team to be as agile as possible. It’s all very relative. I’ll usually start off at the same point; but sometimes just the circumstances -- what the team knows, the members’ skill level, the culture -- calls for changes. For example, if I work on insurance projects or some health care projects and/or with big companies, I find that they are often more risk averse about their projects and applications. For them, the whole culture isn’t quite ready to be razzle-dazzle small-team Agile.

TSS: I hear the most complaints about rigid adherence to Scrum and the leadership problems caused by two-day Scrum Master Certification courses. Do you?

Kern: Partially. Part of me thinks it’s a good thing that a company that is very non-Agile is at least trying to embrace the Agile way by bringing Scrum into the organization. But at the same time, I think Scrum is an easy sell; because it’s like, ‘Oh, well, I guess instead of our Microsoft Project Gantt charts, we’ll just use the Scrum process for project management’. And they don’t do enough of the other, non-Scrum Agile practices to really make it count. For example, the customer still submits gigantic requirements -- 10-page use cases with 67 alternate paths -- and they don’t actually participate with the team. You know, they just throw it over the wall.

So, okay, maybe it’s a good thing that you’re bringing Scrum in; but when you don’t really do Agile and it doesn’t work any better than what you were doing, don’t blame Agile.

TSS: That goes back to what you said about misinformation and misinterpretation of Agile.

Kern: Yes, it’s just hard sometimes to take a single practice, throw it into a group without the true understanding of the Agile mindset, and expect it to work its magic; because it usually doesn’t.

Part of my TSSJS session Agile Schmagile, The Backlash Against Agile will focus on how Agile is much more holistic than people make it out to be. I was an aerospace engineer. In that work, it’s critical to think holistically, because you can’t just wiggle one part of the system without it affecting the others. The same thing is true in Agile, and that’s why I embraced Agile.

Don’t blame Agile, because it can often be something else that’s going wrong. Is there a way that going Agile can create a barrier to delivering good software in and of itself? Or is it usually some other process that’s being done incorrectly, and Agile gets blamed?

TSS: I've heard some managers grumble about developers using Agile as an excuse to slack off on the planning side of things. Does that sound fair?

Kern:  Well, I guess I’d have to see all the specific circumstances, but certainly, if you do Agile poorly -- and a classic example might be doing a handful of the processes that seem to fit your needs -- if developers are just barging ahead and writing lots of code and not following up with or even meeting it with behavior-driven development or test-driven development. And telling the management that oh, we don’t need all this structure anymore; we’re going Agile.

And using it more as an excuse to just do coding and not really be a professional craftsman. And the problem is you can sometimes succeed early on, because you can whip something up, get it out the door, and it looks great. You know, you’ve got people smiling. But it could be a house of cards if you haven’t been paying off the technical debt, i.e., you might be incurring debt just because you wrote code without tests.

TSS: Can using just some parts of the Agile methodology be a successful strategy?

Kern: You can apply part of the Agile practices, think you’re Agile, get some early successes, but then find yourself up against a wall with a lot of technical debt. And then you start blaming, "Well, we were following Agile." Well, okay, yeah, each of your individual practices was Agile, but you weren’t doing enough of a holistic approach to do a full suite of approaches that was necessary to keep you from failing or stumbling.

Agile is all about reducing the time between an action and a result. Whether it’s, ‘The sooner I realize we wrote a piece-of-crap program, the better,’ or ‘As a client can I stop it?’ After all, if a business gets intertwined with software that is actually growing technical debt in an exponential manner, it could cripple the company as a whole.

 So how do we, as an industry, make software visible soon enough that we and the user can see it from the bottom of the iceberg to the visible top? If we as an industry could crack the code on figuring that out, the value for us and users would be tremendous.

Related Resources