6 ms·

Because few organizations actually enable real Agile development. I did some "Agile coaching" in a previous life and time and time again I'd see teams embrace t

Because few organizations actually enable real Agile development. I did some "Agile coaching" in a previous life and time and time again I'd see teams embrace the cosmetic parts of Agile - daily standups, iterations, retrospectives - but workflow was still much the same as it always was. Agile, done right, is more about how work is broken down into consumables and deliverables. It's about clear prioritization and freedom to focus on the task at hand. But most development teams would iterate aimlessly, while the organization around them continued doing business as usual. To successfully embrace Agile, the entire organization has to do so at some level or another. You have to break requirements down into pieces that can be consumed in an iteration. You have to prioritize clearly. And you can't change priorities until the iteration is complete. Additionally, many software teams misunderstand how they work. I can't tell you how many times a team would insist to me they were using a waterfall process, but when I asked them to describe the previous workday they'd describe end-to-end firefighting. When I would introduce Agile and the controls that it brings, they would react negatively expecting that Agile was some magical organized free-for-all. Additionally, lots of consultants made money off of the promise of Agile and the cult of Agile. They didn't provide practical solutions, and organizations resisted change. So much of the indigestion that developers have regarding Agile is due to their own experiences with organizations that bought the promise of Agile but didn't do the necessary work to make it successful.

Tomis02 9y ago
> real Agile Heh, classic response. Whenever your project fails, your coach tells you it's your fault because you didn't do real Agile. Same with OOP, whenever your code inevitably becomes a tangled mess of classes, you will have all sorts of gurus making metric shit tons of money from books and consulting telling you you didn't do real OOP. Guys, please, can you just admit there is no recipe for success (rhetorical question, of course you can't, that's where you money comes from, maybe you even believe your own bullshit)? There is no real Agile and OOP and other crap that I forget, they're just buzzwords that, when applied long or hard enough, produce shit. If you had kept you project to an absolute minimal level of Agile and OOP, it would probably still be alive and kicking. But you didn't, because you jumped on the bandwagon, you used religiously whatever was popular. > Agile, done right ... Yeah, heard that a thousand times before. Sadly, younger developers fall for this all the time, so shit grows exponentially. I'm aware my opinion has always been in minority but whatever.
- wpietri 9y ago
  I have done it right. It worked well for me. I've been on happy teams that produced good code: high quality, high test coverage, good for users. We did technical work that I'm still proud of. And we believe that was true because we paid careful attention to how we were working and improved it continuously, using a lot of techniques from the Agile movement. I grant that there's no one right way. There are many, and they depend on circumstances. I certainly grant that there are an ocean of idiots selling bullshit. But you're throwing the baby out with the bathwater. There are better and worse ways to make software. Teams can reflect on how they work and get better over time. Those teams can recognize patterns, and other teams can benefit from learning about those patterns and trying them out in their environment. And that's how things like Extreme Programming came to be: teams experimenting and sharing what they'd learned with other people who wanted to get better. That was exactly what the early Agile movement was. Piss all over that if you like. But you'll be missing out.
  - lj3 9y ago
    I've been on teams that have agile it right. Some have failed and some succeeded. I've been on teams that practiced chaos driven development. Some of those succeeded and some of those failed. Did you drink any kool-aid on the way in?
    - wpietri 9y ago
      Your theory is that software is totally random? There's no correlation between what people do and how the project goes? That is a really weird theory for a programmer to have about anything, let alone what he's chosen to spent 80,000 hours doing.
      - Tomis02 9y ago
        > That is a really weird theory Not so weird at all. Codebase and process don't matter to a customer, all they see and judge is the end product. Sometimes even the end product doesn't matter, as the likes of Google can put much more money into ads and marketing than you. There might be a correlation between what people do and how the project goes if you're NASA or BMW. But for 99% of the software world, nobody cares if you have the most hacky codebase ever as long as it does what it's supposed to do and doesn't have too many bugs.
jeffdavis 9y ago
Breaking tasks down is the hard part. Usually much harder than completing them once broken down properly.
Clubber 9y ago
The problem with breaking things down iteratively is the same as trying to paint a mural 1 square inch at a time. The developers / designers don't get a feel for the overall picture what so ever. Also, instead of having broader estimates in terms of months, you force developers to rush constantly with sprint completion pressure. In case you didn't know, rushing developers is very, very counterproductive. Cost, Time, Scope. Pick 2.
- mpweiher 9y ago
  > breaking things down iteratively is the same as trying to paint a mural 1 square inch at a time. What you are describing is the opposite of iterative. When you iterate, you go over the same territory multiple times, with more insight/detail.
  - Clubber 9y ago
    Where I recently did this, each iteration was a feature and it was supposed to be "code complete, ready for production, never needing to be modified again." We had to constantly fight to refactor existing stories when new stories were introduced that made our original designs less than desirable. It was a mess.
- scarface74 9y ago
  Software development is all about breaking problems down iteratively. If you can't break the problem down to a scale where people understand, how can you ever break a problem down to a scale where a computer can understand? But I do agree with you about "sprint completion pressure". With Kanban you don't have that and you don't have large day long "sprint planning sessions". You have just enough work in the "Dev ready" column to keep the pipeline going. Of course not having the sprint planning pressure and not having a deadline to release doesn't work without a continuous delivery pipeline and some way to turn features on when ready.
  - Clubber 9y ago
    >Software development is all about breaking problems down iteratively. It is, but it depends on the size of the iteration and who is breaking it down as to whether or not it is useful. I much prefer, "here is the problem, solve it," to "here is the problem and I'm going to tell you how to solve it, even though I have no idea how software development works." Of course, the most recent "official scrum" environment I worked in was horrible. They really used it to micro-manage development. We actually created all the stories for a multi-year project so we could give an overall timeline (waterfall) to management, then the business dictated the order of the stories even when they made no sense. It was a constant battle.
BenoitEssiambre 9y ago
>you can't change priorities until the iteration is complete The original agile manifesto was meant to avoid following plans blindly like that. It's only four lines one of which is "Responding to change over following a plan". Despite what the kanban people think, Agile isn't supposed to be "small waterfall" where the work and priorities are set in advance instead of discovered as you test hypotheses through trying different technological approaches and doing back and forth with the users. What you propose means that if in a cycle you discover that the plan was sub optimal and not well prioritized (and when you are iterating, you are in the best position to find that out) you march on towards the dead end and only adjust after the "sprint" is over? That is not agile, it may fall under scrum but really it is just small waterfall. Good agile as it was originally stated is compatible with and even comes from a similar line of reasoning as the Lean approaches. The core of Lean is that the people closest to the technology should be put in a close relationship with the users to be in the best position possible to resolve what I like to call the crux of innovation. Innovation's most difficult and most crucial part which is to figure out what work has the most value to effort ratio, what has the most risk and needs to be studied early to clear up that risk and ultimately what the team should be working on first. At least for any work that is somewhat leading edge or a bit experimental, priorities cannot be properly assessed without experimentation, user feedback and management of uncertainty and risk trough early experimentation. Scrum tends to ignore this core problem by positing a product owner that has the answers. This is very reminiscent of waterfall where people disconnected from the technology and who aren't experimenting and putting things in front of users, who are ultimately in a bad position to make plans are making those plans anyways. IMO what you are describing and a lot of the ideas in scrum are the very things that original agile was meant to prevent and also goes against Lean approaches. Here is the agile manifesto: "Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan"
t0mbstone 9y ago
> "you can't change priorities until the iteration is complete" And yet the very definition of the word, "Agility" is supposed to mean moving quickly and nimbly, able to easily change direction.
- trentnix 9y ago
  Then you shorten iterations if you need to change priorities more often, or you stop the iteration and start a new one. Waterfall created a scenario where requirements couldn't be changed without significant effort. Agile creates a situation where those managing the backlog can change requirements whenever they see fit. And developers, next time an iteration is planned, take the top items from the backlog that fit into their iteration capacity. The side effect of shorter iterations is that requirements have to be broken down to fit inside the smaller iteration, so there is a price to be paid by those managing the backlog and generating requirements if change needs to happen quickly. Agile methodologies don't enable change as needed, they create a structured way of handling inevitable change. And when the backlog is adjusted to accommodate that change, the consequences of that change to budget and delivery date are easy for everyone to see. If you don't have controls in place, then there is no understanding of the cost of change. And without understanding the cost, good cost-value decisions can't be made.
  - Avernar 9y ago
    Shorten the iteration or abort it midway? Not gonna happen. Management loves having a Monday to Friday iteration. That structure and control is way more important to them than reaponding to change. Shortening the iterations means you now how to rechop all your tasks and do the estimates again wasting even more time. Also the smaller the task the less people focus on the bigger picture and your software just turns into a mess of puzzle pieces. Just my experiences from having to go through Agile Hell.
    - trentnix 9y ago
      Then that confirms my OP - everyone wants to embrace the cosmetic pieces but the actual meat of Agile is ignored. Every control has to have consequences, or else bad behavior has no cost. Your organization is addicted to what the calendar says, and the software is neglected. The consequences are suboptimal productivity and/or quality. Appearing to work has more value than completing work. No software process is immune to leadership failures. Wasting time? Measuring twice and cutting once is done because it saves time. As a shirt I saw recently said, "weeks of programming saves hours of planning".

Tomis02 9y ago

> real Agile Heh, classic response. Whenever your project fails, your coach tells you it's your fault because you didn't do real Agile. Same with OOP, whenever your code inevitably becomes a tangled mess of classes, you will have all sorts of gurus making metric shit tons of money from books and consulting telling you you didn't do real OOP. Guys, please, can you just admit there is no recipe for success (rhetorical question, of course you can't, that's where you money comes from, maybe you even believe your own bullshit)? There is no real Agile and OOP and other crap that I forget, they're just buzzwords that, when applied long or hard enough, produce shit. If you had kept you project to an absolute minimal level of Agile and OOP, it would probably still be alive and kicking. But you didn't, because you jumped on the bandwagon, you used religiously whatever was popular. > Agile, done right ... Yeah, heard that a thousand times before. Sadly, younger developers fall for this all the time, so shit grows exponentially. I'm aware my opinion has always been in minority but whatever.

wpietri 9y ago
I have done it right. It worked well for me. I've been on happy teams that produced good code: high quality, high test coverage, good for users. We did technical work that I'm still proud of. And we believe that was true because we paid careful attention to how we were working and improved it continuously, using a lot of techniques from the Agile movement. I grant that there's no one right way. There are many, and they depend on circumstances. I certainly grant that there are an ocean of idiots selling bullshit. But you're throwing the baby out with the bathwater. There are better and worse ways to make software. Teams can reflect on how they work and get better over time. Those teams can recognize patterns, and other teams can benefit from learning about those patterns and trying them out in their environment. And that's how things like Extreme Programming came to be: teams experimenting and sharing what they'd learned with other people who wanted to get better. That was exactly what the early Agile movement was. Piss all over that if you like. But you'll be missing out.
- lj3 9y ago
  I've been on teams that have agile it right. Some have failed and some succeeded. I've been on teams that practiced chaos driven development. Some of those succeeded and some of those failed. Did you drink any kool-aid on the way in?
  - wpietri 9y ago
    Your theory is that software is totally random? There's no correlation between what people do and how the project goes? That is a really weird theory for a programmer to have about anything, let alone what he's chosen to spent 80,000 hours doing.
    - Tomis02 9y ago
      > That is a really weird theory Not so weird at all. Codebase and process don't matter to a customer, all they see and judge is the end product. Sometimes even the end product doesn't matter, as the likes of Google can put much more money into ads and marketing than you. There might be a correlation between what people do and how the project goes if you're NASA or BMW. But for 99% of the software world, nobody cares if you have the most hacky codebase ever as long as it does what it's supposed to do and doesn't have too many bugs.

jeffdavis 9y ago

Breaking tasks down is the hard part. Usually much harder than completing them once broken down properly.

Clubber 9y ago

The problem with breaking things down iteratively is the same as trying to paint a mural 1 square inch at a time. The developers / designers don't get a feel for the overall picture what so ever. Also, instead of having broader estimates in terms of months, you force developers to rush constantly with sprint completion pressure. In case you didn't know, rushing developers is very, very counterproductive. Cost, Time, Scope. Pick 2.

mpweiher 9y ago
> breaking things down iteratively is the same as trying to paint a mural 1 square inch at a time. What you are describing is the opposite of iterative. When you iterate, you go over the same territory multiple times, with more insight/detail.
- Clubber 9y ago
  Where I recently did this, each iteration was a feature and it was supposed to be "code complete, ready for production, never needing to be modified again." We had to constantly fight to refactor existing stories when new stories were introduced that made our original designs less than desirable. It was a mess.
scarface74 9y ago
Software development is all about breaking problems down iteratively. If you can't break the problem down to a scale where people understand, how can you ever break a problem down to a scale where a computer can understand? But I do agree with you about "sprint completion pressure". With Kanban you don't have that and you don't have large day long "sprint planning sessions". You have just enough work in the "Dev ready" column to keep the pipeline going. Of course not having the sprint planning pressure and not having a deadline to release doesn't work without a continuous delivery pipeline and some way to turn features on when ready.
- Clubber 9y ago
  >Software development is all about breaking problems down iteratively. It is, but it depends on the size of the iteration and who is breaking it down as to whether or not it is useful. I much prefer, "here is the problem, solve it," to "here is the problem and I'm going to tell you how to solve it, even though I have no idea how software development works." Of course, the most recent "official scrum" environment I worked in was horrible. They really used it to micro-manage development. We actually created all the stories for a multi-year project so we could give an overall timeline (waterfall) to management, then the business dictated the order of the stories even when they made no sense. It was a constant battle.

BenoitEssiambre 9y ago

>you can't change priorities until the iteration is complete The original agile manifesto was meant to avoid following plans blindly like that. It's only four lines one of which is "Responding to change over following a plan". Despite what the kanban people think, Agile isn't supposed to be "small waterfall" where the work and priorities are set in advance instead of discovered as you test hypotheses through trying different technological approaches and doing back and forth with the users. What you propose means that if in a cycle you discover that the plan was sub optimal and not well prioritized (and when you are iterating, you are in the best position to find that out) you march on towards the dead end and only adjust after the "sprint" is over? That is not agile, it may fall under scrum but really it is just small waterfall. Good agile as it was originally stated is compatible with and even comes from a similar line of reasoning as the Lean approaches. The core of Lean is that the people closest to the technology should be put in a close relationship with the users to be in the best position possible to resolve what I like to call the crux of innovation. Innovation's most difficult and most crucial part which is to figure out what work has the most value to effort ratio, what has the most risk and needs to be studied early to clear up that risk and ultimately what the team should be working on first. At least for any work that is somewhat leading edge or a bit experimental, priorities cannot be properly assessed without experimentation, user feedback and management of uncertainty and risk trough early experimentation. Scrum tends to ignore this core problem by positing a product owner that has the answers. This is very reminiscent of waterfall where people disconnected from the technology and who aren't experimenting and putting things in front of users, who are ultimately in a bad position to make plans are making those plans anyways. IMO what you are describing and a lot of the ideas in scrum are the very things that original agile was meant to prevent and also goes against Lean approaches. Here is the agile manifesto: "Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan"

t0mbstone 9y ago

> "you can't change priorities until the iteration is complete" And yet the very definition of the word, "Agility" is supposed to mean moving quickly and nimbly, able to easily change direction.

trentnix 9y ago
Then you shorten iterations if you need to change priorities more often, or you stop the iteration and start a new one. Waterfall created a scenario where requirements couldn't be changed without significant effort. Agile creates a situation where those managing the backlog can change requirements whenever they see fit. And developers, next time an iteration is planned, take the top items from the backlog that fit into their iteration capacity. The side effect of shorter iterations is that requirements have to be broken down to fit inside the smaller iteration, so there is a price to be paid by those managing the backlog and generating requirements if change needs to happen quickly. Agile methodologies don't enable change as needed, they create a structured way of handling inevitable change. And when the backlog is adjusted to accommodate that change, the consequences of that change to budget and delivery date are easy for everyone to see. If you don't have controls in place, then there is no understanding of the cost of change. And without understanding the cost, good cost-value decisions can't be made.
- Avernar 9y ago
  Shorten the iteration or abort it midway? Not gonna happen. Management loves having a Monday to Friday iteration. That structure and control is way more important to them than reaponding to change. Shortening the iterations means you now how to rechop all your tasks and do the estimates again wasting even more time. Also the smaller the task the less people focus on the bigger picture and your software just turns into a mess of puzzle pieces. Just my experiences from having to go through Agile Hell.
  - trentnix 9y ago
    Then that confirms my OP - everyone wants to embrace the cosmetic pieces but the actual meat of Agile is ignored. Every control has to have consequences, or else bad behavior has no cost. Your organization is addicted to what the calendar says, and the software is neglected. The consequences are suboptimal productivity and/or quality. Appearing to work has more value than completing work. No software process is immune to leadership failures. Wasting time? Measuring twice and cutting once is done because it saves time. As a shirt I saw recently said, "weeks of programming saves hours of planning".