Mixing Agile With Waterfall For Code Quality

jones_supa writes: The 2014 CAST Research on Application Software Health (CRASH) report states that enterprise software built using a mixture of agile and waterfall methods will result in more robust and secure applications than those built using either agile or waterfall methods alone. Data from CAST's Appmarq benchmarking repository was analyzed to discover global trends in the structural quality of business application software. The report explores the impact of factors such as development method, CMMI maturity level, outsourcing, and other practices on software quality characteristics that are based upon good architectural and coding practices. InfoQ interviewed Bill Curtis, Senior Vice President and Chief Scientist at CAST, about the research done by CAST, structural quality factors, and mixing agile and waterfall methods.

Comments

Agile is the answer to everything

[sandbagger]

The only reason why you disagree is because you're doing Agile wrongly!

Yeah right. The Agile moonies need a slap. If Agile is so wonderful why don't you walk over to payroll and tell them to adopt it?

Re:Agile is the answer to everything

[i kan reed]

I'm pretty sure I like payroll to deliver every 2 weeks.

Re:Agile is the answer to everything

[Anonymous Coward]

Having done pretty much what this article is calling for. Dont do it.

Both methodologies work. They are however like oil and water. It allows for sloppy planing with the idea you can change it later. It does not work. Even with agile you want some sort of end goal plan. But not all the details worked out. With waterfall you try to figure out all the details and usually get them wrong or forget what you were doing 2 years ago.

You will end up with the worst of both methodologies all in one nice neat package.

If you are outsourcing you want a waterfall as you need nice neat checkpoints of saying if your external vendor did the work at all and should be paid. If you are doing internal work agile can work very nicely *IF* your organization is ready for it. If the rest of your organization does waterfall you will end up with a blend that does not work.

The two do not mix. If you do it you will suffer.

Re:Agile is the answer to everything

[Shados]

Joke aside, that's basically the issue. "You're doing it wrong". Now there's various flavors of Agile, and one size doesn't fit all. But often, when people use "hybrids", instead of using the best of both worlds, they use the worse.

So we want sprints, but I can't just let my engineers work unchecked! So we'll have a full day planning meeting every 2 weeks, and a checkpoint meeting every week. The daily standups are going to last 45 minutes, and the PM will also have a 20 minute talk with each individual every day to see if anything changed during the day!

Now, I also want the full design documents and architecture up front, before the sprint start, lets have everyone sign off on it, and if anything changes, we'll just extend the sprint. /true story, happened at my last job...I quit a month and a half in.

Nothing is set in stone and each company has to figure out what will work for them...but virtually all the "hybrid methodologies" or pseudo-agile I've worked in only took the parts of Agile that suck, slapped in the worse parts of Waterfall on top, then wondered why it was a shit show.

Re:Agile is the answer to everything

[pixelpusher220]

We're doing a mix of Agile and Waterfall. I call it Drunken Sailor...it's about as productive.

Re:Agile is the answer to everything

[znrt]

I agree that it can work - IF you have good people. That's rarely the case, so it usually fails

this. agile was the experience of a group of highly skilled and motivated professionals in a very specific setting. they had intuitively adopted some practices that were already known, and then called their whole experience "agile" and produced a recipe for it.

what few understand is that this recipe is simply not universally transferable. talent and motivation are the real drive. given those, everything else can be figured out in many ways: probably any combination will work in such a team, they just chose what suited them best.

but none of them will work in a zoo. no matter how many evangelists and bananas you throw at the monkeys.

Marketing or Research?

[yorgo]

Sogeti has been presenting marketing as research for years with their World Quality Report: http://www.sogeti.com/solution.... This smells similar.

Shocking News - One Size Doesn't Fit All

[i_ate_god]

I'm as surprised as you are...

I tried this. Once.

[xxxJonBoyxxx]

In the late 2000's our fast-moving company was acquired by a slower one out of Boston coming from a history of using waterfall and experimenting with agile. The result was an unmitigated disaster. We had a bunch of Siemens castoffs demanding detailed project plans, down to the exact fix we would implement for every bug, for software six to nine months out. Then we ran agile within dev teams to knock off specific pieces of the application. The combination exposed the worst of both worlds: a lack of flexibility which hurt us in the marketplace and annoyed top customers, and a slow-down of team productivity once they realized that pulling additional work into a sprint wouldn't get them any rewards. And that was before we started to have to tack on "quality sprints" where QA would spend 3 weeks looking for bugs and separate dev teams would react the FOLLOWING sprint.

So...what have I seen work? Define which MAJOR features make up a release, direct agile teams to code toward those, enforce test building at all levels, and REWARD teams that are kicking butt, whether that's churning out some of the MINOR features, being the team known for "bug-less" code, working with UI folks to write up a new interface that customers love, or whatever.

It never ends

[Forgefather]

"CAST Research on Application Software Health (CRASH)"

Is this what computer science has come to? Nested acronyms?

For fucks sake keep your names short and to the point.

none of this does real work

[nimbius]

I dont know what the hell "discover global trends in the structural quality of business application software" means but Agile and Scrum are just excuses for more meetings or magic meetings where we all have to stand instead of sit down in the $4000 worth of new conference chairs we bought. DevOps is just "Synergy" with a new coat of paint. Its a chance for ops to be forced into writing code for projects they arent a part of, and a chance for developers to be forced into firefighting.

Management needs to realize that buzzwords dont write code. Every time you call us into a meeting for a slow-stroke on the latest fancy phrase it disrupts exactly what we're paid to do.

Agile in Aerospace

[Anonymous Coward]

Aerospace is one of the most conservative coding industries out there. We've found a combination of waterfall and agile that works. We use agile for UI development within each waterfall. It turns out that, in spite of decades of human factor research, getting UIs right is very, very hard. So, we've been using a mixture of agile for the UI itself, and waterfall for everything else, and only pushing the UI to certification when a build is going forward. This allows us to (forgive me, engineers) unfuck what the engineers dreamed up, get to a useful interface, and then still have some time to fix (really reverse engineer) the design documents to get them to match the UI. This has worked very well.

Quality and Productivity

[under_score]

Disclaimer: I work as a consultant for large and mid-size businesses.

My experience is that there is no magic bullet for quality, but that there are a few things you can do that will dramatically improve things. What Agile methods bring to this is that they provide fast feedback with customers and users. This means that if the team actually bothers to use the feedback, that they can produce things that have better customer and user perception of quality. Additionally, Agile engineering practices such as refactoring and test-driven development can be used to effectively prevent most technical quality problems. Agile borrows heavily from Lean thinking in which one of the ideas is to build quality in (instead of testing at the end). Lots of practices of Agile methods support this idea and, on rare occasions, I have seen Agile teams building complex systems with defect rates close to 1 or 2 low impact defects per year.

That said, the disciplines of waterfall thinking are often lost when an organization switches to Agile. These disciplines around deep analysis, seeing the big picture, etc. are all still important. They should be done differently with Agile, but they shouldn't be forgotten.

Unfortunately, most teams and organizations do neither waterfall nor Agile well. This is because management has a poor understanding of what it takes to properly support staff who are doing complex creative problem-solving work. Instead, management tries to control staff as if they were assembly-line robotic resources. Ultimately, to be effective with software development, management needs to treat software developers as each being unique, autonomous, and deeply valuable for their own talents, skills and experiences. Likewise, software developers have to stop treating customers and users as idiots... they're not. Agile methods, as a set of values and principles, are about changing these relationships to make them more healthy for everyone involved.

Re:I tried this. Once.

[tomhath]

the root of that issue is that customer was not aware of the internal process change

The root of the issue was that the project managers managed it waterfall/PMI style while pretending to be agile. I've seen that happen too many times - you go into sprint "planning" and are handed the list of stories that the PMs already decided will be worked that sprint.