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

[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

[Anonymous Coward]

I was a QA lead for several years, and I can't the number of planning meetings I was in where the org would come up with a completely dev-centric sprint schedule, then demand that we start testing on the very same day that dev started writing code and finish the second dev made their final check-in. "Agile," they said. "Scrum." "Why can't you accept the genius of our plan?"

Buzzwords won't fix the fact that during the first week or two (or more) nothing's been checked in, and anything you slam-dunk in at 11:55 on Friday night at the end of the sprint won't get tested before the release either. To me the solution was retardedly simple: Just shift the test schedule by two weeks, kind of like waterfall, but just a little bit. Just a nod to it.

Of course when we tried it, as soon as dev starts slipping they invariably take the two weeks at the end and use it for more coding, but don't give test another two weeks to catch up, because, you know, fuck testing it when the release date is at risk. (And anyway the PM would have to stand in front of Staff, hot crumpet burning their cheeks with shame, to explain the slip.)

Re:Agile is the answer to everything

[Anonymous Coward]

Bureaucrats hate "Agile" because they perceive they have less control over the process. Which is true, but only in a way. They may have a bit less control over the process, but they still control the product, which is really the whole point.

Micromanagement is bad. Waterfall is micromanagement in action.

Agile is for lameasses who can't scope a project or develop adequate specs, although it's really good for keeping a client on a payment treadmill using the creeping feature creature. That shit might fly for a webapp (or not, in the case of healthcare.gov), but for real projects it's totally unacceptable. Real as in missile guidance systems, F-16 firmware, HDTV software, etc.

And yes, I've worked in those fields.

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.

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.

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.

That's how it always worked

[Anonymous Coward]

Newsflash, this is how projects were 'managed' for the last few decades. MBAs plan using waterfall and, the project is "on track" till pretty much the end of the development phase, and then shit hits the fan during QA. Then, everyone goes "agile".