Blame your “flaccid developers” and your “flaccid customers” for your poor quality products !

This is the text from a recent announcement for a course by Ken Schwaber on “Flaccid Scrum – A New Pandemic?” (text underlining is mine):

Scrum has been a very widely adopted Agile process, used for managing such complex work as systems development and development of product releases. When waterfall is no longer in place, however, a lot of long standing habits and dysfunctions have come to light. This is particularly true with Scrum, because transparency is emphasized in Scrum projects.

Some of the dysfunctions include poor quality product and completely inadequate development practices and infrastructure. These arose because the effects of them couldn’t be seen very clearly in a waterfall project. In a Scrum project, the impact of poor quality caused by inadequate practices and tooling are seen in every Sprint.

The primary habits that hinder us are flaccid developers and flaccid customers who believe in magic, as in:

Unskilled developers – most developers working in a team are unable to build an increment of product within an iteration. They are unfamiliar with modern engineering and quality practices, and they don’t have an infrastructure supportive of these practices.

Ignorant customer – most customers are still used to throwing a book of  requirements over the wall to development and wait for the slips to start occurring, all the time adding the inevitable and unavoidable changes.

Belief in magic – most customers and managers still believe that if they want something badly enough and pressure developers enough to do it, that it will happen. They don’t understand that the pressure valve is quality and long term product sustainability and viability.

Have you seen these problems? Is your company “tailoring” Scrum to death? Let Ken respond to your issues and questions!

Ken will describe how Scrum addresses these problems and will give us a preview of plans for the future of the Scrum certification efforts.

Here are my observations and thoughts from this synopsis:

  • line 2: what does “when waterfall is no longer in place” mean ? So, when waterwall was still in place, there were no issues ??? Somehow, one gets a feeling all the problems came to light only when Waterfall was “no longer in place”…so, why not get waterfall back in its place 🙂
  • line 5-6: In a Scrum project, the impact of poor quality caused by inadequate practices and tooling are seen in every Sprint ? …in every Sprint ?….now, wait a minute….I thought  Scrum project did not have any of these problems because there were no inadequate practices and tooling issues. And you certainly don’t expect to find such issues in every Sprint, or do you ?
  • line 7: OK, so now we have an official reason: “flaccid developers” and “flaccid customers” for all ills of the modern world. Wow! I am not sure if that is the best way to build trust either with teams or with customers by fingerpointing and squarely blaming them…without giving them a chance to even speak for themselves. And I thought Srcum was cool about trusting developers, not fixing blame on individuals, interacting with customers…but flacid developers and flaccid customer ??? Does it get any better than this ?
  • OK, I will probably agree ‘unskilled developers’ in the context of building an increment of product in an iteration, but what the hell is an ‘ignorant customer’ ? Try telling a customer that you are an ignorant customer…Scrum or no Scrum, you are guaranteed some unsurprising results ! And which Customer paying through his nose waits for the “slips to start occurring” ? In these tough economic times ?  
  • Is your company ‘tailoring’ Scrum to death ? I thought there were only two shades of Scrum – either you did Scrum-per-the-book or you did not. Since Scrum is the modern-day Peter Pan which refuses to grow up, we have only one version of Scrum to play around with, and unless some group of people decide now Scrum can grow to the next version (perhaps more because of commercial interests than anything else, whenever that happens). So, how can one ‘tailor’ Scrum – by any stretch of imagination, that is NOT Scrum. I mean, that is not allowed ! Right  ? So, why are we discussing it and wasting time – we might actually be acknowledging and unknowningly legitimizing that there is a secret world out there where Scrum can be ‘tailored’ and still be called Scrum ! That is sacrilege !

I always hate marketing messages that overpromise miracles, offer snake oil, belittle the intelligence of people, ridicule people…why can’t people simply stick to facts and figures ? Why don’t we talk in a non-intimidating language that encourages people to look up to what is being talked about ? And in the context of current subject, I doubt Scrum community is going down the right path if its next target is developers and customers. One of them does the work and the other one pays for it. Who gives us the right or the data to talk about any of them, in absentia ? Customers are customers, and even if they are irrational, they are still the customers, and whether paying or not, they alone are going to decide how they will behave. Yes, we might not like it, but is ridiculing them as ‘ignorant customers’ going to turn things into our favor ? Other industries like retail, hospitality, transportation, etc. have millions of years of collective experience in managing customers, yet they never break the singlemost cardinal rule of customer service: the customer is always right! And the first chance we software developers get to explain a poorly designed or a bad quality product and rightaway we blame the customers for it ! As if that is not enough, we then look inwards and blame the developers ! GREAT !

I think I will just develop software without blaming anyone else for my mistakes and limitations 🙂 

5 thoughts on “Blame your “flaccid developers” and your “flaccid customers” for your poor quality products !

  1. Paul Beckford

    TV,

    We are on the same page 🙂

    Salesmen come in all guises. You mention PDCA. Well I’ve suffered the TQM and Six Sigma salesmen too. Manufacturing style statistical process control applied to software (The Personal Software Process by Watts Humpreys and the SEI, the CMMI etc). Guess what? It didn’t work.

    I see many of the same ideas being re-hashed and re-branded by the Lean/Kanban camp, so buyer beware 🙂

    BTW. There is nothing wrong with PDCA in the sense you suggest. A high level process improvement approach that can be applied to most things. The problem like you say is when people try to “can” knowledge. Some in the Lean camp are borrowing PDCA tools from manufacturing and apply them by rote to software without modification. Others are obsessing about queue theory. Anything that can be canned and sold. Just more snake oil. No one is admitting the truth that it takes a good team to deliver good results, and building a good team can take years. So we are getting it from all directions 🙂

    As an example of a more enlightened approach, take a look at this interpretation of PDCA that is tailored to knowledge work:

    http://www.whittierconsulting.com/pdf/LAMDA-A3.pdf

    Interesting stuff… Look, Ask, Model, Discuss, Act. Sounds like a great way to conduct a retrospective 🙂 So I guess there is no silver bullet 🙂

    Thanks for the blog. I really enjoyed it.

    Paul.

  2. TV Post author

    @Paul: Thanks for sharing your views, and I especially like and agree with your comment that “the problem isn’t the brand of snake oil being sold, but the belief in snake oil itself”. I don’t know if this reflects our industry’s perennial underconfidence in its abilities that we fall for any half-baked claim by a high-pitch marketing claim, or a legitimate belief that journey to self-improvement is often laden with potholes, bumps and detours and that it is ok to take the road not taken. I hope it is the latter, what with the pains we undergo with each such adoption.

    The basic idea of Agile / Scrum is still the good old PDCA closed-loop management in its modern avatar and that is good (because Waterfall’s PDCA loop was not only too long to be of any meaningful use, it was also broken). The ideas on employee participation and emplowerment are again the best practices that have anyway happened alongside our social evolution process. To that end I have no disagreement. I personally think there are some good things in Scrum (with the eternal ceveat that Scrum doesn’t have monopoly over ‘all’ good software practices) but fail to understand why a good and commonsensical thing should be marketed in such a deceptive or a in-your-face manner ?

    I think our problem is the Old Guard that is so diligently gatekeeping and trying (in vain, I must add) to protect the ‘original’ knowledge that it is shutting itself out of contemprary developments, and I think they will perish for their dogmatic definition and interpretation of Agile.

    My advise to anyone who wants to try Agile is to ‘inspect and adapt’ all claims relating to Agile just like the very practices it preaches – don’t blindly accept a dogmatic version of Agile. Put Agile to test and don’t simply go for marketing claims. Like I read in a recent article….it’s time to stop the standup singalongs 🙂

  3. PAul Beckford

    Hi,

    I like parts of this analysis, especially the bits about the customer being always right, marketing messages, and Scrum masquerading as Peter Pan 🙂 I’m not sold on the overall tone though. Let me explain why. There seems to be an assumption abound in the Agile community that Agile Adoption/Transitions is the acid test of Agile success.

    Personally, I just don’t believe this to be true. Kent Beck and the XP community IMHO were very honest about what it took to be successful at delivering software, and what did the main stream software industry do? Well they looked to Scrum with its lower bar to entry and its magical “snake oil” certificates.

    Scrum is not a method or a process. Its a “meta-model”, that advocates an empirical, iterative and incremental approach and the idea of “inspect and adapt”. Scrum will only ever be part of the answer. We need to fill in the rest for ourselves.

    Scrum the product is just that a product. Any one who is duped into buying snake oil to solve their problems deserve what the get IMHO 🙂

    The responsible amongst us will think for themselves and inspect, adapt, add, extend, modify as they see fit. I call this Generic Agile and it consumes XP, Scrum, Crystal, Lean, Kanban etc. What ever works.

    So who is doing Generic Agile? Well not the mainstream. New startups (or should I call them upstarts :)) like 8th Light for instance, and new Goliath’s like Google. These companies are built on Agile values and has such have no need for cookie cutter solutions and snake oil salesmen. Instead they know to focus on craftsmanship and doing the right thing, freeing their people to be both creative and innovative.

    To me Scrum bashing is too easy. The company transition industry pre-dates Scrum and looks to be getting a new lease of life in the guise of Lean/Kanban. The problem isn’t the brand of snake oil being sold, but the belief in snake oil itself.

    What we should be looking to are shining examples of success. Companies that are built on Agile values and principles from the get go. They are the future and in time, the old school that are in the market for snake oil will whither and die.

    So lets celebrate the true Agile successes and move beyond which brand of snake oil works and which doesn’t 🙂

Leave a Reply