5 ms·

I had this problem too. My younger developers pushed really hard to bring Agile in. One of the supposed benefits was that all developers were treated equally (t

I had this problem too. My younger developers pushed really hard to bring Agile in. One of the supposed benefits was that all developers were treated equally (today we might say they were fungible) We have it a really good shot; we even hired a Certified Scrum Master. But after a while it seemed to me that we were just doing lots of tiny waterfalls. It was nothing for a developer to spend a whole sprint spinning their wheels and not making progress. Long story short, 2 years later I took over the team, threw it all out, and set up a system based around Kanban and hands-on management. And suddenly we became productive again. (Not saying Kanban is a solution, just that Agile is not)

detaro 4y ago
People really use weird labels nowadays. Kanban is agile!
- bitwize 4y ago
  "Agile" in job reqs usually means "we do Scrum with Jira, you'd better be able to align with the Scrum process".
- doctor_eval 4y ago
  You’re right, what I should have said is that Scrum doesn’t work. And I tend to use big-A Agile when talking about the formal processes and little-a agile when talking about the manifesto. I think the manifesto is great btw. It’s just that the formal “Agile” processes, such as the way Scrum is practiced, don’t implement it.
satyrnein 4y ago
Interesting, what I like about kanban is that (in my opinion) it explicitly recognizes that work proceeds through specific stages, and therefore tickets go through a mini-waterfall. Waterfall is great with a small enough batch size. In contrast, scrum seems to pretend that design, development, code review, QA, etc, all happen at once throughout the sprint.
- doctor_eval 4y ago
  We are probably on the same page here but I would describe it differently. For me, there is a whole separate prioritisation and design process that runs ahead of the Kanban board. So by the time work arrives on the board, we have a pretty good idea of what we need to build. The difference is that in waterfall, by definition, we would build what we’re told. But implementation of a design should instead be an ongoing conversation/negotiation between the high-level designer and the low-level implementor. And that can result in big changes to the high level design as problems, inefficiencies or new ideas come up. That is the “hands on” management I mentioned. My way of working is heavily influenced by DDD. Design can only get you so far, and any process that imposes a top-down structure is IMO likely to fail.
- 1123581321 4y ago
  They do happen at once if the stories are working slices of software, and they’re all in different stages. Agile planning has used kanban-style stage notation for a long time. It’s just not always laid out in a grid.
  - satyrnein 4y ago
    On day 1 of the sprint, aren't they all in the same stage?
    - 1123581321 4y ago
      Not in our case. We’re breaking work into small stories that are self-contained improvements that can (usually) move into production independently of anything else. Typically an individual or team can complete more than one in a two week period. But either way, we won’t break them any smaller than that atomic “completeness” to fit into an arbitrary time interval. The sprint is just for automatic estimating of when we’ll get to a story, how often to demo progress to interested parties, etc.
      - satyrnein 4y ago
        In that case, we might only be differing on terminology. In my understanding, scrum's defining feature was the fixed time box. What you described sounds like kanban to me!

detaro 4y ago

People really use weird labels nowadays. Kanban is agile!

bitwize 4y ago
"Agile" in job reqs usually means "we do Scrum with Jira, you'd better be able to align with the Scrum process".
doctor_eval 4y ago
You’re right, what I should have said is that Scrum doesn’t work. And I tend to use big-A Agile when talking about the formal processes and little-a agile when talking about the manifesto. I think the manifesto is great btw. It’s just that the formal “Agile” processes, such as the way Scrum is practiced, don’t implement it.

satyrnein 4y ago

Interesting, what I like about kanban is that (in my opinion) it explicitly recognizes that work proceeds through specific stages, and therefore tickets go through a mini-waterfall. Waterfall is great with a small enough batch size. In contrast, scrum seems to pretend that design, development, code review, QA, etc, all happen at once throughout the sprint.

doctor_eval 4y ago
We are probably on the same page here but I would describe it differently. For me, there is a whole separate prioritisation and design process that runs ahead of the Kanban board. So by the time work arrives on the board, we have a pretty good idea of what we need to build. The difference is that in waterfall, by definition, we would build what we’re told. But implementation of a design should instead be an ongoing conversation/negotiation between the high-level designer and the low-level implementor. And that can result in big changes to the high level design as problems, inefficiencies or new ideas come up. That is the “hands on” management I mentioned. My way of working is heavily influenced by DDD. Design can only get you so far, and any process that imposes a top-down structure is IMO likely to fail.
1123581321 4y ago
They do happen at once if the stories are working slices of software, and they’re all in different stages. Agile planning has used kanban-style stage notation for a long time. It’s just not always laid out in a grid.
- satyrnein 4y ago
  On day 1 of the sprint, aren't they all in the same stage?
  - 1123581321 4y ago
    Not in our case. We’re breaking work into small stories that are self-contained improvements that can (usually) move into production independently of anything else. Typically an individual or team can complete more than one in a two week period. But either way, we won’t break them any smaller than that atomic “completeness” to fit into an arbitrary time interval. The sprint is just for automatic estimating of when we’ll get to a story, how often to demo progress to interested parties, etc.
    - satyrnein 4y ago
      In that case, we might only be differing on terminology. In my understanding, scrum's defining feature was the fixed time box. What you described sounds like kanban to me!