Why? What that is written in the Agile Manifesto precludes quality?
Which, in reality, leads to everyone working on random things, just adding features and somehow patching bugs.
But often refactoring the system, rewriting subsystems, etc is necessary.
> Working software over comprehensive documentation
If your software is working, but there is no documentation, this might work well for a website, but as soon as you go into control systems for the heating of the ISS, or go into railway control systems, or systems that measure the optimum way of packaging a package at an internet retailer, documentation is everything.
----------------
One of the largest european internet retailers fixed their code quality problems by forcing teams to release all code shared between two teams to be released under Apache License on GitHub. Suddenly developers started caring about code quality, reusability, and maintainability.
No, it doesn't. Bad management and process leads to that.
But often refactoring the system, rewriting subsystems, etc is necessary.
Totally acceptable and something that can easily be included in agile development.
If your software is working, but there is no documentation
This is not a prerequisite of agile development.
> This is not a prerequisite of agile development.
No, but agile says that software is still quality software, even when documentation doesn’t work. http://www.agilemanifesto.org/
It’s pretty clearly written down.
If a requirement for the system you are delivering is comprehensive, complete documentation, then you can deliver that. The point is that "comprehensive documentation" without "working software" is useless.
Additionally, software without documentation leads to issues like "does the train continue running when the signal is broken?", and similar ones.
It might be, but it almost certainly won't be. See the errata to any set of documentation. But this is a digression – if the acceptance of your product or feature requires documentation of interfaces in advance, then that's a requirement that can be met regardless of the development process that you use.
Additionally, software without documentation leads to issues like "does the train continue running when the signal is broken?", and similar ones.
No, that's what incorrectly designed, implemented or tested software leads to. But again – if documentation is required, using an agile process in no way restricts your ability to meet that requirement
Are you just telling me that waterfall is also agile?
No, I'm obviously not communicating effectively.
Documentation is a deliverable component of a software system. As a result, it can be tracked and managed just like any other deliverable component.
In any real software system, the initial documentation will not reflect the finished system. That's inevitable – it's why we have errata. The difference between 'agile' and 'waterfall' in this case will be whether those changes to documentation are delivered at the end of development, or as they are required by changes to other parts of the system.
Third party services depending on you having a stable API, for example.
You can’t just break support for them, so what do you do in agile?
There are still requirements, there is still design. If you have a customer depending on your API, that is a requirement. Agile doesn't mean requirements go away.
A product developed in an Agile process still has a 'maintenance phase'; the idea of software maintenance is not a Waterfall concept, it's a Software Development concept.
One thing I think you're having trouble with (maybe) is that this article was about Scrum, but you're attacking Agile. Scrum is an implementation of Agile, or maybe better characterized as a process facilitating Agile development, but it is not uniquely Agile. There are other Agile implementations/processes (Kanban, XP, etc.). Agile is more about attitude than implementation.
What Scrum is attempting to do is break down big ideas into small workable units, and help teams organize, assign, track and complete those work units efficiently. It separates the development cycle into several sprints: a team works a selected amount of items per sprint based on their capacity vs. the 'weight' of those items. If the development process using Scrum incorporates accepting changes to requirements or the design along the way, it's Agile. If it doesn't, Scrum can look a lot like a series of tiny waterfalls; you can absolutely have a Waterfall process where your teams organize and execute work like Scrum.
The most important thing to keep in mind is that neither Agile nor Scrum dictate what you consider to be a finished product, or a successful product. The standard of quality you added to one of your earlier comments is absolutely achievable using Scrum or another Agile process - in fact, it is the stated goal of Agile to turn out a high quality product which meets stated requirements.
Disadvantages: 0 backwards compatibility, annoying for users (I’d love to force the people who made these decisions to try and use a 5 year old Android phone with modern apps, thanks to the constantly breaking APIs that’s not possible), there is no backporting of fixes.
Advantages: Always the newest, shiniest.
When your requirements are stable, and you write
Most software - but not all - deals with uncertain requirements. These are suited to agile methods.
Other software is in a well understood industrialized domain. Here, I would not recommend waterfall per se, but an approach like Six Sigma and Formal engineering methods certainly makes sense.
Simon Wardley has explained this well here: http://blog.gardeviance.org/2015/06/why-agile-lean-and-six-s...
I think the disagreement is
A) is how industrialized IoT applications actually are.
It will be 2 decades or more I believe before they are. This will require to lots of disposability and change in the meantime. Hence appropriate for agile.
B) how much indistrialized software will there be in the future? Things like railway systems are well understood and industrialized. And don't need agile. But my point has been there isn't a lot of railway software out there to write anymore.
But at some point, will the newer IoT domains be eventually so industrialized that it requires formal engineering methods? To this I say - sure - but not for a long while. The applications are still too fluid.
C) how many people actually work on various ends of the spectrum of agile vs industrialized ? There has been an explosion of activity in using software in new domains, which is agile by definition. Industrial software even by your own definition only needs to be written once every 80 years. So it makes one surmise it will always be a minority of software development.
A situation like the Android update situation, though, is completely unacceptable for smoke detectors or other household devices.
No matter how good predictability is, the demand is that these devices are "buy once, just works™". So we need to write stable software for an unstable use case.
But in no case should we end up with serious devices having a support situation like Android, or the SAMSUNG smart devices.
Yes, it will only be written every few decades, but that is fine. It doesn't need to be a huge industry. Just like Washing Machines are mostly made by smaller enterprises.
I think your class or professors are assigning behaviors and outcomes to development processes that should instead be assigned to the companies or people implementing them.
> This is not a prerequisite of agile development.
What I often see in "waterfail" projects is documentation that's inaccurate and reflects what once was the plan someone wanted to build.
It's one excellent way to ensure that updates that necessitate a change in documentation actually get documented.
> in reality, leads to everyone working on random things,
No. It's just that we acknowledge plans need to change and draw new plans. If we feel something need refactoring, we refactor. If it needs a complete rewrite, we do it. We can do it because we have tests for everything. The tests define what the parts do. They are part of the documentation, one you can run and be 100% sure it is correct. When we acknowledge something needs to be redone, we plan for it.
> If your software is working, but there is no documentation,
See above.
> to quote a professor
Judge the argument, not the person making it.
> Apache License on GitHub. Suddenly developers started caring about code quality
A GPLv3 variation could have been a smarter move, but yes. Having people able to look over your shoulder is a fairly decent quality driver. All my recent work is open source and, when I cut a corner, I always document the corner, why I cut it and when and how I will fix it.
And in projects like "ISS heating control", or "railway control system", or "electronical ID card for 82 million people", you want a software that is backwards compatible so third parties interacting with you will never have to rewrite your software, you want a software that runs with minimal maintenance, but is easy to extends, etc.
And Agile is ill suited for that. Agile is well suited for cases where no one ever depends on a your software providing a specific interface and where your target moves quickly and where you can ensure everyone always runs the latest version. In other words, small applications and web apps.
I really think you need to build a lot more software before you can make a claim like that. You're being fed lines from your professors.
The vast majority of software, period, is not backward compatible, has to be rewritten all the time, and costs billions to maintain, and is hard to maintain.
Agile vs. Waterfall is only one factor among many in such as discussion. The difference with Agile is in its ability to deal with uncertain requirements, something Waterfall cannot handle by its nature.
And this piece of software exists. Governmental projects interacting with lots of insurance companies, for example. Like the Elektronische Gesundheitskarte – a concept of giving every German an insurance card issued by the government, with all medical data stored in a cloud with insurances, doctors and pharmacies having access to it.
Before the software was even finished, PoS software was able to interact with the API and insurances had sent out millions of cards.
Breaking anything at that point costs millions.
EDIT: regarding your edit: Agile is far more suited for constantly changing environments, where you also can just break support for any third parties depending on your API. But obviously, that’s not really quality software when every software depending on yours has to be changed every few years.
Yes. There are hard constraints in many projects. If you know exactly up front what you need, you do not need Agile approaches to handle the uncertainty.
However, there is plenty of uncertainty to be managed behind this API.
"Agile is far more suited for constantly changing environments, where you also can just break support for any third parties depending on your API. But obviously, that’s not really quality software when every software depending on yours has to be changed every few years."
One doesn't have to change an API to evolve the software. Old school HTML and HTTP from 1992 still works on an evolving web.
"But obviously, that’s not really quality software when every software depending on yours has to be changed every few years."
APIs can be made to be backward compatible or versioned as they evolve.
Again, you presume the people asking for the software know exactly what they want. IF they do, then you are fine. It is very rare in practice except for simple or well-understood predictable domains. If the stakeholders do not know or agree on what they want (most of the time), something like Agile is appropriate to manage change.
Most APIs evolve a lot as parties learn more about the problem space, but this does not necessarily mean older versions automatically break. This really has little to do with Agile vs. Waterfall, it has more to do with the design decisions made for evolvability.
Actually, not. Try
<blink><marquee>TEXT</marquee></blink>
And many other features, especially in CSS, constantly change and evolve, often older variants being dropped. Especially Chrome is dropping support for older code all the time. (Also, soon CSS newspaper-like column flow will be dead T_T )
Even if the people you work for don’t know what they want, the part of "determining what they want" should be part of the "find the requirements" at the begin. You might even want to work with mockups or proof-of-concepts at this time.
They probably need it too.
What you describe is a problem stated in great detail and an API that's needs to be kept backwards compatible. There is nothing in agile that precludes that. Quite the contrary: if you build your tests well enough, everyone who did not participate in the original design can use them as examples of how your system actually works. More than that: you can always prove your system still works as specified, all the time, every time. Agile is good, very good, for dealing with a changing world. And, while the APIs in the system you describe can't change without major investment, if the rest is also difficult to change, whoever did it did it seriously wrong.
You can tell that to your teachers.
And if you buy a washing machine with lifetime guarantee, you expect it to run forever, but the requirements are mostly static, too.
For a smart TV, on the other hand, you separate the pieces of software with static requirements, and those without. The internal signal decoder, etc will be static. UI might end up rendered by a local web browser, and especially media content will be online.
So if, in 10 years, Netflix defaults, the online content can immediately remove Netflix and replace it with its successor. This UI might make sense with Agile.
But the code the user expects to be reliable and fast – like the code for decoding and displaying a TV signal – will not change, and should be written with waterfall.
----------------
People want to be able to buy a fridge or washing machine and use it for decades. Do you buy a new fridge every year?
We are going to be living in a world with internet of things. And with the internet of things we will have shoes and houses running software. More and more software will have to be built with the expectation never to get updated.
The software can be updated over the air in a Tesla every few weeks.
Mercedes is working with my company to adopt agile practices and server deployment to disposable cloud environments for their connected car IoT applications.
Industrial and Appliance manufacturers such as Philips, and GE (a 10% investor) are also adopting this same software and methodology for their IoT platforms and applications.
I don't know what else to tell you - there are certainly areas where you correctly point out you need to get it right the first time. But you keep making projections about the future of immutable software that are contradictory to all the evidence.
The world is a big place and even in Deutschland the big industrial manufacturers are adopting lean and agile. Cars at Toyota and Honda (and many others) are developed with Lean Product development principles - not a big up front design plan, but test-first, concurrent, iterative, incremental engineering.
One can buy hardware that lasts a decade - the software can and will evolve except in constrained environments. A washing machine is not a constrained environment.
Out of the people I know, most never updated their phone software or the firmware of their consoles. My mum was, until a week ago, running on her PC Windows Vista with the last update being downloaded in 2006, when we moved into this house and I had run Windows Update for her.
A washing machine is probably the most constrained environment in any home. No one’s going to update it. When you turn it on, you want it to just work. Same with the smart fridge.
These devices have a lifetime of decades, and no one’s going to update them.
Same with cars, most people don’t want them to be updated.
Remember, this is Deutschland, we still use Fax for business communication.
over != instead of: "That is, while there is value in the items on the right, we value the items on the left more."
And no, you probably wouldn't use agile to manage the project of heating the ISS. That is a very static problem space with unique requirements. Using the same framework to plan and build anything related to heating the ISS to build an HR system would be overkill. Right tool for the job, etc.
I've worked on both good and bad agile projects - all have involved managing change. The good ones didn't involve throwing a plan out & doing what you want. They merely accepted that when you start building a solution, you lift rocks and uncover requirements that you never envisaged having. In an agile environment, you can deal with that - bring those things onboard, reprioritise and rescope, giving an accurate idea of when a product is going to be delivered. In a traditional waterfall environment, these same requirements get left until the now-woefully inadequate product is built, and useless to anyone.
You don’t decide to build a bridge out of a specific steel without testing in models which kind of steel is ideal for your case, or if you might have to change the shape of the bridge.
But in the moment that others will build projects depending on your implementation being stable – in the bridge example, this would be others building the pillars for the bridge or the bridge deck – you have to keep the implementation stable. (In software, this is usually third parties basing software on your interface)
And then there's the solution itself not being suitable. Have you ever shown a solution built completely to spec in a waterfall-esque environment, only for them to say "oh, but it doesn't solve x"? or for them to start using it and suddenly realise there's some fundamental flaw in it? This is where agile comes in - you can regularly demo the software and make adjustments and reprioritisations as it comes together. It enables that conversation to be had and the change to be made when it's cheapest - early on, rather than when a huge app has been built on top of it.
Also - agile doesn't preclude stability. You can manage this with test suites (the top layer of the current project I'm working on's test suite is built against our documentation), we know if and when we've broken something because we're constantly emulating the third parties in your example using our software and asserting that it remains correct.
But that’s the issue: What if you are writing the third party API, what if you are writing the firmware of a Washing Machine which is sold with lifetime guarantee*? (up to 99 years or death of buyer, whichever happens first), what if you write feature where every change has to be reviewed and costs millions?
People expect from quality software what they expect from a quality washing machine, meaning that they buy it once, never have to touch it again, and it will always work and never change. Except for some minor features added at some point.
But removing or changing features? Never.
This is true for users (remember how many people complained about Windows 8 unusual interface?) and for other developers (How many people go all crazy every time Google kills yet another service, or removes another API, or changes their API syntax?).
Sometimes it works, sometimes it doesn’t. But, effectively, I’m asking for perfect backwards compatibility. And that is rarely possible in systems where the software defines the documentation, instead of the other way round.