(no title)
struppi | 7 years ago
I wrote a whole book about "Agile Anti-Patterns" [3]. Most of the book's content is about things that many companies get wrong when they start with agile or lean software development. Because it is very easy to get those things wrong.
Yes, those problems are extremely common. Not only with Scrum - Organizations also face those problems when they try Kanban or SAFe or whatever. Because, change in a traditional organization is hard. And to really implement Scrum, you'd probably need to change more about the organization than the org was willing to change.
But those problems are not Scrum's fault. If the team has no power, it is also not truly self-organized. And the Scrum Master is not doing their job.
You could start to improve by creating awareness about the problems. Blaming Scrum may or may not be a good idea to do that - Because, some people in your org may be invested in Scrum. Some mentoring or coaching for your Scrum Masters, Product Owners and developers and managers might be a better start.
[1] https://www.davidtanzer.net/david%27s%20blog/2014/03/26/no-t...
[2] https://ronjeffries.com/articles/018-01ff/hills-to-die-on/
mindcrime|7 years ago
Bingo. That is the key point to me. Scrum, and other agile-family methodologies, are great when fully implemented. But what usually happens is that the higher-ups refuse to relinquish a bit of control, and stick tightly to their traditional command-and-control approach, and the dev teams are forced to do something that looks-kinda-like-scrum (or looks-kinda-like-XP or looks-kinda-like-AUP, etc.) while operating in a structure that isn't really compatible with the principles of Scrum, XP, AUP, etc.
Basically, we're forced to try and fit a round peg into a square hole because people higher up the org-chart either don't really understand agile-family methodologies or are actively opposed to truly implementing them.
Cakez0r|7 years ago
tannhaeuser|7 years ago
struppi|7 years ago
And there are other organizations who can make any agile method work for them.
So, it's not really Scrum's fault when it fails (at least not always). And it's not really (or not only) Scrum's achievement when it succeeds.
As a friend of mine, Samir Talwar, once said: "To be good at software development, you need an organization that's optimized for software development. Most organizations are optimized for something else."
Anyway, if you implement a process, but ignore even the very short (22 pages) guide that summarizes the process, but instead cherry-pick what you think will work well in your org, then don't blame the process when it does not work.
As I wrote in my book: "But changing Scrum so it works within your company will not make you more agile – It will make Scrum less agile!"
Cakez0r|7 years ago
srtjstjsj|7 years ago
ataturk|7 years ago