Hacker News Reader

Comment by doctor_eval | Hacker News Reader

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)

View on HN

People really use weird labels nowadays. Kanban is agile!

"Agile" in job reqs usually means "we do Scrum with Jira, you'd better be able to align with the Scrum process".

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.

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.

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.

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.

On day 1 of the sprint, aren't they all in the same stage?

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.

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!

I would say we are using a mix of kanban tools and the scrum process to practice agile software development philosophy. We aren’t really using the kanban process since teams shepherd their stories to completion regardless of WIP at any step. And user research is more based on the continuously evolving end goal than what is being pulled in by openings in the kanban board. But yes, we are not trying to define two weeks of work up front, just noting what gets done every two weeks.

Reply on news.ycombinator.com