>Scrum was created by one of the creators of the agile manifesto as a way to see consulting/training around the 'Agile' idea (timeframes may differ a bit, but they were linked).
Scrum was actually created by two Japanese dudes [0], and was for the manufacturing industry.
Japanese also came up with Kaizen, which Scrum should be about but isn’t, along with Kanban, the process- not the generic term for workflow that some use it as.
While we’re on the topic of Agile, though, it’s best not to forget its eXtreme Programming roots.
XP for me is the core of agile software engineering I can relate to, principle driven rather than process focused a'la Scrum.
For me scrum optimises for a very narrow perspective of software development which did not align well with long term and sustainable software engineering and ownership. If i was far less than generous I'd say scrum is design for children rather than responsible adults.
For success as a leader i should be focusing on building and fostering a team than does not need the self imposed constraints of scrum but are rather conscientious and vested enough to build and deliver what the company needs and the team can maintain.
Scrum, for me, is not for development but for Operations, I don't even like the term scrum but simply WhiteBoard Meeting. Flatten structure, everyone knows what everyone else is doing, chance to mention things on one's mind, perhaps a hiccup from the day or shift before, not hosted by a ScrumMaster just rotate around the team, everyone has a voice, strict visible time limit.
It's super in Operations.. not super in Development.
Sprints make no sense at all. If you can do it you can do it. Stay at it and go on a spectrum of pumping consistent results to once in a blue moon creating something special. Sprint adds nothing to that other than a phrase to use in a conference call to hide ineffective working practices. I have Sprinted on a 35 hour working week, I have also worked normally on a 35 hour working week. Results are similar aside from stress others show where Sprint = Haste, and Haste != Speed or Quality.
Here here. Loved XP, still try to let it influence what I advocate for at my place of employ. XP leans heavy on discipline. It succeeds well when there's an environment of trust towards the team, and the team values discipline as a way of working better together.
Scrum is pretty lightweight. A lot of people add to the core of Scrum and refer to the whole thing as Scrum when that is not accurate. A few uber coders in a garage cranking out their dream idea may not need Scrum. In my experience, it’s most needed in the corporate world where there are tons of development teams being hounded by managers and product owners to constantly cram more and more work into a fixed amount of time left before some arbitrary deadline, and getting management buy-in on Scrum or something similar can actually be a much-needed protection for dev team sanity.
This sums up my thinking. Scrum is a contract between developers and managers, especially non-technical managers.
Developers have always complained about being micromanaged or being given business objectives that don't make sense or about changing requirements or some such. But non-technical managers at the same time typically complain that their developers are prima donnas and that their team produces unpredictable and non-repeatable results.
If you understand KPI's, you understand scrum. Scrum exposes the development process to managers and in theory is supposed to give them a better idea of what the team is doing, what they're having problems with, and what the consequences of their management directives are. If that leads to better management of the team, scrum is a success.
Yes, and Scrum done well can promote a sense of well-being through fulfillment of points and provides rhythmic but varying work for those that like process.
Done poorly it may create a wealth of problems. The cadence may create undue sense of urgency that may lead to unhealthy levels of stress or to depression and desensitization of missing work targets. Nonsense competition may arise due to points and velocities.
But Scrum reinforces all of that; arbitrary deadlines, sprints check; lack of control, product owner the only named role check; process centric, corporate compatibility check.
The achilles heel of Scrum is that it sold out the prescriptive XP practices that enforce sustainable software engineering discipline as well as communication with business concerns in order to sugar coat the fast feedback cycles. Scrum/Kanban feedback is about "doing the right thing". XP feedback is about "doing the thing right". Codebases on projects using Scrum/Kanban without XP technical practices tend to molder and succumb to what I like to call "Scrumrot" within about 18 months. Seen it happen many times.
I worked at a company where the CEO was into Kaizen and brought it up frequently at team meetings. It was otherwise as dysfunctional as any place I've ever worked. It was also my first, and hopefully last, exposure to "full court" Scrum. Both of these are now flags to me that a company is more into process than results, which is sad, because they both came from good places.
That article doesn't even create anything. It's a comparative summary of existing practices in the manufacturing sector. The word "scrum" appears, exactly once, as part of an incoherent rugby metaphor.
Elevating a waffling HBR feature to the status of antecedent decalogue is totally on brand for the clerical formalists that promote Scrum.
In high performance teams, Agile begins where Scrum ends, and as the remarks here extensively demonstrate, awful working environments won't be improved by a bunch of ceremonies.
Scrum was actually created by two Japanese dudes [0], and was for the manufacturing industry.
[0] https://en.wikipedia.org/wiki/Scrum_(software_development)#H...