Scrum is fragile, not Agile
dennisweyland.net
Scrum is fragile, not Agile
1–10 of 329 posts
Re: Scrum is fragile, not Agile
#2Scrum is micromanagement. I think it’s as simple as that.
Re: Scrum is fragile, not Agile
#3At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue)
* Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, so nobody says much of importance, and just parrots what is already on the Jira board.
* Scrum master driving process above scrum. The scrum master's role is to make sure scrum rules are adhered to. But at this company, any deviation from scrum itself poses a threat to this person's job security, so it doesn't happen. More high-level processes are not optimized because the scrum master defines everything.
* Technical debt. I see this time and time again. User Stories are supposed to be forecasts, not commitments. But the business doesn't like stories carried over, so they become commitments. At the end of each sprint, everyone rushes to get their stuff done, and hacks are implemented to meet an arbitrary deadline. Many times I want to begin my work by refactoring something to what it needs to be first, then do the actual user story. But its risky because the refactoring might take more than the allocated story points, and you get dinged. So I do the story first, and if there is time do the refactoring but it almost never happens.
* Poor product owners. During maintenance phase, we could work on cleaning up technical debt, but this value is not appreciated by business so they keep us busy with bikeshedding. One gripe I have about scrum, is there is nobody representing engineering, as the product owner represents the business.
These things combined have dragged down the happiness of the people I work with, but we all feel imprisoned by it. I have a stack of scrum books here I plan on reading, I figure this process isn't going away and I need to up my game with how to play it - but I wish I could use something else, perhaps kanban.
Re: Scrum is fragile, not Agile
#4In my very surface-level, western understanding of Chinese philosophy, Agile seems very much like Taoism and Scrum is like Confucianism, in several ways.
The Agile Manifesto describes a set of ideals but gives no true set of instructions to follow, to do so would not be the Agile way. More than anything, it prescribes an attitude around which you should generally approach things.
Scrum conversely gives rules for how things can be organized and executed in a functional organization. It gives little room for flexibility. Any problems you have with Scrum, the first reaction should be "how are we following the rules wrong?".
Similarly, Tao and Agile are ideals for the individuals (and small teams), Confucianism and Scrum are rules for getting things to work functionally within a society/company.
Re: Scrum is fragile, not Agile
#5Re: Scrum is fragile, not Agile
#6In my very surface-level, western understanding of Chinese philosophy, Agile seems very much like Taoism and Scrum is like Confucianism, in several ways. The Agile Manifesto describes a set of ideals but gives no true set of instructions to follow, to do so would not be the Agile way. More than anything, it prescribes an attitude around which you should generally approach things. Scrum conversely gives rules for how…
The comparison may be very apt. After all, a key tenet of Taoism is that the Tao that can be told is not the eternal Tao. It may very well be that an Agile development process that can be fully specified and documented is not truly Agile.
Re: Scrum is fragile, not Agile
#7At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…
> Daily standup
I have never worked at a company where this actually goes right and could not be replaced by [insert ticketing system here]. We use Basecamp to do daily check-ins on a very high priority issue, if we have one, which we usually don't.
Re: Scrum is fragile, not Agile
#8At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…
> Daily standup I have never worked at a company where this actually goes right and could not be replaced by [insert ticketing system here]. We use Basecamp to do daily check-ins on a very high priority issue, if we have one, which we usually don't.
Managers are the only people that like daily standups, so far as I can tell.
I've never figured out why you couldn't just do it over slack or equivalent. It's massively inefficient to get everyone to meet up in the morning.
Re: Scrum is fragile, not Agile
#9At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…
Standups can have their use but I can't imagine a 20 person standup being useful. Why do you bring so many teams together for it?
Re: Scrum is fragile, not Agile
#10I don't really have that much industry experience but have been reading a lot about development processes and practices. It seems there just isn't one development process that will solve all your problems and allow you always create successful software. To me it seems you just need to find what works for your team and continuously work on improving on it. What might work today, probably won't work for your team tomorrow so you need to always look at how can you improve your process.
ACM recently had a series of webinars[0] by Ivar Jacobson on Essence[1]. Essence was kind of confusing at first, but it is essentially a language to describe practices from the different processes. The idea is that you can build up a library of the various practices in your company and allow teams to pick their own and evolve their process by swapping out practices that just don't work out. Essence seems like an interesting idea, especially if it allows teams to create a development process that fits them.