I'm pretty ambivalent about it, because after 25 years of seeing methodologies come and go and come again with the same ideas wrapped in different names I believe projects that succeed, succeed in spite of the chosen methodology, rather than because of it.
From my experience I've found that scrumm holds back good, fast developers because they focus on only doing their share in a sprint, when they could rocket ahead and be pounding on the backlog.
How can you keep your best developers motivated and busy in an agile/scrumm environment?
Scrum focuses on "systemwide" optimization where the "system" is the development of an increment of a software product from concept to completion.
Letting a good developer "rocket ahead" optimizes for that developer (localized optimization) but not for the complete system (global optimization).
A more "global" optimization of that developer's time and energy, since they can do twice the work in half the time, is to mentor, support, teach, and otherwise spend their energy helping EVERYONE get to their level. Since they can and will get their "portion" of the work done quickly, they have bandwidth to add values in other ways as a force multiplier.
From my experience people like this end up in "lead" or "architect" roles.
Its helpful for all team members to be, as you put it, "competent and fast", its not absolutely necessary (in order for Scrum to work), and in a lot of companies, its not the case.
The purpose of Scrum is to highlight issues and bottlenecks in the 'system' so they can be addressed.
"Wide skill variances in team members skillsets" is one such problem, and a fairly common one. One remedy is to drop the dead weight, either through management/hr action or natural attrition. Another remedy is to upgrade the skills of the people who are "behind" using the people who are "ahead" as mentors.
Interesting trait of scrum - whenever there is scrum related discussion the no true Scotsman fallacies immediately pop up. By the way, scrum is actually a methodology to get something out of non-delivering teams. For everybody else it is just like throwing sand into their engine's cylinders.
I would agree with that. When a company brings me in, the first question I ask is "What is the problem you are trying to solve?"
Most of the problems that management think are because of the team are mostly (80%+) caused by people/processes/habits/cultural issues UPSTREAM of the team.
I think the problem with how agile is "sold" is that it is offered as a prepacked pack of tricks without going to its roots in the queing theory which gives a pretty good reason for a lot of stuff thus leaving the users of the methods partially deaf and blind. But any constraints for projects are better than none and there are worse things than scrum out there...
Agreed! I recommend reading "The Principles of Product Development Flow: Second Generation Lean Product Development" by Donald G. Reinertsen, which while not actually about Scrum, explains a lot of the useful underlying principles at work in Scrum -- like queueing theory.
The rocket ahead folks are often really good at creating technical debt for everyone else. The minority who are really rockets usually burn out early in their career. Used correctly, Agile prevents too much of either type from getting out of control, evening out the peaks and valleys. That's what you want, right? A sustainable pace.
Well said. I've never really looked at it from that perspective, tbh. But you're right, the sprint will keep effort at a sustained pace that the team accepts.
Scrumerfall adopted the term "sprint" so of course it's wrong. Before Scrum was much, we used the term "iteration" which is far more descriptive and truthful.
That's not a Scrum issue, it's shitty project management.
If the scope of a sprint is so far out of whack that fast developers are running out of work, then you're misestimating the complexity of deliverables. That sort of thing gets cleared up pretty quickly if it's being managed correctly.
From my corporate experience, retaining two types of developers on staff for the two different types of challenges is a good idea in general. At my current company, we have a dedicated scrumm team working on the really large projects and individual waterfall engineers cranking out special requests. We swap out engineers between the two groups so they can enjoy creating both types of work product.
The only downside to scrumm IMO is that some companies champion it like it's the only valid solution and waterfall is demonized somewhat. It seems to me the best organizational design is the one that takes into account all likely possibilities. Flexibility twists with the wind. Rigidity eventually cracks and collapses.
That's a general problem of cyclic development approaches instead of flow-based (kanban, etc.) approaches.
OTOH, depending on other aspects of the context, there may be organizational efficiencies from cyclic approaches that flow-based approaches don't realize.
Has it been the same cycle of cargo-culting management as well? I've only been in this game for 3 years, and the number of different labels for "Good Software Development" is already uncountable.
How can you keep your best developers motivated and busy in an agile/scrumm environment?