Love Me I’m an Agile Scrum Master

In the 1966 song, Love Me I’m a Liberal, protest singer Phil Ochs mocked the American left for insincerely pledging support for civil rights and socialist causes. Using the voice of a liberal hypocrite, Ochs sings that he “hope[s] every colored boy becomes a star, but don’t talk about revolution; that’s going a little too far.” The refrain is, “So love me, love me, love me, I’m a liberal.” Putting Ochs in historical context, he hoped to be part of a major revolution and his anarchic expectations were deflated by moderate democrats. In Ochs’ view, limousine liberals and hippies with capitalist leanings were eroding the conceptual purity of the movement he embraced.

If Ochs were alive today, he probably wouldn’t write software; but if he did he’d feel right at home in faux-agile development situations where time-boxing is a euphemism for scheduling, the scrum master is a Project Manager who calls Agile a process, and a goal has been set for increased iteration velocity and higher story points per cycle. Agile can look a lot like the pre-Agile world these days. Scrum in the hands of an Agile imposter who interprets “incremental” to mean “sequential” makes an Agile software project look like a waterfall.

While it’s tempting to blame the abuse and dilution of Agile on half-converts who endorsed it insincerely – like Phil Ochs’ milquetoast liberals – we might also look for cracks in the foundations of Agile and Scrum (Agile is a set of principles, Scrum is a methodology based on them). After all, is it really fair to demand conformity to the rules of a philosophy that embraces adaptiveness? Specifically, I refer to item 4 in the list of values called out in the Agile Manifesto:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

A better charge against those we think have misapplied Agile might be based on consistency and internal coherence. That is, item 1 logically puts some constraints on item 4. Adapting to a business situation by deciding to value process and tools over individuals can easily be said to violate the spirit of the values. As obvious as that seems, I’ve seen a lot of schedule-driven “Agile teams” bound to rigid, arbitrary coding standards imposed by a siloed QA person, struggling against the current toward a product concept that has never been near a customer. Steve Jobs showed that a successful Product Owner can sometimes insulate himself from real customers; but I doubt that approach is a good bet on average.

It’s probably also fair to call foul on those who “do Agile” without self-organizing teams and without pushing decision-making power down through an organization. Likewise, the manifesto tells us to build projects around highly motivated individuals and give them the environment and trust they need to get the job done. This means we need motivated developers worthy of trust who actually can the job done, i.e., first rate developers. Scrum is based on the notion of a highly qualified self-organizing, self-directed development team. But it’s often used by managers as an attempt to employ, organize, coordinate and direct an under-qualified team. Belief that Scrum can manage and make productive a low-skilled team is widespread. This isn’t the fault of Scrum or Agile but just the current marker of the enduring impulse to buy software developers by the pound.

But another side of this issue might yet point to a basic flaw in Agile. Excellent developers are hard to find. And with a team of excellent developers, any other methodology would work as well. Less competent and less experienced workers might find comfort in rules, thereby having little motivation or ability to respond to change (Agile value no. 4).

As a minor issues with Agile/Scrum, some of the terminology is unfortunate. Backlog traditionally has a negative connotation. Starting a project with backlog on day one might demotivate some. Sprint surely sounds a lot like pressure is being applied; no wonder backsliding scrum masters use it to schedule. Is Sprint a euphemism for death-march? And of all the sports imagery available, the rugby scrum seems inconsistent with Scrum methodology and Agile values. Would Scrum Servant change anything?

The idea of using a Scrum burn-down chart to “plan” (euphemism for schedule) might warrant a second look too. Scheduling by extrapolation may remove the stress from the scheduling activity; but it’s still highly inductive and the future rarely resembles the past. The final steps always take the longest; and guessing how much longer than average is called “estimating.” Can we reconcile any of this with Agile’s focus on being value-driven, not plan-driven? Project planning, after all, is one of the erroneous assumptions of software project management that gave rise to Agile.

Finally, I see a disconnect between the method of Scrum and the values of Agile. Scrum creates a perverse incentive for developers to continually define sprints that show smaller and smaller bits of functionality. Then a series of highly successful sprints, each yielding a workable product, only asymptotically approaches the Product Owner’s goal.

Are Agile’s days numbered, or is it a good mare needing a better jockey?

———–

 

 

“People who enjoy meetings should not be in charge of anything.” – Thomas Sowell

 

,

  1. #1 by Artem Kaznatcheev on July 20, 2016 - 4:51 pm

    Given that ever since first year of college, I’ve tried to avoid software engineering like the plague, I am surprised at how much I enjoyed this post. Well done!

    As I was reading this, however, I couldn’t avoid thinking about the philosophy (and sociology) of science that originally brought me to your blog. What are the equivalents of Waterfall and Agile in science? I can’t help but see that contrast in the typical lives of graduate students (and post-docs, faculty, etc) in biomed vs. math. Can we write down an Agile Manifesto for science? Or at least for modelers trapped at the border of math and biomed? I guess this is the sort of things that systems engineers worry about all the time.

  2. #2 by Bill Storage on July 21, 2016 - 5:23 pm

    Hi Artem. I’m not sure agility should apply to science since many would say that science should steer clear of giving customer satisfaction top priority. I.e., Stalin was the customer for Lysenkoism; and it’s scientists kept the customer happy at all times.

    On possible parallels between software development and science with regard to Agile’s values – maybe something like:

    • Welcome changing requirements: avoidance of dogmatism
    • Business people and developers must work together: multidisciplinary teams
    • Build projects around motivated individuals: find autotelic personalities
    • Best designs emerge from self-organizing teams: avoidance of bureaucracy
    • Simplicity (what is worth doing?): what’s worth knowing?
    • Working software is the measure of progress: theories must make testable predictions
    • Team reflects, then adjusts its behavior: reflection – hey, look, they’re doing philosophy!

    For those in theoretical biology, is there an issue of choosing approaches to problem solving similar to Agile/waterfall, e.g., deterministic vs. stochastic representations of a given system? (I know nothing of theoretical biology.)

  3. #3 by smearerm on July 25, 2016 - 9:08 pm

    That’s the contrarian I’ve come to know and love!
    For me, a software developer, I’ve come to think of (successful) Agile as Waterfall, but where the depth of field is very close, gradually degrading towards a blurry horizon. And you get to push the “deploy” button more – that is nice for everyone. Thank you for bringing the quality of developers into the conversation. I shudder to think how many agile success stories gloss over this. I wonder how much of the success of agile is due to smart, self-organizing, and highly skilled teams simply believing in a common thing (especially something that has a cool thing like a manifesto) rather than having a draconian project manager laying it all out then sitting back and stroking a fuzzy cat.
    The right methodology for software development is easy. It depends … on the project, on the people, on the stakeholders, on the business, on the calendar, on …

    • #4 by Bill Storage on July 25, 2016 - 10:31 pm

      Agile claimed a lot of impressive success stories early on. Your point about the source of Agile’s success reminds me of that organizational psychology study where they painted the office walls a certain color and productivity rose. The tried another color and it rose again. The repainted the walls their original color and productive rose again. Productivity rises when workers feel management cares. Perhaps the early Agile initiatives benefited from this effect.

      After writing this, someone directed me to this seeming renunciation of Agile by Andy Hunt, one of its founding members: http://blog.toolshed.com/2015/05/the-failure-of-agile.html

      I was surprised to see that. Can I still keep my contrarian status?

  4. #5 by DeeKay on July 26, 2016 - 2:25 am

    Very nice article. Thank you.
    One question about things like coding guidelines or other rules asked by QA. There are some industries simply asking for these rigid things when they order the software. So we need evidence there. To stay here agile we try to see it as part of the requirement and to implement it as criteria of done. What do you think about it?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: