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.
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?
---- The above post was generated by the Turing Institute. Maybe.
Sogeti has been presenting marketing as research for years with their World Quality Report: http://www.sogeti.com/solution.... This smells similar.
I'm as surprised as you are...
I'm god, but it's a bit of a drag really...
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.
Waterfall + Agile = Fragile
"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.
"There are lies, there are damn lies, and there are statistics"
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.
You just need to use the right mix for the type of project you have, with the main factors being the amount of unknowns and the level of complexity. Iteration is necessary to understand the unknowns, and high-level design/planning is necessary to tame complexity. Just be open-minded, like the fathers of agile intended, and avoid methodology "religions" like Scrum and its multitude of counterparts on the waterfall side.
Strange things are afoot at the Circle-K.
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.
Agile has been around long enough that consulting sales are falling; companies like this need to invent something new to sell. What better way to reach the unwashed masses than a slashvertisement?
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.
...to be met, like being able to be completely interchangeable with other members on your team, and having prior art to reasonably predict every aspect of effort. If that's not the case (say, in an R&D project where certain people are specialists in certain areas), this method does more harm than good. My best suggestion for using which method is to let the nature of the project choose the method, rather than the other way around.
In debates about Christianity, there are two groups: those looking for answers, and those looking to just ask questions.
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.
New Methodology blah blah Agile blah blah blah Waterfall blah blah blah
Nobody wants to hear that! What they want to hear is when their software will be finished or their system ready. It has to work, work reliably, meet the requirements and be on time. That's all the customer wants.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
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".
>> root of that issue is that customer was not aware of the internal process change, or it was not communicated in the right way
The customers here were businesses paying for some high-end commercial software. They didn't and wouldn't have given a s*** that our internal processes changed - they just saw releases slow down, quality drop, and their input seemly ignored.
I'd say the root cause here was that the acquiring company killed the feedback loop between customers and development teams with bloated processes, which then killed productivity, communication, applicability and time-to-market.
Agile and waterfall are *management* methods. Code quality is a function of *developers*.
If you want quality code, stop pissing off your developers, and choose the least intrusive management method, so people can do their work.