News Stay informed about the latest enterprise technology news and product updates.

Agile practices: Misuses and misperceptions

Expert Joseph Flahiff explains why Agile practices aren't just about "being fast," and discusses other misperceptions about managing Agile projects.

Agile and Lean expert Joseph Flahiff is president and CEO at Whitewater Projects Inc., which provides Agile project training and consulting services to enterprise organizations. He previously worked for a multi-state health insurance company, providing Agile project management and training for a three-year, $20 million project that coordinated the work of more than 100 team members. Here, he discusses how enterprises misuse Agile practices, and clears up some growing misperceptions about the meaning of Agile project management.

You focus on the Lean and Agile practices of project management. How are these disciplines changing, and what is bringing about these changes?
In 2008, the PMI [Project Management Institute] found that 12% of enterprises were using Agile, and [by 2011] 27% were using it. It's huge, the movement towards using Agile techniques. I have people who come to my class and say they are doing Agile. When you drill down into what it really is they're doing, they say, "We're delivering in iterations" or "We are doing a daily stand-up," but they're not necessarily using Agile as the general industry would define what Agile is. 

Joseph FlahiffJoseph Flahiff

If they think they are following Agile practices but aren't, what should they do differently?
I'm not sure they should be doing Agile anyway. Back in the early 1990s, Ken Schwaber and Jeff Sutherland came up with Scrum as a response to problems they were having with their existing project managers and the approach that project management was taking to try and put structure around software development. The existing project management structure they had to follow came from the construction industry and a 75- to 100-year history of construction project management. Software is not like construction. With construction you know what's coming out the other end -- it's a building, here's the blueprint. In software it's a "I'll know it when I see it" kind of thing.

What we're now doing is continuing to take their [software development] solution and apply it everywhere across the organization. So now, enterprises are having some of the same problem sources that people had back in the early '90s, with having to use a discipline for the construction industry for software development. People now are trying to apply Scrum as a solution, rather than looking at their problem and coming up with a solution. They're trying to take what works in one place and assume that it's going to work for them in other places without fully understanding what it means to implement Agile.

Is there a fundamental disconnect between what people think Agile project management is and what it really is?
Most people who take my Agile and Lean fundamentals class just want to learn what is this Agile thing and how do I apply it? When we get into what it really takes to do Scrum correctly -- and these are things that break it for most companies, like the need for 100% dedicated people and teams and fully cross-functional teams -- they say they can't do that. With Agile, you need "specializing generalists" who can jump on many tasks in a project backlog. In many organizations, that doesn't work -- when you have very deep tools and technologies, where people really know that and only that. People in the class say, "Well, having a dedicated team of people and generalists doesn't work for me."

So, the question is not "How can I apply Agile?" but "What is my fundamental problem here and how can I resolve it?" Most project managers like solving problems, so this plays well into what they like to do, but instead we [as a corporate society] tend to look for the answer and what to apply to the answer.

I have heard Agile practices defined as "being fast" above all else. Strategy becomes secondary to getting things done quickly.
There is a big disconnect with people taking Agile completely out of context. One of the books on every good Agilist's shelf is Mike Cohn's Agile Estimating and Planning. The [title's] second word is planning. Agile project managers do a lot of planning; we have vision plans and roadmap plans and daily plans, iterations plans. As a matter of fact, there is more planning that goes on in Agile than there is with traditional approaches like Waterfall because you're constantly updating and adapting the plan. It's quick and very dynamic, but there's a lot of planning.

A recent MIT Sloan CIO Symposium presentation talked about "being agile." Facebook was used as an example of this, with one speaker remarking that Facebook likes to say it doesn't do strategy because "by the time we have a strategy, the world has changed."
That is a strategy. It says that we are going to adapt in the short range. I don't know if that can be a long-range corporate strategy though. I would argue that they do have some long-range planning and that they do have some long-range vision. That they don't have long-range little steps -- I'm all for that when things are far out in the future and you don't know what's ahead. What they have is a long-range vision and short-range tactical plans toward that.

In your experience, how are Agile practices being applied in the wrong way in enterprises?
A client told me they are seeing Agile being used as an abusive approach in their organization, just to be able to say, "We need to go faster, push our people harder. We're going to be Agile so we need to go faster, faster, faster." Well, no. Agile is 80% culture and 20% practices. The culture is one of trust and self-empowerment, of self-motivated teams.

Daniel Pink talks about how autonomy, mastery and purpose motivate people today. If you can get behind giving people autonomy, letting them set their own direction, helping them master whatever it is they're working on and connecting them with the overall purpose of their organization -- what are we here to do? If you can connect people with that purpose, then motivating them doesn't become a carrot and stick beating them over the head to make them go faster. People are motivated to go faster because they're excited about what they're doing and they do deliver faster because they want to.

Let us know what you think about the story; email Christina Torode, Editorial Director.

Next Steps

Agile project management, from Agile to Waterfall

Choosing a management approach that clarifies Agile project completion

Agile project management approaches for on-time and on-budget delivery

Dig Deeper on IT project management and portfolio management