Slashdot Mirror
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.
Sogeti has been presenting marketing as research for years with their World Quality Report: http://www.sogeti.com/solution.... This smells similar.
I'm pretty sure I like payroll to deliver every 2 weeks.
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.
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.
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.
Good people go to bed earlier.
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.
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.
Helping with organizational effectiveness is our job.