Why agile isn't enough for many software projects

Why agile isn't enough for many software projects

Summary: Agile and scrum — which encourage team-based partnerships between developers and end users — don't work well within large or complex environments, an expert has warned.

SHARE:

Agile methodologies such as scrum are good practices for software development teams, but they become problematic for large projects. Developers should be willing to "step back" from agile to incorporate other methodologies to get the job done.

That's the advice of Mark Lines, partner with Scott Ambler & Associates, who argues that while scrum is a good starting point for agile in the organization, it falls apart when large teams are required, or if software development takes place in different locations across the globe.

"Scrum assumes you work in small teams, ideally collocated in one room," he pointed out in a recent interview (see video, below). "You don't have to talk to other teams in regards to architecture requirements and things. You can make all the decisions about the project yourself."

However, most agile teams don't all work in the same room, or even in the same city, for that matter. To offer new ways to address these challenges, Lines and Scott Ambler published a book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise, which surveys available alternatives to simple agile practices. Disciplined Agile Development (DAD) is a decision process framework that "brings together some of the good practices from the disparate set of methods that out there and combine it into a whole," Lines said.

"It would be nice if we were all collocated in small teams, and we didn't have to talk to anybody else, but that's not a reality," he continues. "What if you're in situations where you need to more than what a classic agile project would ask for?" Examples of software projects beyond the scope of agile include applications subject to regulatory mandates, or complex programs such as software for rocket ships or medical devices.

Teams are larger than two to nine people like scrum would prefer. There are a lot of other concerns in the enterprise, like architecture, database standards, and governance, that haven't been talked about with other methods."

"Were seeing Agile projects with 300-person teams. You cant obviously be collocated, so you have to figure out a way to make that successful and still be agile," he said. Also, you have off-shoring ... outsourcing, distributed teams, technically complex, functionally complex applications."

By applying DAD, developers pull in the best practices across a range of methodologies.

Topics: Enterprise Software, IT Priorities

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

4 comments
Log in or register to join the discussion
  • Very nice

    Thanks for sharing. I will most certainly pass it on. BTW, the video seems to be embedded twice by accident.
    gamoniac
  • How Would You Characterize Linux Kernel Development?

    15 million lines of source code, around a thousand active contributors submitting 11,000 lines of changes per day (about half of that new code), managing a new major stable release every three months. Running on two dozen different major processor architectures.

    Does that fit your definition of "agile"?
    ldo17
  • Scrum works just fine long distance

    I do it regularly. Have these people never heard of Skype?
    Mac_PC_FenceSitter
  • Broad statements, squishy terminology

    When the term Scrum is used, we know this is referring to very specific practices. The term "agile" however lacks formal boundaries. I often find commentary peppered with the word agile to be meaningless.

    Lack of collocation (as defined here as individuals being face-to-face) is going to negatively impact collaboration regardless of the methodology used. This is not a "Scrum problem" - and I don't buy that it is worse in Scrum than other methodologies (or lack thereof).

    Also find it curious that someone would coin regulatory guidelines as "out of scope" on any credible project approach but I guess I need to read the book.
    B.A.