8 ms·

Mind the Burndown, Comrade – Scrum Propaganda Posters

32 points by alwaysunday 12y ago

Spearchucker 12y ago
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. https://www.wittenburg.co.uk/Entry.aspx?id=99bb5987-e08d-4e81-974d-daa5e07c0d5f https://www.wittenburg.co.uk/Entry.aspx?id=99bb5987-e08d-4e8...
- marktangotango 12y ago
  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?
  - fsloth 12y ago
    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...
    - calibraxis 12y ago
      You make vital points which should be highlighted. One subtlety of Scrum is that it resets a queue at the end of each sprint. More info on queues and software dev: http://agile-jitsu.blogspot.de/2013/07/don-reinertsens-talk-on-flow-to-limited.html http://agile-jitsu.blogspot.de/2013/07/don-reinertsens-talk-...
    - mjbellantoni 12y ago
      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.
  - FrankenPC 12y ago
    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.
  - tirrellp 12y ago
    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. http://www.payton-consulting.com http://www.payton-consulting.com
    - marktangotango 12y ago
      This makes perfect sense to me given the constraints of working in a mandated scrum environment, thanks. Not sure why you're being downvoted?
      - tirrellp 12y ago
        Thats how it goes I guess *shrug
    - mempko 12y ago
      Scrum requires that all team members are already competent and fast. Don't let this consulting company fool you.
      - trhway 12y ago
        >"Scrum requires that ..." 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.
        tirrellp 12y ago
  - ErikRogneby 12y ago
    change to kanban and let them pound away.
  - nickbauman 12y ago
    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.
    - blazespin 12y ago
      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.
      - kylequest 12y ago
        It's funny to see "sprint" and "sustained pace" used together. In a normal/regular life you have one or the other :-)
        nickbauman 12y ago
        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.
  - mempko 12y ago
    Scrum has, as a prerequisite that all your developers are already competent and fast. It assumes competence. If you are doing scrum with a team that has incompetent and slow developers, you will fail.
  - matthewmacleod 12y ago
    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.
    - marktangotango 12y ago
      What i see is not that work runs out, but the best developers on the team throttles their effort lower, so as not todo too much extra work.
  - dragonwriter 12y ago
    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.
- fein 12y ago
  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.
- deleted 12y ago
  [deleted]
eterm 12y ago
I can't tell if these are mocking or not? (Even down to capitalisation of SCRUM). 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.
- kylequest 12y ago
  It's a pretty big fail when people wait until the daily stand-up to communicate. It's better than not communicating at all, of course :-) 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.
  - silverbax88 12y ago
    I use some aspects of Scrum; but when a development team starts using a daily stand up meeting, you've effectively taken IT and turned into into a charade of nonsense.
  - blazespin 12y ago
    There are different types of communication. Some things need to be communicated to the whole team, something you don't want to be doing more than once a day. 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?
    - kylequest 12y ago
      Sadly most of the time stand-ups turn into glorified status reports for managers/PMs :-( Stand-ups are meant for developers (carried out for developers by developers). If devs don't get enough value out of them (to offset the "distraction factor" they introduce) they shouldn't exist. 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.
fsloth 12y ago
Philosophically I find it hilarious these posters supporting a particular agile flavor are using the style of the ultimate waterfall command and control system which certainly was not based on reciprocal communication and immediate feedback loops :D Love the hands in the "all blockers" poster.
nickbauman 12y ago
Agile works as a bottom-up methodology only. Once the PMs get a hold of it, they figure out a way to wire their TPS-report-"did you get the memo on that? It needs a cover sheet."-thinking into it so that it's effectively destroyed. Scrum is the goto agile methodology for these people to wreck, and wreck it they have. 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.
faragon 12y ago
Agile methodology reminds me Asimov's "Reason" (short story), in this case, poor management methods masking the whip behind a ridiculous religion/faith plus some "gamification".
- mempko 12y ago
  Scrum comes before "Agile" was invented. Scrum has more connections with lean. But scrum is agile too.
  - faragon 12y ago
    s/Agile/Scrum/g
    - mempko 12y ago
      Agile manifesto was published in 2001? Notices I am using a capital A here.
  - dragonwriter 12y ago
    Scrum is neither agile nor lean, though its possible for an organization following agile or lean principles to adopt Scrum (as a starting point.) 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.
- derriz 12y ago
  The whole agile/scrum "movement" should be simply amusing and provide endless inspiration for humor and satire. Unfortunately it has gathered enough wide-eyed zealous adherents that it has become scary. Religion/faith indeed; a smug disinterest in empiricism, a rejection of decades of scientific research into complex project management and delight in juvenile revolutionary imagery.
trhway 12y ago
after a year and half of thorough, to the letter, BigCo company-wide (only super important/critical projects were excepted :) push of Scrum/Agile/Lean down our throats and as result, in particular, work on our complex multi-team project slowing down to a crawl and failing to release while everybody was super busy with their mouths foaming and not being able to catch a breath, about a year ago everybody in our BigCo almost instantly forgot these words and about associated reports/tools/meetings/bla-bla-bla - Christmas magic i guess. The only thing reminding that it wasn't just a nightmare dream, that it was real is that our team's weekly status meeting is called "scrum meeting" :) 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.
matthewmacleod 12y ago
I appear to be in the minority as an engineer who rather enjoys Scrum – we've been delivering working features to customers at a steady pace; they've been involved in the feedback process; we've managed to improve the process through the retrospectives; the burndown charts etc. have been useful in understanding where bottlenecks are. I guess the key, like anything else, is not overcommitting, not having interfering management. I suspect that applies to any PM methodology, though.

32 points by alwaysunday 12y ago

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. https://www.wittenburg.co.uk/Entry.aspx?id=99bb5987-e08d-4e81-974d-daa5e07c0d5f https://www.wittenburg.co.uk/Entry.aspx?id=99bb5987-e08d-4e8...

marktangotango 12y ago
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?
- fsloth 12y ago
  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...
  - calibraxis 12y ago
    You make vital points which should be highlighted. One subtlety of Scrum is that it resets a queue at the end of each sprint. More info on queues and software dev: http://agile-jitsu.blogspot.de/2013/07/don-reinertsens-talk-on-flow-to-limited.html http://agile-jitsu.blogspot.de/2013/07/don-reinertsens-talk-...
  - mjbellantoni 12y ago
    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.
- FrankenPC 12y ago
  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.
- tirrellp 12y ago
  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. http://www.payton-consulting.com http://www.payton-consulting.com
  - marktangotango 12y ago
    This makes perfect sense to me given the constraints of working in a mandated scrum environment, thanks. Not sure why you're being downvoted?
    - tirrellp 12y ago
      Thats how it goes I guess *shrug
  - mempko 12y ago
    Scrum requires that all team members are already competent and fast. Don't let this consulting company fool you.
    - trhway 12y ago
      >"Scrum requires that ..." 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.
      - tirrellp 12y ago
- ErikRogneby 12y ago
  change to kanban and let them pound away.
- nickbauman 12y ago
  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.
  - blazespin 12y ago
    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.
    - kylequest 12y ago
      It's funny to see "sprint" and "sustained pace" used together. In a normal/regular life you have one or the other :-)
      - nickbauman 12y ago
        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.
- mempko 12y ago
  Scrum has, as a prerequisite that all your developers are already competent and fast. It assumes competence. If you are doing scrum with a team that has incompetent and slow developers, you will fail.
- matthewmacleod 12y ago
  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.
  - marktangotango 12y ago
    What i see is not that work runs out, but the best developers on the team throttles their effort lower, so as not todo too much extra work.
- dragonwriter 12y ago
  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.
fein 12y ago
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.
deleted 12y ago
[deleted]

eterm 12y ago

I can't tell if these are mocking or not? (Even down to capitalisation of SCRUM). 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.

kylequest 12y ago
It's a pretty big fail when people wait until the daily stand-up to communicate. It's better than not communicating at all, of course :-) 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.
- silverbax88 12y ago
  I use some aspects of Scrum; but when a development team starts using a daily stand up meeting, you've effectively taken IT and turned into into a charade of nonsense.
- blazespin 12y ago
  There are different types of communication. Some things need to be communicated to the whole team, something you don't want to be doing more than once a day. 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?
  - kylequest 12y ago
    Sadly most of the time stand-ups turn into glorified status reports for managers/PMs :-( Stand-ups are meant for developers (carried out for developers by developers). If devs don't get enough value out of them (to offset the "distraction factor" they introduce) they shouldn't exist. 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.

fsloth 12y ago

Philosophically I find it hilarious these posters supporting a particular agile flavor are using the style of the ultimate waterfall command and control system which certainly was not based on reciprocal communication and immediate feedback loops :D Love the hands in the "all blockers" poster.

nickbauman 12y ago

Agile works as a bottom-up methodology only. Once the PMs get a hold of it, they figure out a way to wire their TPS-report-"did you get the memo on that? It needs a cover sheet."-thinking into it so that it's effectively destroyed. Scrum is the goto agile methodology for these people to wreck, and wreck it they have. 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.

faragon 12y ago

Agile methodology reminds me Asimov's "Reason" (short story), in this case, poor management methods masking the whip behind a ridiculous religion/faith plus some "gamification".

mempko 12y ago
Scrum comes before "Agile" was invented. Scrum has more connections with lean. But scrum is agile too.
- faragon 12y ago
  s/Agile/Scrum/g
  - mempko 12y ago
    Agile manifesto was published in 2001? Notices I am using a capital A here.
- dragonwriter 12y ago
  Scrum is neither agile nor lean, though its possible for an organization following agile or lean principles to adopt Scrum (as a starting point.) 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.
derriz 12y ago
The whole agile/scrum "movement" should be simply amusing and provide endless inspiration for humor and satire. Unfortunately it has gathered enough wide-eyed zealous adherents that it has become scary. Religion/faith indeed; a smug disinterest in empiricism, a rejection of decades of scientific research into complex project management and delight in juvenile revolutionary imagery.

trhway 12y ago

after a year and half of thorough, to the letter, BigCo company-wide (only super important/critical projects were excepted :) push of Scrum/Agile/Lean down our throats and as result, in particular, work on our complex multi-team project slowing down to a crawl and failing to release while everybody was super busy with their mouths foaming and not being able to catch a breath, about a year ago everybody in our BigCo almost instantly forgot these words and about associated reports/tools/meetings/bla-bla-bla - Christmas magic i guess. The only thing reminding that it wasn't just a nightmare dream, that it was real is that our team's weekly status meeting is called "scrum meeting" :) 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.

matthewmacleod 12y ago

I appear to be in the minority as an engineer who rather enjoys Scrum – we've been delivering working features to customers at a steady pace; they've been involved in the feedback process; we've managed to improve the process through the retrospectives; the burndown charts etc. have been useful in understanding where bottlenecks are. I guess the key, like anything else, is not overcommitting, not having interfering management. I suspect that applies to any PM methodology, though.