3 ms·

"Proper" (haha, yes I know) agile is anti-dogma. You throw out the rituals ("processes and tools", "plans") when they don't work. That's called a retro. How

by mrkeen 7y ago

"Proper" (haha, yes I know) agile is anti-dogma. You throw out the rituals ("processes and tools", "plans") when they don't work. That's called a retro. How do you know if you're doing it right? You'll have "working software". That's a pretty subjective idea, so you'd better have someone to help you judge that, i.e. a "customer".

crimsonalucard 7y ago
Do retros allow you to throw out agile and retros? In practice I find retros to be a special place where engineers can vent their discontent and nothing will ever be done about it.
- mrkeen 7y ago
  I worked somewhere where we made a conscious decision at a retro to not do them so often. But to be honest that was probably the most agile place I've been at. But perhaps good retros are the exception, not the rule. At the place I worked, we started with a pretty regimented scrum - Monday morning planning poker, fixed-length sprints, which were closed and groomed, etc. I hated that crap. There was also a tech lead bully that insisted on doing things his way, and would use the code review process to keep other people's code out of the system. It was a real death march. By the time we had the basics of the system running, it was a dozen layers of synchronous blocking code where simple REST requests would take between 2 and 60 seconds to complete. Eventually the bully left, and after that we eventually wore our (non-tech) team lead down into getting rid of discrete sprints and planning poker, and the devs tended towards just 'working on the next thing'. I think the biggest factors we had in our favour were: 1) The team lead (pretty much the boss, too) was not technical, so he had no choice but to leave the tech decisions to us. 2) The tech bully left us in such a shitty state that it became obvious we'd need big changes, rather than token ones. 3) We got quite a bit of rapport happening and eventually the team lead understood that we actually wanted to get the system working nicely. The devs also got better at pitching ideas, like why a certain large changes were necessary. I can't imagine we would have gotten to steer the ship in any meaningful way without a bunch of factors lining up like that.
- EdwardDiego 7y ago
  In practice I found retros very useful in my last Scrum team because we iterated on our process to make retros useful. #1 was clustering similar sad faces. #2 was as a team, agreeing on actions we could take on those clusters. #3 was tracking how well we did on performing those actions. If it's just venting, it's not overly useful.
- UK-Al05 7y ago
  In theory if the retros arnt providing anything useful then yes. I would try to fix the retros though or have some kind of alternative to allow the team to change the process.
ch_123 7y ago
> How do you know if you're doing it right? You'll have "working software". This is _exactly_ the problem - agile is never defined by itself, it is defined in terms of some desirable outcomes. Project was on time and succesful? Great victory for agile. Project failed? Need more agile in the future. In my experience, all this is used as a smoke screen by management types who have no real idea what they are doing to externalize their own accountability.
- UK-Al05 7y ago
  Agile = reflect and adapt. Replace agile word with that in your paragraph and it makes sense without sounding silly. If you've done well you've probably learned and adapted. If you havent done well, you probably need to reflect and work how to do it better next time. Things arnt 'proper' agile when they are not about adapting but instead following a specific process your team cant change.
  - stcredzero 7y ago
    If you've done well you've probably learned and adapted. If you havent done well, you probably to reflect and work how to do it better next time. In that case, you can also replace "Agile" with "Kung-Fu!" Actually, I'm serious. There are various anti-philosophies in art and the martial arts which say something like this.
    - UK-Al05 7y ago
      Yes. It's been rediscovered thousands of times. OODA loop, plan do check act, kaizan etc The core is the same.
  - Melchizedek 7y ago
    So we as developers have the power to throw out things like daily stand-ups and sprints? And if we don't have that power, we're not being agile? Cool, tell that to your "scrum master" next time you see him.
    - 7y ago
bearmobius 7y ago
Lately I've started to think Agile also bears some striking similarities to Communism. It has its dogmatic adherents, and it actually sounds good on paper. It's just that everywhere I've seen it tried, it fails. And the reason given is always "that wasn't proper Agile". Like other dogmas or ideologies, it's unfalsifiable. No amount of real-world experiments can invalidate it if the reason is always "that wasn't real Agile".
- mrkeen 7y ago
  What wasn't working for you, and what did you change?
- deleted 7y ago
  [deleted]

by mrkeen 7y ago

crimsonalucard 7y ago

Do retros allow you to throw out agile and retros? In practice I find retros to be a special place where engineers can vent their discontent and nothing will ever be done about it.

mrkeen 7y ago
I worked somewhere where we made a conscious decision at a retro to not do them so often. But to be honest that was probably the most agile place I've been at. But perhaps good retros are the exception, not the rule. At the place I worked, we started with a pretty regimented scrum - Monday morning planning poker, fixed-length sprints, which were closed and groomed, etc. I hated that crap. There was also a tech lead bully that insisted on doing things his way, and would use the code review process to keep other people's code out of the system. It was a real death march. By the time we had the basics of the system running, it was a dozen layers of synchronous blocking code where simple REST requests would take between 2 and 60 seconds to complete. Eventually the bully left, and after that we eventually wore our (non-tech) team lead down into getting rid of discrete sprints and planning poker, and the devs tended towards just 'working on the next thing'. I think the biggest factors we had in our favour were: 1) The team lead (pretty much the boss, too) was not technical, so he had no choice but to leave the tech decisions to us. 2) The tech bully left us in such a shitty state that it became obvious we'd need big changes, rather than token ones. 3) We got quite a bit of rapport happening and eventually the team lead understood that we actually wanted to get the system working nicely. The devs also got better at pitching ideas, like why a certain large changes were necessary. I can't imagine we would have gotten to steer the ship in any meaningful way without a bunch of factors lining up like that.
EdwardDiego 7y ago
In practice I found retros very useful in my last Scrum team because we iterated on our process to make retros useful. #1 was clustering similar sad faces. #2 was as a team, agreeing on actions we could take on those clusters. #3 was tracking how well we did on performing those actions. If it's just venting, it's not overly useful.
UK-Al05 7y ago
In theory if the retros arnt providing anything useful then yes. I would try to fix the retros though or have some kind of alternative to allow the team to change the process.

ch_123 7y ago

> How do you know if you're doing it right? You'll have "working software". This is _exactly_ the problem - agile is never defined by itself, it is defined in terms of some desirable outcomes. Project was on time and succesful? Great victory for agile. Project failed? Need more agile in the future. In my experience, all this is used as a smoke screen by management types who have no real idea what they are doing to externalize their own accountability.

UK-Al05 7y ago
Agile = reflect and adapt. Replace agile word with that in your paragraph and it makes sense without sounding silly. If you've done well you've probably learned and adapted. If you havent done well, you probably need to reflect and work how to do it better next time. Things arnt 'proper' agile when they are not about adapting but instead following a specific process your team cant change.
- stcredzero 7y ago
  If you've done well you've probably learned and adapted. If you havent done well, you probably to reflect and work how to do it better next time. In that case, you can also replace "Agile" with "Kung-Fu!" Actually, I'm serious. There are various anti-philosophies in art and the martial arts which say something like this.
  - UK-Al05 7y ago
    Yes. It's been rediscovered thousands of times. OODA loop, plan do check act, kaizan etc The core is the same.
- Melchizedek 7y ago
  So we as developers have the power to throw out things like daily stand-ups and sprints? And if we don't have that power, we're not being agile? Cool, tell that to your "scrum master" next time you see him.
  - 7y ago

bearmobius 7y ago

Lately I've started to think Agile also bears some striking similarities to Communism. It has its dogmatic adherents, and it actually sounds good on paper. It's just that everywhere I've seen it tried, it fails. And the reason given is always "that wasn't proper Agile". Like other dogmas or ideologies, it's unfalsifiable. No amount of real-world experiments can invalidate it if the reason is always "that wasn't real Agile".

mrkeen 7y ago
What wasn't working for you, and what did you change?
deleted 7y ago
[deleted]