4 ms·

In my experience, the term “Agile” itself has been so widely applied that it lost any useful meaning it might have had a long time ago. The ideas it prompted ar

In my experience, the term “Agile” itself has been so widely applied that it lost any useful meaning it might have had a long time ago. The ideas it prompted are the interesting part. I’ve never fully agreed with the original Agile Manifesto anyway, mostly because I think it tries to separate concepts that aren’t independent in practice. For example, if you don’t have a comprehensive requirements spec, how can you possibly know whether you have working software? I do think the early Agile advocacy served a useful purpose in highlighting how slow and heavy a lot of software development processes were at the time. I think a lot of good ideas have been popularised as a result of that awareness and the various alternative processes that have been tried as a result. I also think some not so good ideas have been popularised, and some ideas that work well in the right context but not universally. IMHO, it is much more interesting to discuss those specific ideas. How can we build software more incrementally, so we can see real progress and identify any potential problems earlier when they might be easier to fix? Is there a risk of becoming too short-sighted, so we create an illusion of progress, yet overall it takes longer to build a product we can ship? How can we organise our code and our teams to be more adaptable as requirements evolve over time? How does our situation change depending on whether we’re building a line-of-business web application, a game for a next generation console, or the management system for an aircraft carrier? There are lots of interesting ideas and useful discussions to be had, but they can be had just as well without applying the loaded term “Agile” anywhere.

marcus_holmes 5y ago
> For example, if you don’t have a comprehensive requirements spec, how can you possibly know whether you have working software? Short answer: iterative prototypes. Long answer: I have yet to see a single project in all my decades of experience in this industry where the requirements didn't change during the project. A "comprehensive requirements spec" is and always was a myth. Agile wasn't even the first to say this bit out loud. Software is always developed by a series of iterative prototypes, only sometimes does the process acknowledge this.
- Chris_Newton 5y ago
  Short answer: iterative prototypes. OK, but then how do you know what each prototype is required to do? It’s true that you might be lucky enough to work on a project where your employer/client/customer is willing to let you make some of the decisions. In that case, you are effectively defining some of the requirements yourself and hoping that your employer/client/customer will be happy with your decisions. That’s a risk you can mutually agree to take, and sometimes it will pay off royally, and sometimes it will end in disaster, and probably most of the time it will end somewhere in between. However, in my experience, the more important the software you’re building is, the less likely it is that you will have that kind of flexibility for the developers. At the extreme end of the industry, if you’re building something like the control system for medical equipment that will kill the patient if it goes wrong or a billion dollar satellite that you get one shot at launching, you probably aren’t going to be doing it through informal discussions with a “product owner” and relying on TDD to make sure everything is working (where “working” in that case is really a euphemism for “whatever test conditions an individual developer felt might matter”). I have yet to see a single project in all my decades of experience in this industry where the requirements didn't change during the project. Of course, but every time the requirements change, you still need to identify what the change is so you can change your implementation accordingly. There are many ways you can address that problem, some of which involve one big requirements spec document and some of which don’t, but if you don’t end up with some clear and well-maintained spec each time, you don’t know what you’re trying to build and you have no meaningful definition of “working software”.
  - marcus_holmes 5y ago
    > OK, but then how do you know what each prototype is required to do? You define an area of exploration for each prototype. Like "we think that the hard part of this problem is getting the encryption right, so we're going to explore that in this prototype". And I thought SpaceX disproved this whole waterfall approach to rocket science? They have used iterative prototypes to build better rockets considerably faster than the waterfall approach used by the rest of the industry.
    - 5y ago
stefanve 5y ago
"Working software over comprehensive documentation" "That is, while there is value in the items on the right, we value the items on the left more" I have had many discussions with both agilest and let's say traditionalist about these statements. funnily enough people from both "sides" sometimes mis interpet (or at least that is my view) the statement as; agile means no documentation. To me it is about just enough documentation. You should know what needs to be build, what you expect from it etc. But in the end it is better to have working software than to have piles of documentation. So there is value is having documentation but the end goal is working software. If you are old enough you remember months and sometimes years spend at documentation, scribbling over details, etc. At the end of the documentation phase they started building, than a building phase that could take months or years. After the building phase they found out the things that seemed handy at the time where not working in real life or where obsoleet. So a analyst should create a RFC which again would take lots of time before it would finally be made The idea of having working software over comprehensive documentation is that it is better to start building the most important feature(s) and release it as soon as possible. This makes sure you add value as soon as possible. Documentation by it self doesn't add value, but working software does. This doesn't mean that the important feature should not be documented, but it should be documented enough to add value as quickly as possible. That way you get feedback from the users and change what is needed instead of talking for days about what something should do and what problems might arise from some theoretically edge case. Also it makes prioritisation much easier. Maybe an edge case can be tackled by a change of process in state of a difficult software solution. thus having time to work on a feature that adds more value
- Chris_Newton 5y ago
  I would be the first to agree that a lot of documentation of little or no value has traditionally been created during software development. I saw an interesting report once about some research on where software developers actually look for information while doing their work. Sure enough, it turns out that some types of documentation are very useful and some are mostly useless, and which is which is very much as you probably expect if you’ve been developing for a while. Still, when it comes to things like defining the requirements and acceptance criteria for software, “just enough documentation” and “comprehensive documentation” are often the same. Otherwise, you literally don’t know what you’re trying to build. That is not to say that you have to have one big requirements spec that never changes (or one big set of requirements specs including numerous cross-references, if it’s that kind of project) or that every change must go through an extensive change management process involving 27 people and a month-long delay to fix a spelling mistake in the original spec. But you need something that clearly defines what the software is supposed to be. As I noted in another comment, if you are making software without that, you don’t really have a useful definition of “working software” to prefer. Obviously you can still go ahead and make something. It’s just that both sides are then taking on the risk that the development team’s assumed requirements when they fill in the gaps will be satisfactory to whoever is paying the bill. That could end anywhere from spectacularly successful to a dismal failure, which doesn’t seem like an ideal basis for a software development process to me. Perhaps a more common scenario, particularly for software developed in-house or outsourced on a T&M charging basis, is that when differences arise you go back and correct them afterwards, so you still get what the end customer needs but it takes longer and costs more than was really necessary to get there. This is a more insidious danger, because if things do work out in the end, you might not have any quantifiable way to assess what you lost or maybe any awareness that you lost out at all. But you still lost out all the same. The idea of having working software over comprehensive documentation is that it is better to start building the most important feature(s) and release it as soon as possible. This makes sure you add value as soon as possible. Sometimes. It depends entirely on your situation. Shipping a line-of-business application with 75% of the desired functionality that you can then incrementally develop further in production might offer a lot more than 75% of the value. Shipping 50% of the software that controls the mechanics of a modern car might offer 0% of the value, and if shipping that 50% early means the 100% point when the car is actually useable is delayed then doing so actually has negative value, and the only early feedback you’re going to get is that no-one has bought the car yet.
PaulKeeble 5y ago
"Individuals and interactions over processes and tools" The issue I have always had here is that in order to go fast and have short cycle times you need quite a bit of automation and the more you rely on automation and make it work the easier it is to maintain iterative agile development. That requires processes and tools maintained and the more you rely on individual personal preferences and nuances the longer those cycle times will be. Once you get down to continuous delivery you don't have much choice but to have automated tests written for everything, the basis of which might have been a fantastic interaction with a stackholder with a good back and forth on the right tests, but its far too reductive to just always value people over process when solid engineering is critical to low cycle time for software agility. It seems the manifesto was written from a contract interaction perspective for consultants. With the product mindset however these types of scenarios are a lot less common but the engineering doesn't go away. Its just one aspect that has annoyed me where Xtreme programming got more into defining what a good project actually ought to be able to do and the sort of processes that were necessary to make it work even if some of it was flawed it hung together better than a set of values.
scott_middleton 5y ago
> IMHO, it is much more interesting to discuss those specific ideas. Yes, agree here. > I do think the early Agile advocacy served a useful purpose.. Agree.

marcus_holmes 5y ago

> For example, if you don’t have a comprehensive requirements spec, how can you possibly know whether you have working software? Short answer: iterative prototypes. Long answer: I have yet to see a single project in all my decades of experience in this industry where the requirements didn't change during the project. A "comprehensive requirements spec" is and always was a myth. Agile wasn't even the first to say this bit out loud. Software is always developed by a series of iterative prototypes, only sometimes does the process acknowledge this.

Chris_Newton 5y ago
Short answer: iterative prototypes. OK, but then how do you know what each prototype is required to do? It’s true that you might be lucky enough to work on a project where your employer/client/customer is willing to let you make some of the decisions. In that case, you are effectively defining some of the requirements yourself and hoping that your employer/client/customer will be happy with your decisions. That’s a risk you can mutually agree to take, and sometimes it will pay off royally, and sometimes it will end in disaster, and probably most of the time it will end somewhere in between. However, in my experience, the more important the software you’re building is, the less likely it is that you will have that kind of flexibility for the developers. At the extreme end of the industry, if you’re building something like the control system for medical equipment that will kill the patient if it goes wrong or a billion dollar satellite that you get one shot at launching, you probably aren’t going to be doing it through informal discussions with a “product owner” and relying on TDD to make sure everything is working (where “working” in that case is really a euphemism for “whatever test conditions an individual developer felt might matter”). I have yet to see a single project in all my decades of experience in this industry where the requirements didn't change during the project. Of course, but every time the requirements change, you still need to identify what the change is so you can change your implementation accordingly. There are many ways you can address that problem, some of which involve one big requirements spec document and some of which don’t, but if you don’t end up with some clear and well-maintained spec each time, you don’t know what you’re trying to build and you have no meaningful definition of “working software”.
- marcus_holmes 5y ago
  > OK, but then how do you know what each prototype is required to do? You define an area of exploration for each prototype. Like "we think that the hard part of this problem is getting the encryption right, so we're going to explore that in this prototype". And I thought SpaceX disproved this whole waterfall approach to rocket science? They have used iterative prototypes to build better rockets considerably faster than the waterfall approach used by the rest of the industry.
  - 5y ago

stefanve 5y ago

"Working software over comprehensive documentation" "That is, while there is value in the items on the right, we value the items on the left more" I have had many discussions with both agilest and let's say traditionalist about these statements. funnily enough people from both "sides" sometimes mis interpet (or at least that is my view) the statement as; agile means no documentation. To me it is about just enough documentation. You should know what needs to be build, what you expect from it etc. But in the end it is better to have working software than to have piles of documentation. So there is value is having documentation but the end goal is working software. If you are old enough you remember months and sometimes years spend at documentation, scribbling over details, etc. At the end of the documentation phase they started building, than a building phase that could take months or years. After the building phase they found out the things that seemed handy at the time where not working in real life or where obsoleet. So a analyst should create a RFC which again would take lots of time before it would finally be made The idea of having working software over comprehensive documentation is that it is better to start building the most important feature(s) and release it as soon as possible. This makes sure you add value as soon as possible. Documentation by it self doesn't add value, but working software does. This doesn't mean that the important feature should not be documented, but it should be documented enough to add value as quickly as possible. That way you get feedback from the users and change what is needed instead of talking for days about what something should do and what problems might arise from some theoretically edge case. Also it makes prioritisation much easier. Maybe an edge case can be tackled by a change of process in state of a difficult software solution. thus having time to work on a feature that adds more value

Chris_Newton 5y ago
I would be the first to agree that a lot of documentation of little or no value has traditionally been created during software development. I saw an interesting report once about some research on where software developers actually look for information while doing their work. Sure enough, it turns out that some types of documentation are very useful and some are mostly useless, and which is which is very much as you probably expect if you’ve been developing for a while. Still, when it comes to things like defining the requirements and acceptance criteria for software, “just enough documentation” and “comprehensive documentation” are often the same. Otherwise, you literally don’t know what you’re trying to build. That is not to say that you have to have one big requirements spec that never changes (or one big set of requirements specs including numerous cross-references, if it’s that kind of project) or that every change must go through an extensive change management process involving 27 people and a month-long delay to fix a spelling mistake in the original spec. But you need something that clearly defines what the software is supposed to be. As I noted in another comment, if you are making software without that, you don’t really have a useful definition of “working software” to prefer. Obviously you can still go ahead and make something. It’s just that both sides are then taking on the risk that the development team’s assumed requirements when they fill in the gaps will be satisfactory to whoever is paying the bill. That could end anywhere from spectacularly successful to a dismal failure, which doesn’t seem like an ideal basis for a software development process to me. Perhaps a more common scenario, particularly for software developed in-house or outsourced on a T&M charging basis, is that when differences arise you go back and correct them afterwards, so you still get what the end customer needs but it takes longer and costs more than was really necessary to get there. This is a more insidious danger, because if things do work out in the end, you might not have any quantifiable way to assess what you lost or maybe any awareness that you lost out at all. But you still lost out all the same. The idea of having working software over comprehensive documentation is that it is better to start building the most important feature(s) and release it as soon as possible. This makes sure you add value as soon as possible. Sometimes. It depends entirely on your situation. Shipping a line-of-business application with 75% of the desired functionality that you can then incrementally develop further in production might offer a lot more than 75% of the value. Shipping 50% of the software that controls the mechanics of a modern car might offer 0% of the value, and if shipping that 50% early means the 100% point when the car is actually useable is delayed then doing so actually has negative value, and the only early feedback you’re going to get is that no-one has bought the car yet.

PaulKeeble 5y ago

"Individuals and interactions over processes and tools" The issue I have always had here is that in order to go fast and have short cycle times you need quite a bit of automation and the more you rely on automation and make it work the easier it is to maintain iterative agile development. That requires processes and tools maintained and the more you rely on individual personal preferences and nuances the longer those cycle times will be. Once you get down to continuous delivery you don't have much choice but to have automated tests written for everything, the basis of which might have been a fantastic interaction with a stackholder with a good back and forth on the right tests, but its far too reductive to just always value people over process when solid engineering is critical to low cycle time for software agility. It seems the manifesto was written from a contract interaction perspective for consultants. With the product mindset however these types of scenarios are a lot less common but the engineering doesn't go away. Its just one aspect that has annoyed me where Xtreme programming got more into defining what a good project actually ought to be able to do and the sort of processes that were necessary to make it work even if some of it was flawed it hung together better than a set of values.

scott_middleton 5y ago

> IMHO, it is much more interesting to discuss those specific ideas. Yes, agree here. > I do think the early Agile advocacy served a useful purpose.. Agree.