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...
BINGO!
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
Having working on what was supposedly a "CMMI Level 3" project, CMMI is utter crap. It is so focused on process that the actual job (you know, developing the software?) becomes just another checkbox. When the job itself turns into "hoop-to-jump-through number 14 of 27" everyone mentally checks out and quality rapidly approaches 0.
Plus, since CMMI doesn't specify any particular set of tools, and exists merely as a "framework" for guidance, it allows your organization to make really bad decisions and enact mandatory use of really terrible tooling, as long as it's "industry standard."
Not to say that my organization actually used industry standard tooling. What they were using was custom-built and -configured, which, by definition, cannot be "standard" in any way. Which, of course, begs the question: How the hell did they get certified? I have to assume that the CMMI auditors were corrupt in some way.
Speaking of corruption: How is it legal that the government can mandate a specific CMMI Level in order to compete for certain contracts? A CMMI Level can only be granted by paying money to one specific company (the CMMI Institute was spun off of CMU as a for-profit enterprise)?
So, in conclusion, avoid CMMI like the plague.
"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.
All these "methodologies" are just orthodoxy. Any competent developer will always blend the two.
Business requirements should always be nailed down first and absolutely (Waterfall..kinda). Business practices, processes and requirements by their nature are fairly static and rarely have radical changes (if you are in a stable company, operating in the black). The tools and methods you use to automate/implement the tactical aspects of the business practices are what change...Agile.
This was called cinnubun 20+ years ago. Stop pretending to invent new shit.
Because while you will be a waterfall, you are by no means agile!
Poll: Program while drunk? Can do, or no way?
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, or it was not communicated in the right way. it had nothing to do with the fact that it was mixed, and everything to do with how the transition took place.
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".
The basic dogma is that it works. If it does not work for you, it is because you are doing it wrong.
Quite frankly, all these methodologies that have been foisted on the software development world throughout the years amount to little more than fads with very little in the way of a scientific basis. They are just modern day snake oil.
if this tool can analyze structural quality they should create an open source plug in to sonarqube. additionally they should show the results of the tool and not someone's analysis of the data in text format.
Agile is garbage and is for morons that can't write good software without their hands being held.
Agile, scrum, whatever. They are just buzzwords for some sort of kool-aid to empower programmers when they feel powerless. None of this can ever work unless the folks ordering the software or software changes know what they are asking for (rare) or provide an unwavering list of requirements. Most software projects go over time estimates or fail because of SPAC. Specification Provided After Completion.
>> 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.
and airliners were designed and built using Agile engineering methods.
That's right, exactly zero.
Software development is not making the same widget again and again. This is the fundamental misapplication that is messing up agile implementations.
Software grows more like a city. Any new functionality needs to interface with and restricted by existing infrastructure. A large software project is like adding a new skyscraper to an throbbing downtown. If we could distill the collective wisdom of the town planners about clearly marking existing interfaces, existing users, the typical use case scenarios that will be affected by the reengineering, detours and diversions needed while the project is going on, we would get a better process. Agile is simply promising too much to the top management and then blaming the developers for "not doing agile right".
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Drunk Developing?
I work at home a lot. If I'm doing detailed coding, complicated architecture, or other stuff that has to have all the details just right, no way.
If, on the other hand, I'm brainstorming ideas on a high level - how might I design an interface for this particular crazy business requirement, what cool features might I toss into a project, etc., a splash of Jack in the morning coffee can be of benefit.
Sadly, I'm tweaking interface code to a payment gateway API this morning, so stone cold sober. :(
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.
Except city planning is expected to grow and plan over years. Try telling that to management, who always asks why the software project is talking x time and y $ and not 20- 30% less on each dimension.
From what I hear, this is all old news anyway and we should all be switching to devops!
Like we used to do in the 90s and just called it 'engineering'.
Korma: Good
Exactly this.
And it gets worse for some flavors of agile, for example where any programmer can get assigned to any task any part of the code, etc.
Aside from the implicit assumption that all parts of the code are equivalent and all programmers are interchangeable, which may be true to some degree for the corporate IT projects that some agile books use as their wonderful success stories and basis, this fights human nature. Some people are productive and happy bouncing around different parts of a project, but others are more product and happier when then get to drill down and focus and become expert in one particular area. Its just the way people are wired, some one way, some the other.
A key to good management is to figure out what work styles and methodologies fit each individual programmer so that their productivity (and hopefully happiness) can be high. That's the problem with these "here is the one true universal answer" methodologies, they fight against human nature. Admittedly this may not be a problem with agile in general but it is a problem in some flavors of agile.
They're NOT coders and talking out their asses. QA, Project Managers, etc. (bullshit artists that have NO CLUE on how or why apps are written as they are). Sorry to those of you that actually code though. This isn't directed your way. The ONLY THING that really works is good decisions on the part of the customer, who commits to them in writing, and doesn't change scope or features much (and is billed for times they do and is willing to pay up). All this "agile" bullshit is just that. Bullshit. Too much change and you never actually get anything done. That's a fact. Any real dev will tell you the same. You hit a shop using anything else? Run. Quit. Leave. You're wasting your time and theirs until they get their heads out of their asses and perhaps hire former coders as project managers who understand how the process of SUCCESSFUL development is actually done so it works, successfully, on time.
Actually, we discovered the same thing: that it's better to mix agile and waterfall. Already in 2006 we wrote about it in our project management manual, that was released then open source: http://www.projectmanagement-training.net/book/chapter6.html
We know all the problems of 'pure' waterfall, but some things are just missing in 'pure' agile. For example to set clear goals for the project or do some initial thinking anyway.
They already have a name for this.
From the wiki:
The Avalanche model is a Software Engineering project management anti-pattern, it is a combination of a sequential process such as the Waterfall model and Agile software development methodologies. It is the result of a Project Manager's attempt to apply Agile techniques to a project, when all they really understand or were taught was a sequential development cycle. Instead of breaking the project into parts that each sequentially go through the phases of development, the entire project inhabits all phases of development simultaneously. Usually the result of attempting to use the Avalanche model is mass confusion, wasted effort, and a product that cannot meet the specifications of any requirements document.
We'll call it "Mudslide".
Have gnu, will travel.
You use the tools the way they were designed AND purposed (folks forget the 2nd part). And you use the tools for their strengths, not their weaknesses, aka as needed--which is also known as experience.
Otherwise you're just following a religion.
And to try to control project risks, we have many best practices. Some work well in a given industry, some don't; some work well for a given product, some don't; some work well in a given organization, some don't; some work well for a given team, some don't; and some of them work well together, others don't.
The sad thing is that we underestimate these contextual issues, everywhere in our industry - from process consultants who want to sell their expertise, to Agilistas who sacrifice their objectivity to their god, to PMPs who want a schedule down to five minute increments before they're satisfied (and your status reports for each of those tasks had better be in order, Buster!), not to mention business people demanding irrelevant statistics (because what's important to an engineering manager might not be important to an accounts payable manager and vice versa), QA teams morphed to process teams (because you engineer in quality, not test it in) who demand the same processes across the company (no matter what's being built), to VPs who tout metric gains that don't fall outside the boundaries of noise, given the process being measured, etc., etc., ad nauseum.
However, to me it is unsurprising that companies that decided to roll their own processes rather than "cookie cutter"ing one are doing better. They're probably more attuned to their environment than any company in the throes of iatrogenic Agilista or PMPing agony will ever be.
That is all.
I feel your pain. Luckily I just got promoted into a Dev Lead role, where I take part in those meetings that decide what goes into the sprint and am in a position to try and influence the PM into a more agile way of doing things. Of course, when we even suggested to him that the team would tell him how much of what he wants they think they can actually do he was scared as hell. It wasn't getting through to him that he's not even giving up any control, while gaining on the team side, because they will care more about what they've actually committed to vs. something that was handed down to them as "do or die".
We're using FrAgile and Waterfall and our project has had to be halted for the second time in two years.
Agile (the way we're doing it, probably the wrong way) doesn't scale. If the project is 100 people, half of whom have never met the other half, then a daily meeting is impossible and attempts just degenerate into people checking off boxes but mainly consuming enormous amounts of time without actually communicating anything of value.
On the other hand, my personal suspicion is that "Agile" was really the vendor saying they could adapt to very fluid and evolving requirements when in reality they never understood the requirements in the first place and had no intention of ever fulfilling them. Maybe 'real' Agile would work better.
Aye: http://gilesbowkett.blogspot.c...
At least you got an acquiring company. When we went agile, we hired a bunch of assholes who killed our margins, and with it, the only chance that we'd get acquired. We were fucking profitable once.
It's not about mixing waterfall with agile, it's about mixing a waterfall organisation with a pseudo agile team of developers. Been there, done that.
They call this lack of productivity, I call this structural inertia and company lack of change.