[_009]

Back in 2005, I remember working on startups running on Scrum principles. It worked well at the time, we where able to ship, grow the team, and move forward with a nice few-features-per-week cadence, working remotely, on a small team; less than 10. Tt always worked fine, but very centralized and slow, as all-things-dev were at the time.

I worked with ActiveColab in 2007, Skype 2007, Yammer 2009, Trello 2011, Pivotal Tracker 2013, Trello 2016, Confluence 2022, Slack 2013, Google Meet, and sometimes I think, scrum became _less-relevant_ over the years as more advanced product management tools became the norm and the product manager role matured by leveraging them.

These days, it's not rare to see lead developers manage kanban-like boards very effectively, releasing on time, with grace, without the need of a scrum master to coordinate efforts.

I do like asynchronous scrum daily standups using http://geekbot.com on slack, when on-site or/and distributed and doing sprints. I seen this work well on startups going from pre-seed to series B.

Personally, I am fascinated with team dynamics and how they've changed over the years. We are definitely living the best of times as a developer and I still see sparkles of well-applied scrum every now and then that works nicely.

[vannevar]

>These days, it's not rare to see lead developers manage kanban-like boards very effectively, releasing on time, with grace, without the need of a scrum master to coordinate efforts.

Sadly, it's also common to see such kanban teams endlessly winging it and slowly losing sight of what they were trying to accomplish, at the same time burning out their teams on an endless stream of tickets and testing without ever taking time to reflect and course correct on their goals.

[mhss]

It's almost as if the process was not the most (not even close) important thing to ship value consistently.

[vannevar]

True. But given a team of average ability, good process (ie, good habits and conventions) can definitely mean the difference between success and failure.

[mhss]

I'm sorry if I'm splitting hairs a bit here, but I'd argue 'good enough' process is all you need even with average teams. Keep them focused, limit their in flight work, unblock them, iterations with feedback, etc; I just feel some people spend inordinate amounts of time trying to optimize process when process hits diminishing returns pretty quickly.

[vannevar]

>I'd argue 'good enough' process is all you need even with average teams.

That's sort of a tautology, right? If it's 'good enough', that implies it's a good process. In my experience, Scrum is a good enough process, with very little wasted overhead. It keeps the team focused, limits their in-flight work, unblocks them and offers regular iterations with feedback.

I'd agree that over-optimization is sometimes a problem, but when something as simple as scrum fails, it's usually down to the basics, like poor meeting practices, or micromanagement, or something outside of the development process entirely, like badly underbidding the project. No amount of process will save a project that was doomed from the start due to poor budgeting of time or money.

[mhss]

I think 'good enough' is just an expression to mean it doesn't need to be perfect or very elaborate. Unfortunately the term scrum these days is far from precise and does not guarantee it'll be lightweight, but the principles I definitely agree with. I've seen all sorts of things, including people over-focusing on the scrum process and nitpicking about all sorts of irrelevant things. I've worked with and without scrum masters in teams as an IC and manager. I think having a scrum master is often unjustified overhead, but having an experienced SM in new teams or teams with an inexperienced manager or lacking in soft-skills, it can help fill the gaps.

And yeah you said it well at the end. There are many other things that I believe are more relevant than the process, but you do need a process teams can follow.