Comment by sufyanadam | Hacker News Reader

Comment by sufyanadam | Hacker News Reader

Parent Full thread

> Rule 20: When somebody says Agile, push for Kanban, not Scrum... ...Scrum can easily mean that you’ll get pressured to work extra hours to complete something within that arbitary two-week horizon.

This is very true. I've worked for over 12 years in the bay area in different software engineering teams at startups and found that scrum just leads to burnout and developer unhappiness and encourages team members to just do the minimum 'slap it together till it works' solution without thinking long-term on codebase stability, architecture and maintainability. By far the best development process that leads to high developer happiness, engagement, productivity and empowers them to go the extra mile to go above and beyond, and produce work that acts as a force-multiplier across the team, is what the author describes here as 'Kanban', also known as eXtreme programming. Most people from Pivotal Labs or Carbon Five or from a startup that adopted their process would recognize what the author describes as 'Kanban'.

To be clear: XP and Kanban are different things. XP has prescribed engineering practices, most forcefully that development should be done via pair programming for continuous code review. Kanban prescribes no engineering practices and could be used in lots of non-engineering contexts (e.g., your marketing team could take all of their tasks, put them in a prioritized backlog, then track the progression of those tasks across Todo/Doing/Done/Blocked and that would still be Kanban). Kanban is great for teams in maintenance mode with a steady in/out of smaller tasks in their backlogs, but it's not great for helping your customers get an idea of when they might see a new product or feature.

I do find it odd that people describe Scrum as "leading to burnout" or a "death march", and I'm guessing most people who do either have not worked in waterfall IT projects that preceded widespread Agile or they're part of "Agile" teams that do waterfall development in two-week chunks with daily standups. (Maybe both.)

Scrum practiced well brings the essence of small-town democracy into the workplace. You have to work a late night the day before sprint release? You were in the room when the team agreed to the body of work that would be committed for delivery in this sprint. You just slapped it together until it works? You'll get to accommodate 0-point bugs in a future sprint, and perhaps you can have a conversation in your team's retrospective about why velocity went down that week. (Speaking of: how many other professions get to have a candid conversation with management about what's going well and not going well on a regular basis? Not many, it's a real privilege!) There are certainly deviations from this, but in my experience Scrum teams' problems are generally of their own making, and many of those problems are refined away over time as teams grow and better define their norms.

> You have to work a late night the day before sprint release? You were in the room when the team agreed to the body of work that would be committed for delivery in this sprint.

Fuck that. The fact that my estimate does not work out as expected should not be a reason to work late nights just to get it done.

That’s exactly the death march that you were saying Scrum is not.

+1 A million times on this, you nailed it.

> I'm guessing most people who do either have not worked in waterfall IT projects that preceded widespread Agile or they're part of "Agile" teams that do waterfall development in two-week chunks with daily standups.

I haven’t come into an organization in the past 15 or so years which wasn’t using _some_ form of Agile (generally Scrum). It’s fairly likely anyone who has started their career in software within that timeframe may never have experienced how things were done in the past.

That said, there is certainly always room to improve, which is a critical piece I see teams often miss in Scrum. The two-week cycle isn’t just about planning and doing whatever it takes to hit the commitment. It’s about a) the business having a cycle they can plan to if priorities change and b) the team having a regular feedback loop they can use to help understand where they are doing well and where they aren’t.

Missing a sprint commitment is fine. Missing the commitment for multiple sprints in a row means something is going wrong. This is an opportunity to learn and improve, and the sprint retrospective at the end is as important if not more so than the planning meetings.

And then make time in the sprint to implement improvements in the process, tech, whatever is needed. We use 20% of the sprint time as a rule on this, and move that up and down periodically as needed.

> You have to work a late night the day before sprint release? You were in the room when the team agreed to the body of work that would be committed for delivery in this sprint.

This can get complicated depending on the team dynamics and upper management. Sometimes there are pressures that cause the team to overcommit (throw lower estimates, giving the illusion that things can be done within the 2 weeks).

Overall, I think it kind of depends on the product you're building. If it's some SaaS product in the modern world of CI/CD, it doesn't really make sense to hold everything up for 2 weeks and then release. If new things are being continuously deployed/delivered, then value is being delivered faster and the business is achieving goals faster, learning faster, getting returns faster, rather than having to wait 2 weeks at a time. This in turn makes your business more 'agile', and all the productivity boosts, developer empowerment and happiness are great side benefit of the iterative process.

Reply on news.ycombinator.com