5 ms·

There is nothing in agile stopping you from producing comprehensive designs or specs. Every project I take on these days has a pre-production phase. This phase

There is nothing in agile stopping you from producing comprehensive designs or specs. Every project I take on these days has a pre-production phase. This phase is 1-3 sprints. It involves speccing sophisticated systems, designing UX and several spikes to evaluate technology. These all have outputs in the form of documents. Even the spikes should produce a short document outlining the technology recomendations and the reasons for the recommendation. Similarly, in a project with a more research orientation, we perform spikes which involve building various prototypes and documenting their feasibility. None of this conflicts with agile principals nor creates a situation in which engineers and designers are pressured to forsake, "building it right". In fact the only differences between this approach and "waterfall" is that there is frequent accountability and there is protection for the development team because they are still choosing what comes into a sprint. I generally find that whatever form the various criticisms of agile take over the years, there are generally two impulses really at work underneath them. Either management is trying to undermine the protections agile and scrum create for the dev team by violating the "only pigs talk" principal or it's developers trying to avoid regular accountability so they can build their castles in the air. To be 100% clear, I'm not even saying that approach never works. There are phenomenal developers who disappear for weeks and come back with magic. But often enough, developers who cannot deliver try to perform the same act and their incompetence sinks a project. The development team cannot collectively afford the risk to find out which kind of developer you might be and therefore you owe them accountability. We all owe each other accountability.

deleted 4y ago
[deleted]
lumb63 4y ago
Your last paragraph makes me wonder: are there two sets of people, one of people who perform better under Agile, and one of people who don’t? We acknowledge the above is true for, e.g., work from home, but have many ever taken the time to consider the same might be true for development process? I’ve worked with (and supervised) developers who I’m fine with sending off into their corner to do what they think is best for weeks at a time. I’m confident they’ll come back with something great, more often than not. I’ve also seen developers who I’m not comfortable with sending off on their own for even a day in between daily standups. I wonder if there’s a process that allows to reap the spoils of both types of developers. Naturally, I’d rather have a team of the first type and think hiring those is the best way, but inevitably, some of the second type make their way in.
- AnimalMuppet 4y ago
  I wonder if the difference is not developers, but managers who can/can't do agile.
- hackerfromthefu 4y ago
  And there are also adaptable people that make it work under most or any system, and another type of people who find the failure cases for almost any type of system.
- desmosxxx 4y ago
  What this normally looks like is a project leader that syncs with each developer as needed and aggregates that into the project management overview with no/minimal large stand-ups or syncs. If two developers should adjust or be in contact than the leader facilitates that. etc. The agile framework can still be followed by the project leaders, but the developers (who don't like micromanaging) can be shielded from any rigidness.
convolvatron 4y ago
waterfall is a strawman. any pre-agile organization that signed off on a two-year plan and showed up two years later saying 'where's my thing?' is just as much of an idiot as they would be today. yes, making plans that you indend to continuously adapt to the situation at hand doesn't conflict with agile. but that still leaves one wondering what agile really brought to the table. time boxing everything at a fixed 2 week interval?
- d_sem 4y ago
  The us vs them mentality between Agile and Waterfall that coaches often preach is itself a violation of the agile principle of people over process. You should identify what process best fits your product/customer/team, then use that process. Some products require lots of upfront requirement elicitation before you can even identify the appropriate solution-- and that's ok. Imagine prioritizing a working software in a sprint over figuring out what your customer needs. I recently observed from the outside a project that took upwards of two years of requirement elicitation, IP contracting, complex distribution of ownership between multiple competing companies, multiple OS's, complex hardware platform design revisions to support the intended software functionality. Not a single line of code was written for two years. Was this state of the art engineering? YES. Did they operate under the principles of the agile manifesto? YES.
- lmm 4y ago
  > waterfall is a strawman. any pre-agile organization that signed off on a two-year plan and showed up two years later saying 'where's my thing?' is just as much of an idiot as they would be today. It's not a strawman. Those organisations are very real. > yes, making plans that you indend to continuously adapt to the situation at hand doesn't conflict with agile. but that still leaves one wondering what agile really brought to the table. time boxing everything at a fixed 2 week interval? Agile emphasises that you need to deliver something working to the customer, every 2 weeks. Without that it's very easy to call something code-complete or tested but not released or whatever, and you get further and further behind where you think you are because none of the stuff you thought you'd finished actually works.
- DubiousPusher 4y ago
GuB-42 4y ago
> There is nothing in agile stopping you from producing comprehensive designs or specs. Agile manifesto, 2nd point "Working software over comprehensive documentation". It certainly doesn't stop you but if you focus on writing comprehensive documentation before working software, it is not Agile, it is something else. As for Agile offering "protection", maybe I misunderstand your point but for me, Agile is the opposite of protection. I think that if there is one thing that defines Agile, it is that the customer is very close the the team, so it can be, well, agile. The customer has to be there to see how things are going and adjust course as necessary, unlike the waterfall style where a formal contract protects both the team and customer. Note that I don't consider "waterfall" bad, and "Agile" good. It is just different approaches for different situations. If the customer wants an "hands off" approach, or if you write certified software, then I believe that "waterfall" style approaches are superior most of the times.
- sodapopcan 4y ago
  OP's opening statement was a little off. What OP went on to describe was not "comprehensive documentation" in the Agile sense but merely "documenting progress and learnings as to not repeat mistakes". The "comprehensive documentation" in Agile is trying to avoid the "We have delivered exactly what you asked for even it if is no longer what you need."
- michaelcampbell 4y ago
  > Agile manifesto, 2nd point "Working software over comprehensive documentation". Isn't the 0'th point that agile still values the stuff on the right, it just values the stuff on the left more?
- randomdata 4y ago
  > Agile manifesto, 2nd point "Working software over comprehensive documentation". Which is funny given that the father of TDD, Kent Beck, is one of the Agile Manifesto signatories. What does TDD give you before working software? Comprehensive documentation.
  - GuB-42 4y ago
ydlr 4y ago
What is a "spike?"
- sodapopcan 4y ago
  A spike is when you do exploratory work on a concept/ticket/whatever to get a sense for its feasibility, utility, and how long it will take. It often goes hand-in-hand with TDD but it doesn't have to. Basically you try and get as much of the feature implemented as quickly as possible. Forget tests, forget well-named identifiers (just call 'em foo1, foo2, foo3 if you're stuck), forget breaking other part of the app, just get enough of the feature working as quickly as possible that you can identify pain points. If you get enough of it working it can even be used as a prototype for the customer to play with to see if they actually want it. Of course, when _and if_ you decide to actually implement the feature, you gotta throw away all your spike work or you're going to have a bad time. It is of course perfectly acceptable to keep it around on another branch for reference.
  - DubiousPusher 4y ago
    I see spikes as user stories that instead of a deliverable as their output, their output is the answer to a question.
    - sodapopcan 4y ago
      Absolutely, that's a good way to put it. All feature spikes should have tickets defining what it's trying to validate. From a TDD standpoint, I also use the word "spike" to describe any quick experimental throw-away work done on a small slice of functionality before writing the first test. These should not have tickets as that would be a bit over-the-top (and you don't always know if you're going to do them).

deleted 4y ago

[deleted]

lumb63 4y ago

Your last paragraph makes me wonder: are there two sets of people, one of people who perform better under Agile, and one of people who don’t? We acknowledge the above is true for, e.g., work from home, but have many ever taken the time to consider the same might be true for development process? I’ve worked with (and supervised) developers who I’m fine with sending off into their corner to do what they think is best for weeks at a time. I’m confident they’ll come back with something great, more often than not. I’ve also seen developers who I’m not comfortable with sending off on their own for even a day in between daily standups. I wonder if there’s a process that allows to reap the spoils of both types of developers. Naturally, I’d rather have a team of the first type and think hiring those is the best way, but inevitably, some of the second type make their way in.

AnimalMuppet 4y ago
I wonder if the difference is not developers, but managers who can/can't do agile.
hackerfromthefu 4y ago
And there are also adaptable people that make it work under most or any system, and another type of people who find the failure cases for almost any type of system.
desmosxxx 4y ago
What this normally looks like is a project leader that syncs with each developer as needed and aggregates that into the project management overview with no/minimal large stand-ups or syncs. If two developers should adjust or be in contact than the leader facilitates that. etc. The agile framework can still be followed by the project leaders, but the developers (who don't like micromanaging) can be shielded from any rigidness.

convolvatron 4y ago

waterfall is a strawman. any pre-agile organization that signed off on a two-year plan and showed up two years later saying 'where's my thing?' is just as much of an idiot as they would be today. yes, making plans that you indend to continuously adapt to the situation at hand doesn't conflict with agile. but that still leaves one wondering what agile really brought to the table. time boxing everything at a fixed 2 week interval?

d_sem 4y ago
The us vs them mentality between Agile and Waterfall that coaches often preach is itself a violation of the agile principle of people over process. You should identify what process best fits your product/customer/team, then use that process. Some products require lots of upfront requirement elicitation before you can even identify the appropriate solution-- and that's ok. Imagine prioritizing a working software in a sprint over figuring out what your customer needs. I recently observed from the outside a project that took upwards of two years of requirement elicitation, IP contracting, complex distribution of ownership between multiple competing companies, multiple OS's, complex hardware platform design revisions to support the intended software functionality. Not a single line of code was written for two years. Was this state of the art engineering? YES. Did they operate under the principles of the agile manifesto? YES.
lmm 4y ago
> waterfall is a strawman. any pre-agile organization that signed off on a two-year plan and showed up two years later saying 'where's my thing?' is just as much of an idiot as they would be today. It's not a strawman. Those organisations are very real. > yes, making plans that you indend to continuously adapt to the situation at hand doesn't conflict with agile. but that still leaves one wondering what agile really brought to the table. time boxing everything at a fixed 2 week interval? Agile emphasises that you need to deliver something working to the customer, every 2 weeks. Without that it's very easy to call something code-complete or tested but not released or whatever, and you get further and further behind where you think you are because none of the stuff you thought you'd finished actually works.
DubiousPusher 4y ago

GuB-42 4y ago

> There is nothing in agile stopping you from producing comprehensive designs or specs. Agile manifesto, 2nd point "Working software over comprehensive documentation". It certainly doesn't stop you but if you focus on writing comprehensive documentation before working software, it is not Agile, it is something else. As for Agile offering "protection", maybe I misunderstand your point but for me, Agile is the opposite of protection. I think that if there is one thing that defines Agile, it is that the customer is very close the the team, so it can be, well, agile. The customer has to be there to see how things are going and adjust course as necessary, unlike the waterfall style where a formal contract protects both the team and customer. Note that I don't consider "waterfall" bad, and "Agile" good. It is just different approaches for different situations. If the customer wants an "hands off" approach, or if you write certified software, then I believe that "waterfall" style approaches are superior most of the times.

sodapopcan 4y ago
OP's opening statement was a little off. What OP went on to describe was not "comprehensive documentation" in the Agile sense but merely "documenting progress and learnings as to not repeat mistakes". The "comprehensive documentation" in Agile is trying to avoid the "We have delivered exactly what you asked for even it if is no longer what you need."
michaelcampbell 4y ago
> Agile manifesto, 2nd point "Working software over comprehensive documentation". Isn't the 0'th point that agile still values the stuff on the right, it just values the stuff on the left more?
randomdata 4y ago
> Agile manifesto, 2nd point "Working software over comprehensive documentation". Which is funny given that the father of TDD, Kent Beck, is one of the Agile Manifesto signatories. What does TDD give you before working software? Comprehensive documentation.
- GuB-42 4y ago

ydlr 4y ago

What is a "spike?"

sodapopcan 4y ago
A spike is when you do exploratory work on a concept/ticket/whatever to get a sense for its feasibility, utility, and how long it will take. It often goes hand-in-hand with TDD but it doesn't have to. Basically you try and get as much of the feature implemented as quickly as possible. Forget tests, forget well-named identifiers (just call 'em foo1, foo2, foo3 if you're stuck), forget breaking other part of the app, just get enough of the feature working as quickly as possible that you can identify pain points. If you get enough of it working it can even be used as a prototype for the customer to play with to see if they actually want it. Of course, when _and if_ you decide to actually implement the feature, you gotta throw away all your spike work or you're going to have a bad time. It is of course perfectly acceptable to keep it around on another branch for reference.
- DubiousPusher 4y ago
  I see spikes as user stories that instead of a deliverable as their output, their output is the answer to a question.
  - sodapopcan 4y ago
    Absolutely, that's a good way to put it. All feature spikes should have tickets defining what it's trying to validate. From a TDD standpoint, I also use the word "spike" to describe any quick experimental throw-away work done on a small slice of functionality before writing the first test. These should not have tickets as that would be a bit over-the-top (and you don't always know if you're going to do them).