Podcast 253: is Scrum making you a worse engineer?
This week, we dive into the debate over Scrum methodology. Sure, it helps you finish your sprint faster. But is it leaving your engineers burnt out, and your product substandard?
Episode Notes
What began as a question on our Software Engineering Stack Exchange graduated into a blog post for further discussion.
Paul points out that modern tooling has internalized so much of agile methodology that developers tend to work this way without having to explicitly create a culture or process around Scrum.
And as Sara points out, if it turns out you’re being driven to optimize for finished work over quality work, the problem may not be Scrum, but the pressures of your particular manager or company.
Our lifeboat of the week goes to an old school Excel question with over half a million views. Thanks to Michelle for earning a badge while answering this query: How do I append the same text to every cell in a column in Excel?
A written transcript of this podcast episode can be found here.
Tags: bulletin, stack overflow, the stack overflow podcast
9 Comments
The ‘How do I append the same text to every cell in a column in Excel? ‘ link leads to a reply by a user called ‘Melissa’ not ‘Michelle’.
Still no transcripts?
Sara, use the phrase “I think ” a little less, as it starts to feel like you’re not sure about what you’re saying
Please, no little intro explaining what the podcast is on each episode. Personally, I find those kind of annoying. Put it in the description of the podcast. I’d bet most people aren’t just listening to episodes of random podcasts, and have some idea of why they’re listening to a podcast before they start an episode. Either because they were referred to the podcast from somewhere, or they found it in a directory and the description sounded appealing.
I enjoyed this week insight on SCRUMin…love the podcast.
This is no accident for me and scrum tend to favor this when we focus on velocity & commitment. Safe go beyond that by adding more predictability and then reducing flexibility. This is why it is so popular as the methodology is a perfect fit for micro management. Safe using agile to make everybody work like in a factory.
A basic agile methodology is just incremental and focus on getting things done and working together. This is the core of agile for me. Being pragmatic and incremental.
Just putting a kanban board would help organize things with a backlog, a tracking of tasks. You would of course refine your tasks as needed, and you can even if you are into that compute your velocity. Kanban also put a few sane rules like not starting too many things at the same time and focussing on finishing things.
Great thing with this simple setup is that tasks can be added/removed/changed priority at any time. As long as the task is not started, it doesn’t matter. If you change the backlog order 10 time a day, nobody care. You would of course still demo things to your stakeholder. Ideally on the go when the task is being accepted (and potentially going into pro just hours latter in the next release) or why not every few weeks.
What I think is overkill is to have fixed sprint with a commitment where there is this strange game and waste of time to try to fit as many tasks as possible in a fixed time period. If the team agree too easily, you get a team that may deliver a lot but is seen as bad because it doesn’t finish its sprints. On the opposite a lazy team that commit almost nothing would finish in advance and see as great on the methodology but disapoint anyway.
And usually what happen is the moment we all agreed on that commitment, priorities change and that sprint commiment is ready to go to the trash. And there always things that goes on top like somebody getting ill, one of the team member having to deal with an urgent bug in production that make the micro management of scrum wrong anyway.
Another problem with agile is that you are forced to use it. It is full of buzz word, it is the thing to do and it can only bring improvements. So people do it and fake it because they have no choice. If you have for example 3 small independant project for 3 people, 1 per person, they would put the 3 person together, have daily with the boss and call it “agile”. So that the percentage of people in agile is greater in the team and the team can fit its objective to have 80% of its member being in agile. This lead to lot of bad agile implementations by design. People use the tool and fake it so that everybody get happy.
Then the worst is maybe the mentoring/training. There a big market of certifications. You get certified in 2-3 day with trivial questions and can get renewed without a new exam but just sending money. Things like how to really split a complex task is never really solved as well as how to deal with the project as a whole.
Scrum/Agile is sold as universal while it solve only a specific part of the problem and that it become forced. That’s a real problem.
And ofc. Advertisement is the first thing I hear… Nope.
Sara says that goal of Agile is to make work repeatable, predictable and estimable. To me it’s exactly opposite: to manage work that is not repeatable, predictable or estimable. That is the value of programming. Turning it into repeatable, predictable and estimable “factory work” also makes it worthless.
Should have listened to the end. There is exact definition of Agile. It just may not be a definition you want:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.