Mixing Agile With Waterfall For Code Quality 133
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.
Agile is the answer to everything (Score:4, Insightful)
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 (Score:5, Funny)
I'm pretty sure I like payroll to deliver every 2 weeks.
Re: (Score:1)
But I do not want payroll to be adding or removing features to my pay every 2 weeks.
Re: (Score:2)
Someone in accounting watched Superman III a few months ago.
Re: (Score:2)
Re: (Score:3, Interesting)
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 pac
Re: (Score:3)
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.
I think the point of TFA was that it does work. And on average, better.
Emulsions can be good.
Re: (Score:3)
Pretty sure he understood the point of the article. By personal experience, he disagrees. If you're appealing to the authority of the article - pffft! - authorities on developmental and coding methodologies are a dime a dozen.
Re: (Score:2)
authorities on developmental and coding methodologies are a dime a dozen
I thought people who sat around opining about the code they expect other people to actually write were somehow paradoxically payed much better than that.
Re: (Score:2)
I agree that it can work - IF you have good people. That's rarely the case, so it usually fails.
Managers need to focus on dollars per result rather than irrelevant headcount.
Re:Agile is the answer to everything (Score:4, Insightful)
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.
Re: (Score:2)
I think the point of TFA was that it does work. And on average, better.
That might be "the point" but that doesn't make it true.
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.
Re: (Score:2, Insightful)
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
Re: (Score:2)
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.
You can find bad business practioners in every area. This is hardly a feature of Agile. Plenty of waterfall companies are guilty of exactly the same things.
You, as the stakeholder, are in charge of features. If you don't have them under control, you're doing it wrong.
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.
Hahahaha. Seems to me the news has been full of stories for many years about how things like military software contracts have CONSTANTLY been full of abuses, bugs, and cost overruns. I've been reading about them in the news since I was a chi
Re: (Score:2)
And, many military software contracts are moving to require Agile practices because they are tired of spending a lot of money on cancelled projects with nothing to show for it except a bunch of documents.
Re: (Score:1)
Hahahaha. Seems to me the news has been full of stories for many years about how things like military software contracts have CONSTANTLY been full of abuses, bugs, and cost overruns. I've been reading about them in the news since I was a child.
Projects that are delivered on time and under budget don't make the news.
Re: (Score:2)
Projects that are delivered on time and under budget don't make the news.
Of course. But that argument works both ways. You don't often hear about the Agile successes either.
Re: (Score:2)
right except the part where you call someone a lameass just for working on a different use case.
you wouldn't use the same approach and investment for a social website and a satellite control system, would you?
Re: (Score:3)
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.
My experience with Agile has been the bureaucrats transformed it into just another vehicle for micromanagement. In some ways, an even better vehicle for that than ever before. Daily standups? Sprints? Grooming? Burndown charts? Perfect for micromanagers.
Re: (Score:2)
It kind of depends on which kind of manager, and the organization. My experience is that managers love their illusions of control, but hate actual control because then they have to be responsible for the results. Also, actual control means actual effort. They want burn down charts that they can look at once a week and pretend they are contributing something useful by beating on people when they are not perfectly on the ideal line. Of course, in two week sprints at that interval burn down charts are virtua
Re: (Score:2, Insightful)
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
Re: (Score:1)
Yeah orig AC here. Basically your org failed to follow the steps. It an easy to fall into trap.
Instead of that story failed and needs more time it was pushed and not really 'done' yet called 'done'.
This happens commonly with a poor estimation of time (which comes with experience of many iterations). It is why some agile methodologies call for story points. I usually see people throw out that abstraction and try to use hours which then leads them down the slippery slope of combo. And the idea you can pi
Re: (Score:2)
One of the big tricks I have found is that you actually have to identify everything that might need to be done to get something to "release" (whatever that means in your org). I don't mean like in waterfall with every individual thing in a project plan with an estimate. I mean in general for all stories. i.e. Definition of Done. Then, you identify the things that can and must be done during the story Sprint and that is the sprint definition of done. What is left over can be called release definition of d
Re:Agile is the answer to everything (Score:4, Funny)
Agile is the answer to everything (Score:2, Funny)
Waterfall + Agile = Fragile
Re: (Score:3)
Exactly, we called it either fragile or scrum-fall. Glad i got out.
The reality is this : if you have a good responsible software development team with expert development leads, architects and you have generally sound software development practices you can follow any process du jour and get good quality software out. Otherwise all bets are off and no process buzzwords are going to help you.
Re: (Score:1)
Amen. Also add in analysts who actually analyze requirements and validate functional specs, not just act as stenographers blindly writing whatever a stakeholder says. Bonus points for managers who actually manage by inspecting work products, not just going around the meeting room table asking people "is your work done? yes? ok, good enough for me".
Re: (Score:2)
I try to mix both myself.
Agile has issues in terms of scale. It is great for small projects, works for Medium then as you get larger it begins to fall apart. As you have way too many sprints to choose, that things just do not coincide for a long time. Causing disjointed code segments.
Waterfall is too rigid where you have do this by then. Not accounting much for unforeseen issues, means you have to redo the plan, or if you find that things can be done in a different order is difficult to represent.
I find mi
Re: (Score:3)
Customers need to grow up. The government of The Netherlands (a country with a GDP of ~€600 billion) wastes up to €5 billion of taxpayer money each year on badly managed IT projects. The reality is that projects with a fixed timeline never get completed on time, lending to the "deadlines are meant to be broken" meme. This is especially true for IT projects, as the scope is often not fully known at the start of the project, and will grow as the project progresses.
Agile is all about realism. You jus
Re: (Score:2)
Hourly billing can work, but it does require a level of trust and openness between customer and contractor that may not be possible in many cases. The customer has to trust the contractor is billing for productive hours worked at a reasonable profit. The contractor has to trust the customer enough to open up their operations sufficiently to create the trust with the customer that they are getting the value for their money.
Re: (Score:1)
In a waterfall, you account for unknowns. I've put right in my project plan, "3 months, stuff we didn't anticipate." Waterfall forces the business side to think about what they want. Agile lets them be creative snowflakes all throughout the project.
Remember, waterfall can have multiple phases. Phase 1 is the core of the application, what it needs to do, what it was designed for. Phase n is for all the stuff to improve, move with the times, automate, etc.
Re: (Score:2)
Agile has issues in terms of scale. It is great for small projects, works for Medium then as you get larger it begins to fall apart
This. What I find funny is that it's use is generally the reverse of where it would be most beneficial. A large established mature project would be great for Agile as it can handle the smaller delta's. These are usually in larger companies who won't touch Agile.
Consulting which is generally ground up work on the other hand with major changes loves Agile.
Re:Agile is the answer to everything (Score:5, Insightful)
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: (Score:2)
Exactly this.
I've found agile typically a poor solution for building non-trivial internal software for a company.
Issues I've found with in-house pure agile:
- regular access to the customer is problematic
- need to re-architect during sprints due to unforeseen requirements
- inability to produce reliable estimates or determine whether buy/build/make-do is the best option
- running over time/budget due to poorly analyzed requirements
The big "win" of agile is s
Re: (Score:2)
That is weird. I find it much harder to get access to actual users for externally facing software. At least for internal software the user works for the same company. The fact that the company doesn't actually want the users to contribute their knowledge of how they actually do business to the creation of the software that is supposed to help them do that business seems like a dysfunction that will doom a project regardless of the methodology. Interestingly, the project itself might not get the doom, bu
Some flavors of agile fight human nature ... (Score:2)
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 ar
Re: (Score:2)
One of the key tenants for Agile though is that developers pick the tasks they're going to work on in a sprint.
Re: (Score:2)
One of the key tenants for Agile though is that developers pick the tasks they're going to work on in a sprint.
But some flavors say that developers are supposed to work on all parts of the project. So yes they may be able to pick the individual task but they might not be able to pick a task from an area they prefer.
Re: (Score:2)
But some flavors say that developers are supposed to work on all parts of the project.
I think that is a misreading. Development teams should be assigned to end to end features. Development teams can be specialized in particular features and the components associated with those features. Development teams should be allowed to work on whatever component is required to implement their features, including some that may only be peripheral to their core components in order to complete a feature. Experts should be available to assist with modifying those peripheral components. That means teams
Re: (Score:2)
But some flavors say that developers are supposed to work on all parts of the project.
I think that is a misreading. Development teams should be assigned to end to end features. Development teams can be specialized in particular features and the components associated with those features. Development teams should be allowed to work on whatever component is required to implement their features, including some that may only be peripheral to their core components in order to complete a feature.
I think we are describing two very different sized projects. I'm not referring to very large projects that are implemented by multiple development teams. I am referring to more modest sized projects where there is a single development team; several different small projects that are developed/maintained by a single development team; etc.
I'd have to go find the book that a previous manager read and fell in love with, but it was pretty clear. Don't let someone always work in the same area or always avoid a
Re: (Score:2)
Re: (Score:2)
Scaled Agile Framework or Unified Process?! Some people might call it Scrum-fall.
Working in a big org on a big product I can see why somebody would suggest mixing both. The problem is - taking the "good" things from both rather than the bad things.
For example, If you want telemetry data sent back to a repository (to track feature usage) - you might want the architecture of that figured out "up front" rather than retrofit. I say "you might." In Agile it might be an important spike to get closed up front
Agile in Aerospace (Score:5, Interesting)
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.
Re: (Score:1)
This needs to be modded up.
Re: (Score:2)
If Agile isn't working for you, you *are* doing it wrong.
"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more."
Now, this kind of thinking is usually re
Marketing or Research? (Score:5, Insightful)
Sogeti has been presenting marketing as research for years with their World Quality Report: http://www.sogeti.com/solution... [sogeti.com]. This smells similar.
Re: (Score:1)
Thus far, I've been unable to find the actual report. I found and downloaded the "Summary of Key Findings", which says, "This report provides a brief summary of the important results from the full 2014 CRASH Report.". But, I can't actually find the "full 2014 CRASH Report".
This is making it difficult to evaluate. Perhaps on purpose...?
Re: (Score:2)
The CRASH 2014 "Summary of Key Findings" can be found at http://www.castsoftware.com/ [castsoftware.com] / ADVERTISING-CAMPAIGNS /
(emphasis mine)
Shocking News - One Size Doesn't Fit All (Score:4, Informative)
I'm as surprised as you are...
Re: (Score:1)
On that note: http://www.ipetitions.com/peti... [ipetitions.com]
Help stop "one size fits all" standards!
Re: (Score:2)
...also:
Can't speak for the development community at large but I have yet to work in either a purely Agile OR a purely Waterfall project yet. Every one has been a balance of both and it has worked quite well so this research seems stale to me.
Given I've "only" been in the development world for 15 years I missed Waterfall's heyday (Thank Jebus) but its not like the switch flipped all the way over. Agile and a variety of other procedural breakthroughs just add to the development toolbox from which to pick th
I tried this. Once. (Score:5, Insightful)
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.
Re:I tried this. Once. (Score:4, Insightful)
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.
Re: (Score:3)
>> 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
It never ends (Score:3, Insightful)
"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.
Re: (Score:2)
Comment removed (Score:5, Insightful)
Re: (Score:2)
Agile and scrum usually have less meetings than 'traditional' methods.
So calling them an excuse for 'more' is very dishonest.
If your organization claims to use agile methods but calls you into meets, then you are not agile!
Or as we say: you are doing it wrong!
Fire your agile consultants and get real ones! And most important build up agile know how in your own environment, get rid of consultants all together!
Re: (Score:3)
Very short feedback loop and adaptation cycle
A common characteristic of agile development are daily status meetings or "stand-ups", e.g. Daily Scrum (Meeting). In a brief session, team members report to each other what they did the previous day, what they intend to do today, and what their roadblocks are.[14]
From http://en.wikipedia.org/wiki/A... [wikipedia.org]
Can you tell us the one true agile that doesn't have lots and lots of meetings? In my experience, Waterfall frontloads a few megameetings, whereas Agile backloads them in nickels and dimes.
Re: (Score:2)
The parent talked about 'meetings' as in sitting around for hours, if not a whole day.
In agile processes you have a team meeting each day that lasts 30 seconds per developer.
So with ten developers it is 300 seconds which is 5 minutes.
So, what is your point?
Re: (Score:2)
duh (Score:3)
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.
Re: (Score:2)
Poll: Program while drunk? Can do, or no way?
From a QA tester perspective: Oh, hell no. Nothing worse than dealing with a new build on Monday morning after the programmers get drunk from the Friday beer bust and work all weekend long in a drunken stupor.
Selling methodologies (Score:3)
Quality and Productivity (Score:5, Insightful)
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: (Score:1)
Agile requires certain assumptions... (Score:3)
New Method on the horizon! (Score:3)
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.
Re: (Score:1)
And you've just pointed out why Agile is a steaming pile of crap.
Customers want to know when their software is going to be done and ready for them to use. Agile substitutes time estimates (which are hard and we all suck at) for "story points", which are supposed to be level-of-effort measurements that can be time-flexible at an individual level. So instead of a manager deciding how long each developer will take to do a given task based on their knowledge of that developer's skill level and other workload, t
That's how it always worked (Score:2, Insightful)
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".
Agile is a bit like a religion (Score:1)
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.
Re: (Score:1)
Incorrect. The different agile methodologies are sound in theory just as waterfall is sound in theory. They all work extremely well WHEN YOU FOLLOW THEM. The problem is no one correctly follows them (due to stupid people and the world being complex). Waterfall is the best practice if your requirements don't change and communication has been 100% on what's needed. It was designed for those requirements. Most agile practices are about smaller waterfall iterations leading to more feedback from the user.
Re: (Score:2)
sonarqube integration (Score:1)
SPAC (Score:1)
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.
How many suspension bridges... (Score:1)
and airliners were designed and built using Agile engineering methods.
That's right, exactly zero.
We should learn from municipalities, not toyota. (Score:2)
WTF? (Score:3)
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.
Re: (Score:2)
Both is wrong.
Waterfall is a 'planning method' has nothing to do how you 'manage' the project.
Agile is a 'development method' has again nothing to do with either 'planning' or 'managing'.
If you mix up that shit it is no wonder your organization has trouble to make software.
Hint: extreme programming is an agile 'development method' where everything around crafting software is emphasized and turned into the mid of the focus of developing. No 'planning' except for sprints and absolutely no 'managing' involved
WTF? (Score:2)
Aye: http://gilesbowkett.blogspot.c... [blogspot.com]
DevOps (Score:2)
Sigh... (Score:2)
It's Called the Avalanche Model (Score:2)
They already have a name [wikipedia.org] 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.
Mix Agile with Waterfall (Score:2)
We'll call it "Mudslide".
DUH (Score:2)
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.
Almost all management is risk management... (Score:2)
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 the
Experience (Score:2)
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 v