Under-educated and inexperienced Agile development “experts” have l the current backlash against Agile, says Jon Kern, Agile Manifesto co-signer, in this Q&A.

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?”

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.

Misinformation or, let’s say, misinterpretation of information often happens when CIOs and others hear a talk or read an article that’s not so good, or rather brash and harsh about waterfall or keeping to rigid Agile practices. When that’s taken out of context, it can cause big problems.

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.

Join the conversation

2 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Your password has been sent to:

Please create a username to comment.

This seems to be a growing problem. Matt Heusser gives a talk called Save Our Scrum, and its amazing how many of the problems that get brought up at a talk like his are really due to misreading, or applying methodology intended to support Agile practices, and either ignore the agile manifesto entirely or ignore the principles for which it sets out.