Consider: My local chapter of the Project Management Institute has ~7000 members. Are the even 7000 competent people in the area that can act as leaf node workers for these folks? I doubt it.
Love the hands in the "all blockers" poster.
https://www.wittenburg.co.uk/Entry.aspx?id=99bb5987-e08d-4e8...
How can you keep your best developers motivated and busy in an agile/scrumm environment?
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.
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.
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.
OTOH, depending on other aspects of the context, there may be organizational efficiencies from cyclic approaches that flow-based approaches don't realize.
It assumes competence. If you are doing scrum with a team that has incompetent and slow developers, you will fail.
I guess the key, like anything else, is not overcommitting, not having interfering management. I suspect that applies to any PM methodology, though.
Personally I think agile is best thought of as a broad church of methodologies rather than anything concrete to adhere to, and especially I think the sprint approach isn't always suited to business needs.
But a generally agile approach I think is good, and I think daily stand-up meetings are good for communication even without sprints or a maintained backlog.
Either way, daily stand-ups are the worst thing about scrum especially when they are hijacked by PMs. I'm yet to meet a develop who'd look forward to stand-ups. I know they exist somewhere :-)
If you are curious about what other people (you don't talk to a lot) are working on then Hubot is a good solution. Hubot has a great plugin to let you share what you are working on without having to deal with stand-ups.
The one thing about stand ups that I find to be a profound waste of time is reporting what you've done. Isn't that what SVN / GIT / JIRA / etc is for?
SVN/GIT commit messages and Trello/JIRA notifications sent to Slack/Hipchat/YourInternalIrcServer are a great way to aggregate all that information. You can write a Hubot/YourOtherChatBot plugin to gather and summarize that information to make it even easier to track.
By the way, with Hubot you can just say "What everybody is working on?" and it will show you the status for everybody.
And if I had to pose as Scrum Master, every incentive would push me to intentionally propagate cultishness. (Better than those unaware they're doing it, because at least I can turn it off on a dime as the situation requires.)
Beside other failures, one of a major failures of scrum in real environment (not toy building fun exercise during a scrum course) is failure to address the multi-team environment of real multi-layered projects. A team would usually have dependencies and dependents. In scrum/sprint process a team would try to avoid committing to anything with unsatisfied dependencies which results in that any vertically dependent feature would take a series of sprints, much longer than in non-scrum environment. Add to that complete impossibility of iterations/adjustments on the feature - team A delivers to team B and team B has no chance (until a sprint much much later in the release, i.e. never) to have team A to do an additional iteration upon the delivered changes desired as a result of the actual usage by the team B. It is expectably much worse when it comes to 3 layers/teams (like persistence/framework, business logic, UI).
I specifically asked consultants (during 2 different courses by 2 different consulting companies and at work) about dependencies management in scrum, and blank-facing was their answer. Think about it - software development methodology without addressing inter-component/layer/team dependencies.
If you are using a externally-defined methodology rather than driving your methodology based on continuous objective review of what works and does not work for your organization, you are neither agile nor lean, just cargo culting.
