Refactor your agile processes

Good read (academic paper btw ;-)):

We observe a rising scepticism towards Agile Methods: practitioners are not able
 to use them in an efficient and effective way since the underlying assumptions are 
hidden by gurus. This missing knowledge is furthermore used by agile zealots to indeed 
legitimize hacker behaviour. The reputation of Agile is at stake.
To avoid that Agile Methods become obsolete, we think it is necessary to understand 
software development process tactics, i.e., knowledge about when to use which practice,
 knowing its advantages, its disadvantages, and how to apply it.
Therefore, we propose the use an approach to collect falsifiable knowledge about agile methods, 
for example using the Quality Improvement Paradigm.
To change this attitude, i.e., to switch from believing a guru to adopt a scientific approach requires 
educational, cultural, and managerial changes. To study how to accom-plish these, will be the 
challenge of the future.
"XP is like a ring of poisonous snakes, daisy-chained together. All it takes is for
 one of them to wriggle loose, and you've got a very angry, poisonous snake 
heading your way." (Stephens and Rosenberg)
Agile methods are undeniably one of the important recent developments in software
engineering. They are also an amazing mix of the best and the worst. This is an extraordinary
situation: usually, when a new set of concepts bursts forth, one can quickly assess
its overall contribution as beneficial, neutral or detrimental. Agile texts, however, defy
such a simple judgment: you may find in one paragraph a brilliant insight, in the next
paragraph a harmless platitude, and in the one after some freakish advice guaranteed to
damage your software process and products.[..]
 Until now, however, each organization and project has had to repeat for itself
the process of sorting out the gems from the gravel. What a waste of effort. This book
spares you the trouble by presenting a comprehensive description and assessment of the
key agile ideas.,%20The%20Good%20the%20Hype%20and%20the%20Ugly%20(2014).pdf

1 Like

That first paper in particular is really good, v well written, crystallizes some of the thoughts I’ve been having recently about capital-A Agile.

Personally, my experience is that Agile tends toward a form of organised bikeshedding, meeting after meeting about capital-P Process (long discussions around deciding on a correct ‘definition of done’ for tickets was a recent goodie). I can’t shake the feeling that [though in some ways it all works very well] it’s all an attempt to transplant something human and complex that worked in one setting with one team into a much more general setting, that it’s an attempt to structure something that when it works works for organic rather than structural reasons


It’s hard nowadays in Holland to find companies that work with elixir/phoenix that do not work with scrum (I found one that explicitly named “No scrum bs” in their jobrequest though). Ironically those that are the least silent about their use of scrum, TDD (“no software gets out of the door here without 100 % coverage!”) etc are the most strongly hierarchical oriented I noticed when I talked with employees / employers. While there was something with “self organizing teams” and “personal responsiblity” I felt treated like a child when I did a contractor job (using another programming language) for 1 1/2 years in a scrum team. Of course I “did not understand it”. I stood baffled the first time I entered that room without chairs, where all teammembers were standing obediently. Is this a new religion? I learned the doctrine: “now you take this post-it and replace it to this column”. I proposed to build some reusable components that luckily for me did not fit in their doctrine (upfront design, lots of work before I could show “working software”). I could persuade the software-manager of the waste of my expensive time that participating in his scrumteam meant. Lots will feel the same when this doctrine is imposed (read f.e. or see f.e.). But it’s hard to find well reasoned critical papers wherein the baby is not thrown away together with the dirty water. Maybe the two links I sent are a starting point.


It all comes down to the fact that “agile” is a mindset, not a set of practices, not a set of methods, not a cookie-cutter approach to being iterative (i.e. scrum). And because it’s a mindset, it should be org-wide.

Unfortunately it’s not as easy as asking people if they’re agile, because “yeah, we have standups” is basically the best you’re gonna get…


Good read:


Academics Demolish Straw Man - Film at 11:00

1 Like

I think the best approach to deconstruct that is to forget about “agility” or “Agile”.

As happens everywhere, you get a system that represents its hierarchy/model. Learn how it works for others and build a system that correspond to your team members and the thing you have to build.

This is what is behind all the part of the “Agile Manifesto”. Adapt to others and the goals. This is also what Human Factors and Ergonomics teach. Because it is how you get something that works.

The “Agile” stuff is just another symptom of the root problem : fear of consequences and the “Bad Apple” syndrome

1 Like

TL;DR Annoying processes and tools, often established as a quick fix, are symptomatic in this industry and “commercial Agile” is only one of the symptoms. To discredit “inappropriate usage” often requires developing an understanding of the offending process or tool that typically goes far beyond what some of it’s proponents are willing to develop. And even when you make a well argued case for “you are doing it wrong”, you’ll often be countered with “I’m just doing what he/she/it told me to do”. Bad implementations don’t invalidate the core principles.

Many of the deployments of SCRUM would be in trouble once they were scrutinized for the “individuals and interactions over processes and tools” value under the agile manifesto - i.e. in many places SCRUM has become the Process for it’s own sake and no longer serves to enhance interactions to allow individuals to contribute effectively to the project/product.

In my view the scourge of “commercial Agile” is only one of a number of constantly mutating symptoms that have been manifesting themselves over time which I believe comes from the divergent mindset between “makers” and “managers” which is alluded to in Paul Graham’s Maker’s Schedule, Manager’s Schedule.

In this particular case, “meeting” is a tool that is well understood by managers - they gather information during meetings (information which is often researched independently by other attendees) and they delegate work during meetings. So to some managers “meetings” is how work gets done. But of course meetings simply route work. If the right work gets routed to the right place things get done, otherwise things can devolve rather quickly, especially when all that routing time eats into the working time.

Frequent meetings also appeal to some managers because it gives them the illusion of being more in control, not having to trust their makers as much.

So in my view SCRUM is something that some management can easily get behind because all those meetings keeps matters in their comfort zone.

In some cases there is also the desire to have “Process replace thinking because then non-thinking (cheap and easily replaceable) drones can handle this incidental part of our business”. That motivation seems to be a factor with the adoption of a lot of shiny objects in our industry - sometimes it even becomes a key part of a new product:

Go lang - language design

Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical.

… it’s more important to make a relatively “cheap” workforce “productive” rather than having a workforce that creates professional and mature products?

Another example outside of “Agile” where valuable insights could be buried under problematic adoption:

Ted Neward on Web Services and Security (2005)

Start from your code, just sprinkle some web service magic pixie dust on it and lo and behold you have a web service, bad things, bad, bad, bad, bad. I need to beat the vendors over the head to stop doing that

Basically that “magic pixie dust” dust enabled a run-of-the-mill programmer (prone to the “leaky illusion of local/remote transparency”) to deploy a webservice without ever really having to bother to find out what makes a well designed webservice.

This of course escalated to the frenzy of SOA-tooling which ultimately collapsed in 2009. Ironically important strides where in fact made in service oriented design but for the longest time that experience was tainted by association with the period of SOA-tooling - to the point that some people need to be reminded that these same design principles also apply to the now-hyped microservices.

Also hype or popularity rarely foster actual understanding. Once the SOA-tooling collapsed, attention focused onto REST - but many people still associate REST with JSON over HTTP, pretty URLs, something cranked out by swagger, etc. - rather than something based on the 4 core concepts of resources, their names (URIs), their representations and the links between them with the 4 core properties of addressability, statelessness, connectedness, a uniform interface.

The point being, something can be valuable at the core, be it the values of the agile manifesto, service oriented design principles, REST, etc. - there simply is no guarantee that people will make the effort to truly understand the fundmentals, nor is it guaranteed that somebody won’t come along and turn it into some cookie cutter process or tool (typically but not always for profit) that can be misapplied to all sorts of situations.

Unfortunately it often is far easier to apply a process or tool than it is to acquire the wisdom to know when it is appropriate to use it.


That. And yes, I’m just posting this so I can quote that so it’ll be twice on the page :slight_smile:

1 Like