1. 40
  1.  

  2. 5

    Very strong opinions here…

    As far as I’m concerned, strong scrum practices would defeat these issues.

    Bad tools are not scrum. Lack of ownership is not scrum.

    People who try to use scrum as a way to wrap a process around bad ideas will never benefit from it.

    Take the good ideas, apply scrum, and most importantly, adapt to what you learn.

    1. 38

      adapt to what you learn.

      Umm. Point 5 and 6 of TFA?

      I’ve learnt from seeing it in practice both in my own experience and speaking to many others… The article is pretty spot on.

      Ok. Warning. Incoming Rant. Not aimed at you personally, you’re just an innocent bystander, Not for sensitive stomachs.

      Yes, some teams do OK on Scrum (all such teams I have observed, ignore largish chunks of it). ie. Are not doing certified scrum.

      No team I have observed, have done as well as they could have, if they had used a lighter weight process.

      Many teams have done astonishingly Badly, while doing perfect certified Scrum, hitting every Toxic stereotype the software industry holds.

      Sigh.

      I remember the advent of “Agile” in the form of Extreme Programming.

      Apart from the name, XP was nearly spot on in terms of a light weight, highly productive process.

      Then Kanban came.

      And that was actually good.

      Then Scrum came.

      Oh my.

      What a great leap backwards that was.

      Scrum takes pretty much all the concepts that existed in XP…. and ignores all the bits that made it work (refactoring, pair programming, test driven development, …), and piles on stuff that slows everything down.

      The thing that really pisses me off about Scrum, is the amount of Pseudo Planning that goes on in many teams.

      Now planning is not magic. It’s simply a very data intensive exercise in probabilistic modelling.

      You can tell if someone is really serious about planning, they track leave schedules and team size changes and have probability distributions for everything and know how to combine them, and update their predictions daily.

      The output of a real plan is a regularly updated probability distribution, not a date.

      You can tell a work place bully by the fact their plans never change, even when a team member goes off sick.

      In some teams I have spoken to, Scrum planning is just plain unvarnished workplace bullying by powertripping scrum managers, who coerce “heroes” to work massive amounts of unpaid overtime, creating warm steaming mounds of, err, “technical debt”, to meet sprint deadlines that were pure fantasy to start with.

      Yes, if I sound angry I am.

      I have seen Pure Scrum Certified and Blessed Scrum used to hurt people I care about.

      I have seen Good ideas like Refactoring and clean code get strangled by fantasy deadlines.

      The very name “sprint “ is a clue as to what is wrong.

      One of the core ideas of XP was “Sustainable Pace”…. which is exactly what a sprint isn’t.

      Seriously, the one and only point of Agile really is the following.

      If being able to change rapidly to meet new demands has high business value, then we need to adapt our processes, practices and designs to be able to change easily.

      Somehow that driving motivation has been buried under meetings.

      1. 8

        I 100% agree with you actually.

        I suppose my inexperience with “real certified scrum” is actually the issue.

        I think it’s perfectly fine and possible to take plays out of every playbook you’ve mentioned and keep the good, toss the bad.

        I also love the idea that every output of planning should be a probabilistic model.

        Anyone who gets married to the process they pick is going to suffer.

        Instead, use the definitions to create commonly shared language, and find the pieces that work. For some people, “sprint” works. For others, pair programming is a must have.

        I think adhering to any single ideology 100% is less like productivity and more like cultish religion.

        1. 5

          fantasy deadlines

          Haha. Deadlines suck so let’s have em every 2 weeks!

          1. 3

            As they say in the XP world: if it hurts, do it more often.

            1. 3

              True. It’s a good idea. One step build pipeline all the way to deployment. An excellent thing, all the pain is automated away.

              If you planned it soundly, then a miss is feedback to improve your planning. As I say, planning is a data intensive modelling exercise. If you don’t collect the data, don’t feed it back into your model… your plans will never improve.

              If it was pseudo planning and a fantasy deadline and the only thing you do is bitch at your team for missing the deadline… it’s workplace bullying and doing it more will hurt more and you get a learned helplessness response.

        2. 12

          Warning: plain talk ahead, skip this if you’re a sensitve type. Scrum can actually work pretty well with mediocre teams and mediocre organizations. Hint we’re mostly all mediocre. This article wreaks of entitlement; I’m a special snowflake, let ME build the product with the features I want! Another hint; no one wants this. Outside of really great teams and great developers, which by definition most of us aren’t, you are not capable.

          Because all product decision authority rests with the “Product Owner”, Scrum disallows engineers from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction.

          This the best thing about scrum/agile imo. Getting someone higher in the food chain to gatekeep what comes into development and prioritize what is actually needed is a huge benefit to every developer wether you realize it or not. If you’ve never worked in a shop where Sales, Marketing and Support all call their pet developers to work on 10 hair on fire bullshit tasks a day, then you’ve been fortunate.

          1. 9

            Scrum can actually work pretty well with mediocre teams and mediocre organizations. Hint we’re mostly all mediocre.

            The problem is: Scrum also keeps people mediocre.

            Even brilliant people are mediocre, most of the time, when they start a new thing. Also, you don’t have to be a genius to excel at something. A work ethic and time do the trick.

            That said, Scrum, because it assumes engineers are disorganized, talentless children, tends to be a self-fulfilling prophecy. There’s no mentorship in a Scrum shop, no allowance for self-improvement, and no exit strategy. It isn’t “This is what you’ll do until you earn your wings” but “You have to do this because you’re only a developer, and if you were good for anything, you’d be a manager by now.”

            1. 3

              That said, Scrum, because it assumes engineers are disorganized, talentless children, tends to be a self-fulfilling prophecy.

              Inverting the cause and effect here is an equally valid argument, that most developers in fact are disorganinzed, talentless children as you say, and the sibling comment highlights. We are hi-jacking the “Engineer” prestige and legal status, with none of the related responsibility or authority.

              There’s no mentorship in a Scrum shop, no allowance for self-improvement, and no exit strategy.

              Is there mentoring and clear career paths in none scrum shops? This isn’t a scrum related issue. But regardless, anyone who is counting on the Company for self actualization is misguided. At the end of the day, no matter how much we would all like to think that our contributions matter, they really don’t. To the Company, we’re all just cogs in the machine. Better to make peace with that and find fulfillment elsewhere.

              1. 3

                Scrum does not assume “engineers” at all. It assumes “developers”. Engineers are highly trained group of legally and ethically responsible professionals. Agile takes the responsibility of being an engineer right out of our hands.

                1. 4

                  Engineers are highly trained group of legally and ethically responsible professionals.

                  I love this definition. I have always said there’s no such thing as a software engineer. Here’s a fantastic reason why. Computer programmers may think of themselves as engineers, but we have no legal responsibilities nor ethical code that I am aware. Anyone can claim to be a “software engineer” with no definition of what that means and no legal recourse for liars. It requires no experience, no formal education, and no certification.

                  1. 1

                    True, but why?

                    IMHO, because our field is in its infancy.

                    1. 2

                      I dislike this reason constantly being thrown around. Software engineering has existed for half a century, name another disipline where unregulated work and constantly broken products are allowed to exist for that long. Imagine if nuclear engineering was like us. I think the real reason we do not get regulated is majority of our field does not need rigor and companies would like a lower salary for engineers, not higher. John Doe the web dev does not need the equalivalent of a engineering stamp each time he pushes to production because his work is unlikely to be a critical system where lives are at stake.

                      1. 1

                        I’m pretty sure that most human disciplines date in the thousands years.

                        Nuclear engineering (that is well rooted in chemistry and physics) is still in its infancy too, as both Chernobyl and Fukushima show pretty well.

                        But I’m pretty sure that you will agree with me that good engineering take a few generations if you compare these buildings with this one.

                        The total lack of historical perspective in modern “software engineers” is just another proof of the infancy of our discipline: we have to address our shortsighted arrogance as soon as possible.

                        1. 1

                          We’re talking about two different things. How mature a field is not a major factor in regulation. Yes I agree with your general attitude that things get better over time and we may not be at that point. But we’re talking about government regulating the supply of software engineers. That decision has more to do with public interests then how good software can be.

                          1. 1

                            That decision has more to do with public interests then how good software can be.

                            I’m not sure if I agree.

                            In my own opinion current mainstream software is so primitive that anybody could successful disrupt it.

                            So I agree that software engineers should feel much more politically responsible for their own work, but I’m not sure if we can afford to disincentivate people to reinvent the wheel, because our current wheels are triangular.

                            And… I’m completely self-taught.

              2. 3

                This the best thing about scrum/agile imo. Getting someone higher in the food chain to gatekeep what comes into development and prioritize what is actually needed is a huge benefit to every developer wether you realize it or not.

                While I agree with the idea of this, you did point out that this works well with mediocre teams and, IME, this gatekeeping is destructive when you have a mediocre gatekeeper. I’ve been in multiple teams where priorities shift every week because whoever is supposed to have a vision has none, etc. I’m not saying scrum is bad (I am not a big fan of it) but just that if you’re explicitly targeting mediocre groups, partitioning of responsibility like this requires someone up top who is not mediocre. Again, IME.

                1. 2

                  Absolutely, and the main benefit for development is the shift of blame and responsibility to that higher level, again, if done right. Ie there has to be a ‘paper trail’ to reflect the churn. This is were jira (or whatever ticketing system) helps, showing/proving scope change to anyone who cares to look.

                  Any organization that requires this level of CYA (covery your ass) is not worth contributing to. Leeching off of, sure :)

                  1. 2

                    So are you saying that scrum is good or that scrum is good in an organization that you want to leech off of?

                    1. 1

                      I was referring to the case the gp proposed where the gatekeeper themselves are mediocre and/or incompetent, and in the case scape goats are sought, the agile artifacts can be used to effectively shield development, IF they’re available. In this type of pathological organization, leeching may be the best tactic, IMO. Sorry that wasn’t clear.

                2. 3

                  I’m in favour of having a product owner.

                  XP had one step better “Onsite Customer” ie. You could get up from your desk and go ask the guy with the gold what he’d pay more gold for and how much.

                  A product owner is a proxy for that (and prone to all the ill’s proxies are prone to).

                  Where I note things go very wrong, is if the product owner ego inflates to thinking he is perhaps project manager, and then team lead as well and then technical lead rolled into one god like package…. Trouble is brewing.

                  Where a product owner can be very useful is in deciding on trade offs.

                  All engineering is about trade offs. I can always spec a larger machine, a more expensive part, invest in decades of algorithm research… make this bigger or that smaller…

                  • But what will a real live gold paying customer pay for?
                  • What will they pay more for? This or That? And why? And how much confidence do you have? Educated guess? Or hard figures? (ps: I don’t sneer at educated guesses, they can be the best one has available… but it gives a clue to the level of risk to know it’s one.)
                  • What will create the most re-occurring revenue soonest?
                  • What do the customers in the field care about?
                  • How are they using this system?
                  • What is the roadmap we’re on? Some trade offs I will make in delivering today, will block some forks in the road tomorrow.

                  Then there is a sadly misguided notion, technical debt.

                  If he is wearing a project manager hat, there is no tomorrow, there is only The Deadline, a project never has to pay back debt to be declared a success.

                  If he is wearing a customers hat, there is no technical debt, if it works, ship it!

                  Since he never looks at the code….. he never sees what monsters he is spawning.

                  The other blind spot a Product Owner has is about what is possible. He can only see what the customers ask for, and what the competition has, or the odd gap in our current offering.

                  He cannot know what is now technologically feasible. He cannot know what is technologically desirable. So engineers need wriggle room to show him what can or should be done.

                  But given all that, a good product owner is probably worth his weight in gold. A Bad One will sink the project without any trace, beyond a slick of burnt out and broken engineers.

              3. 5

                The valuable thing about scrum is, that it gets everyone involved into a conversation in regular intervals. Other than that, everything else is still about people, … both, for good and for bad.

                1. 12

                  And the scrum guide, linked in TFA, even makes that clear. Unfortunately people who practise scrum do not make that clear, and use the Scrum meetings and artefacts to centralise responsibility and hide behind a process.

                  It seems that Scrum belongs in a category with Agile, Object-Oriented Programming, BDD and others[*] where the thing as-described is hard and has lots of value once you’ve mastered it, the thing as-practised is easy but has little value, but has the same name so lets you claim to be doing the hard-and-valuable thing. Eventually everybody notices that the easy-but-worthless thing is not helping, so claims that the thing never had any value and reject it.

                  Scrum-as-described is a baseline process, along with a process improvement framework for a self-organising team to frequently adapt the process to meet their particular needs. Unfortunately, self-organisation and process improvement are difficult skills that are not quickly mastered. Therefore Scrum-as-practised is introduced. Scrum-as-practised is the baseline process forever, with decisions made unilaterally by the product owner, daily status meetings, and fortnightly blame games. Scrum-as-practised is not very useful[**], therefore Scrum is bad.

                  [*] I would include Free Software, except that Free-Software-as-practised goes by the distinct name Open Source.

                  [**] Even Scrum-as-practised is useful in many contexts. It provides a safe (pun intended) way for a legacy business to approach an “agile transformation” without completely disrupting middle management and the project office, nor the existing technical functions that have grown a culture expecting those things to exist. When you’ve worked on the “here’s the list of features, see you in 18 months” project, fortnightly releases and a guidebook on how to achieve them really are beneficial.

                2. 5
                  1. Because all product decision authority rests with the “Product Owner”, Scrum disallows engineers from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction.

                  i.e. the product has a clear owner, and you build the thing that customers want rather than the thing that engineers want.

                  2-3,9, most of 11: true, and these things result in better software.

                  This lack of ownership results in: Poor design Lack of motivation (“It isn’t my thing”, “It was broken when I start working on it”)

                  That’s the opposite of my experience. Lack of ownership means I don’t need anyone’s permission to improve code I’m working on, and means the design can be evolved by the people actually working on it, leading to better design.

                  5-7, 14: not my experience.

                  8, 12: don’t do that then.

                  Do managers or Product Owners track and estimate every task they engage in

                  Track and estimate tasks? No, because those are reactive positions - QA folk or people on support duties this week don’t estimate either. The point of estimating is to be able to make prioritisation decisions, so it only really applies when there’s a

                  with little or no say in what they work on?

                  Yes? Managers and owners are expected to solve everything people bring to them, they don’t get any chocie.

                  Are they required to present burn down charts that show that they are on target to finish?

                  No, nor are developers.

                  Are they required to do bi-weekly sell-off meeting to justify their activities?

                  No, again like QA or support people.

                  13, 14: no actual argument to justify those claims, not my experience.

                  1. Scrum ignores the fact that any task that has been done before in software does not need to be redone because it can be easily copied and reused. So, by definition, new software tasks are truly new territory and therefore very hard to estimate.

                  Disagree. Scrum does everything reasonably possible to acknowledge that estimation is hard: estimating in officially meaningless points, daily standups to give you an assessment point to realise if a task is diverging from its estimate and reasses if need be. At the same time, ultimately you do want some way to have engineering estimates feed into task prioritization decisions - you need some minimal level of estimation to be able to make the “do I do task A or task B or task C this week” decision. Scrum accomplishes that better than anything else I’ve seen.

                  1. 6

                    i.e. the product has a clear owner, and you build the thing that customers want rather than the thing that engineers want.

                    It’s amazing to me how much bellyaching I hear over this. At $DAYJOB I have people coming to me all the time trying to figure out how to get their priorities done vs what the product owners want …why do you have priorities? Are you paid to build a product or to play with your toys?

                    1. 3

                      Maybe… don’t look at your colleagues like children who don’t want to do work and would rather play with their toys. Maybe look at them like adults who are invested in the product in their own way. Maybe you’d understand them better then.

                    2. 5

                      Disagree. Scrum does everything reasonably possible to acknowledge that estimation is hard: estimating in officially meaningless points

                      In theory this is true. In practice every single time I’ve seen or used scrum the points have devolved into a meaningful value instead. You can shout as loudly as you want that this is not doing scrum right but human nature says that doesn’t matter. We will inevitably assign a real metric to the points before too many sprints happen. We’ll treat them as time to ship, an estimate of effort required, complexity of problem. It’s pretty much inescapable that this will happen.

                      1. 1

                        I don’t disagree as such. The way I look at it is: given that we want to feed some level of engineering cost estimate into the planning process, what’s the cheapest/least damaging form of estimation we can do that will suffice for making prioritisation decisions?

                        From this perspective points are a small, incremental improvement over estimating in terms of e.g. programmer-days: they blunt some of the sting of “I only got 2 days’ worth of work done this week”, they make it a little less awkward that Bob gets 25% more done than Jim. They make it a little harder for a manager to breathe down your neck with “you estimated this as 3 days, it’s now 4 days since you started, why isn’t it done?”

                        They’re not infallible on any of these aspects, but they’re a little better than using a “real” metric directly. The fact that they’re officially meaningless give you a tool to push back with if people start to misuse them.

                        1. 1

                          They make it a little harder for a manager to breathe down your neck with “you estimated this as 3 days, it’s now 4 days since you started, why isn’t it done?”

                          This sound funny to me, because I’m pretty good at estimating long and complex tasks.

                          My average error is around 2%, but the bigger the task the more precise is the estimate.
                          It’s not magic, it’s just that for bigger tasks managers give me more time to explore the matter. And I’m talking about project that requires small (3-7) to medium (10-20) sized teams.

                          What’s funny?

                          Most of managers (that is all non technical ones, except one) prefer a small estimate than a precise one.
                          They fight back a lot. My usual answer is: “Why did you asked me? Write the numbers you like!”

                          In one case, some years ago, one did. Guess what happened?

                          1. 1

                            My average error is around 2%, but the bigger the task the more precise is the estimate. It’s not magic, it’s just that for bigger tasks managers give me more time to explore the matter.

                            Either there’s some “magic” you’re not mentioning, or you’re working in a very strange field for software. As the article puts it:

                            any task that has been done before in software does not need to be redone because it can be easily copied and reused. So, by definition, new software tasks are truly new territory and therefore very hard to estimate.

                            Certainly I’ve watched teams put a lot of time and effort into “exploring” and estimating, and come up with numbers that turned out to be orders of magnitude out. So it’s not as simple for ordinary programmers as just “spend some time on it”.

                            1. 1

                              No magic, really.

                              You just need twenty years of experience in a lot of different projects (with several different stacks), good tools (that I design for my own team) and enough informations.

                              The only “strange” thing is that we work for big banks.

                              1. 1

                                Well, bully for you, but most working programmers don’t have twenty years of experience, and in most fields you never have “enough” information. (I’m not surprised that projects in big banks would be unusually predictable, but that doesn’t help the rest of us).

                    3. 8

                      Scrum may be the illness; it is more likely an expression of a deeper problem that may be inextricable. Either way, it has pushed more experienced, excellent developers out of the industry than I care to count.

                      Software is the only industry in the world where people above IQ 120 with 5 years of experience (even well above 120, and well above 5 years) have to justify days and weeks– hell, sometimes even hours– of their own working time. No one capable will tolerate that if she can get something else. Scrum is a great way to end up with the Dead Sea Effect.

                      I call Scrum the Whisky Goggles of programming. It turns the unemployable 3’s into marginally employable 5’s, but the 6+ see you as a foolish, dangerous drunk and want nothing to do with you.

                      I also doubt that it will change. It works well enough to get to the next round of funding. Hiring massive armies of mediocre programmers has become “the way it’s done”. Now it’s reminiscent of “Nobody ever got fired for buying IBM.”

                      Those of us in the top ~5 percent, we had our time. It seems to be over, at least in this industry. Some of us will reinvent ourselves as “data scientists” and hope to escape the hell of burndown story points and product “individuals”; some of us will go back to graduate school and either escape into academia or vie for the few remaining R&D jobs that Scrum can’t touch; many of us will just leave and do something else.

                      1. 4

                        I’m going to let out a big secret that I probably shouldn’t about Scrum. I’m going to quote one of your recent posts on medium because I think it is relevant.

                        The one thing that universally turns up when people investigate workplace violence is… not race, not mental health, not disputes with co-workers or management, but exactly that type of “performance management”, which is the euphemism for this sort of psychotic, evil surveillance capitalism. It literally drives people nuts.

                        Where are the managers in Scrum? The answer, there aren’t any. Scrum is sold to businesses as a technique to exponentially increase productivity. However, the this is a lie, a foot in the door technique. The reason the other 95% of IT workers like it is that Scrum is a worker emancipatory movement. No more managers, no more long hours, no more abuse, no more performance management.

                        Scrum is not meant to protect the gifted 5% of engineers who worked privileged environments, who never deal with the kind of abuse other 95% of IT workers have to. It’s was never designed to make life easier for those that already have an easy life. Scrum isn’t meant for the already privileged 5%.

                        You mention high IQ like it’s a good thing. In the words of Alan Kay, high IQ is a lead weight, your viewpoint is everything.

                        1. 6

                          Software is the only industry in the world where people above IQ 120 with 5 years of experience (even well above 120, and well above 5 years) have to justify days and weeks– hell, sometimes even hours– of their own working time

                          That’s … not true at all. If you look at jobs done by actual engineers, you’ll see that they routinely have to provide time estimates. In order to make those time estimates, they have to estimate their work to the day and week, even if those detailed timelines aren’t provided to their clients. Even newly-licensed engineers already have 4 or more years of experience, since work requirements are part of the license process. Most people who are engineers have high IQ, because they’re complicated technical fields with nontrivial education requirements. And they all must pass an exam on engineering ethics.

                          And they provide time, labor, and cost estimates to clients.

                          Which is much like what we do in software development. We put together estimates in as detailed a way as we can, to provide an overall plan. We tell our customers the overall plan, and we track against our detailed plan so we know if we have to tell the customer the plans have changed.

                          Actual engineers are currently far better as an industry at providing those types of estimates. If we ever want to mature as an industry, we must improve our ability to estimate our work.

                          Claiming that we’re above the need to estimate because we’re smart and we have experience misunderstands the need. Being smart and having experience should make us more comfortable and confident providing estimates, rather than less comfortable even being asked.

                        2. 4

                          This should instead be titled “Scrum alone won’t fix your toxic work environment”. Processes and software can’t fix conflict though they can help you manage it, but you have to actually try to manage the conflict. The first line screams of completely unmanaged conflict.

                          “Because all product decision authority rests with the “Product Owner”, Scrum disallows engineers from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction.”.

                          Their response The nature of computer programming basically aims for eschewing process as much as possible

                          “The lightest, leanest process you can get away with is always best — and you will be amazed how very little process you really need.”

                          I think the author doesn’t really understand conflict, doesn’t really understand processes and thinks that if you get rid of processes that the conflict will magically resolve.

                          1. 3

                            For me personally, usage of Scrum on a project is a red flag, and I will try to avoid the project if I can. The existence of worse modes of work (which I also avoid) only constitutes an argument in favor of Scrum if they actually are the only alternatives.

                            To elaborate - from my perspective, Scrum feels

                            • disrespectful toward developers
                            • like a waste of time in terms of personal development and
                            • a step away from impact & responsibility
                            • overhead that makes me slower and less motivated

                            Perhaps that’s all a result of “doing it wrong”. For communication purposes, however, Scrum-the-formally-defined-process is much less relevant than Scrum-as-it-is-implemented. For me, the term is already tainted enough that I would actively avoid associating myself with it in any way.

                            1. 1

                              FWIW: my experience of Scrum-as-implemented has been very positive.

                              I don’t really get the “disrespect” narrative; for me the most fulfilling thing, the thing that makes me feel impact and responsibility, and the best for my “personal development” (to the extent that I understand the concept at all) is to have contact with a customer that I’m solving problems for.

                              Scrum has struck the best balance I’ve found between overhead and effectiveness; the overhead is not zero but it’s less than any other formal process I’ve seen applied unless we count Kanban (which is essentially Scrum without the iterations, and I found lead to endless indefinitely-scoped “do the thing” tasks where it was easy to get lost doing nothing useful). “No process” is of course the lowest overhead but I find it unpleasant to work under: much more of a blame game when things go wrong and something isn’t done, and too easy to end up building something useless.

                            2. 2

                              Modern software development is extremely fad-driven these days.

                              It sucks.

                              1. 1

                                The point about “Scrum is hypocritical” hits home so hard :)

                                On topic just wanted to say there’s no perfect methodology for developingh software because not all the software and people that build it are the same. Just take the good bits form agile/scrum/waterfall/whatever ans “follow” those. So whatever works for you/your team.

                                1. 1

                                  A lot of this and the ensuing arguments sound like a No True Scotsman argument, Scrum is good but everyone does it wrong, Scrum is bad unless you do it right.

                                  I’m not an expert in or fan of scrum, but it seems to work as an outline for talking about the hard parts of programming and project development. If you can’t work with your coworkers, managers, devs, whatever to make the nouns and verbs of scrum flex to your needs look elsewhere. I think a good portion of the explosion over the past 20 years of these techniques (and things like GTD and other self-help tools / manufacturing methodologies over the past 100) is that no one knows how to do this ‘right’ for all the possible things that could be done, but will pay for any insight that might get them closer to an effective strategy.

                                  The idea that the inventors of manufacturing methods like assembly line, TQM, TPM or programming methods XP, Agile, Kanban (stolen a bit from the TQM folks), Scrum have all encompassing insight is dangerous, but it isn’t new or all bad. At best the devs have the power to take the frameworks presented, find hypothetical fixes for their flaws and can implement them. At worst these plans come from above and end up damaging morale and momentum.

                                  Either way “scrum is the wrong way” is an absolutist statement that doesn’t provide much help in exposing a right way (other than the article stating it would be good scrum instead of bad)