Vet Your Agile Advisor with 5 Questions

Whether an internal hire or a hired gun, onboarding someone to advise you about Agile is a risky but important gamble. Not all Agile advisors are equal; there are good ones, bad ones, and some in-between ones.  How can you tell the difference?

Just to be clear – Agile is the worldwide standard for software development today. However, Agile is a philosophy, not an instruction book. Like any philosophy, Agile is susceptible to variation in interpretation and implementation. Such variation has extreme consequences, sometimes creating a fast-paced highly productive culture and other times a lumbering beast that drains budgets with low workforce engagement and questionable delivery throughput. It should come as no surprise that simply ‘being Agile’ is no cure for anything.

I often work with post-Agile organizations; i.e., organizations that fully transitioned to Agile Software Development. The top complaint I hear from executive management in these organizations is that productivity is the biggest disappointment.

I agree that many organizations suffer chronic productivity problems even after transitioning to Agile. The root cause isn’t Agile itself, it’s the type of Agile.

As a philosophy, Agile is non-hierarchical self-organizing egalitarianism, consensus decision-making, community ownership, deep collaboration, transparency, and open communication. From this perspective, Agile could be a 1970’s era hippie commune, complete with spiritual leader, a.k.a. ‘Agile Coach’.  Viewed from this perspective there is no emphasis to drive workforce engagement, productivity, high-margin returns, or blistering speed.

Relax man! We’ll get there when we get there

Vet Agile Advisor - 5 questions - artwork

However, the hippie bus is not the full story with Agile. The Agile philosophy also embraces extreme disciplines around test generation and test execution, continuous integration, individual craftsmanship, proper software engineering, lean workflow optimization, small elite teams, and continuous delivery. Agile can be aggressively aerodynamic packing tons of horsepower into a small footprint, if that’s your thing.

Unfortunately, few Agile practitioners go deeper than the commune-style egalitarianism aspects of Agile.

Vet Agile Advisor - 5 questions - Executive Perspective

Imagine yourself in the position of vetting a new Agile advisor. What questions do you ask?

Here are 5 questions we designed to help you vet whether someone is performance-oriented:

1 – How does Agile fail?

If they answer with some variation of “lack of buy-in from management or stakeholders” then run, because they plan to blame you for any failures. As with all philosophies, Agile can fail; and it does…predictably. Someone with real experience squeezing high-performance out of Agile should be familiar with its modes of failure. Those who sprinkle ‘Agile fairy dust’ over organizations, generally refuse to accept that Agile can and does fail. These people will be unable to articulate the circumstances under which it fails or why. Likely those people will answer your question from the ‘Agile is perfect – everything else is the problem’ perspective. That perspective is naïve and not at all useful.

2 – If productivity is my #1 concern, how does that impact Agile?

I’m not suggesting productivity should be your #1 concern, but you need to know how your Agile advisor reacts to such prioritization. What components of their approach to Agile would be emphasized or deemphasized to optimize for productivity? Lower-end advisors will avoid directly answering the question and focus on the definition of ‘productivity’. Productivity is seen by lesser Agilists as an outdated 20th century ode to Taylorism. They’ll talk about how it’s not proper to think in terms of productivity in the modern age and how software organizations are much more complicated than that. Of course, this attitude is partly to blame for so many IT shops that have chronic productivity problems after transitioning to Agile. Not only do many Agile advisors not know how to optimize for productivity, they don’t recognize productivity as something important.

3 – If innovation is my #1 concern, how does that impact Agile?

This question is intended to separate the master class from the middle. This may come as a surprise, but innovation is rarely discussed within Agile circles. It’s is not an ugly word, like ‘productivity’, it’s just not discussed much. The lesser Agilists believe innovation is a natural ‘happy accident’ that comes from self-organizing egalitarianism, consensus based decision-making, community ownership, deep collaboration, and open communication. These people lack a basic understanding of innovation leadership and certainly don’t know how to incubate it alongside Agile. The truth is, innovation is not addressed by Agile. If innovation is a priority, additional workflows are necessary to generate, select, and develop fresh high-impact ideas.

4 – How will I know if Agile is successful?

A gripe many executives express 3 (or 5) years after embarking on an Agile transformation is – they are still transforming. When does the train arrive at the station? How can you tell when Agile is working? Just as lesser Agilists are unlikely to blame Agile for any failures, they are equally unlikely to promise measureable improvements or success. A grittier person will take this question seriously and put their reputation on the line. Think of it this way, if your organization doesn’t feel a sharp improvement in feature delivery and quality at lower production costs … why exactly is Agile being embraced?

5 – If we only adopted three things from Agile, what three practices will make the biggest difference?

This question separates the bottom of the barrel from the middle. If the answer covers daily standups, retrospectives, planning poker, pair programming, story walls/backlogs, or anything like that then fail. If their list of three includes ‘iteration’ then that’s borderline okay – but iteration is hardly unique to Agile (even Waterfall had it) and should be done regardless. If their list includes Continuous Integration or Continuous Delivery, then gold star; in fact it’s hard to envision a correct answer that omits those two. Also give gold stars for advanced Test Automation, but the answer must go beyond the mere basics of creating unit tests that will inevitably wind up in the ‘technical debt’ pile; i.e. the answer must key on ‘advanced’.  The double-gold star goes to the person who prioritizes ‘technical excellence’, particularly with respect to team member selection. It’s not that the 4 values and 12 principles of Agile aren’t all important, but some are way more important than others. Does your Agile advisor know which those are, or at least does she/he have a strong opinion?

Finally, for extra credit you could ask them how they would implement Agile without Scrum.  Many practitioners of Agile only know Scrum (it takes < 1 hour to become a Certified Scrum Master). Challenging your Agile advisor to formulate an approach to Agile without Scrum will test their knowledge of ‘first principles’ rather than rely on their hour of training. Like asking an artist to paint something in black and white; sure they have skill to paint with color – but it’s a good test to see if they can make something beautiful from a smaller palette.

1 reply
  1. Gerry Perham says:

    Nice article, Thad. Too often the agile ‘practitioners’ at our site are far too autocratic and rigid. They lose sight of the philosophy and get enamored by the implementation/procedures even if they are not working. A recent company-level report on Agile (which had data that Agile projects had been failing at a higher rate than non-Agile cited two things as the problem: (1) lack of training on Agile; and (2) lack of management buy-in. Essentially it said “give the Agile Excellence Center more money and stop questioning us” which seems like the wrong message to be sending to your executives. So I was pleased to see this cited under your #1 as a bad indicator. Unfortunately our retrospectives do not really seem to get honest feedback as people feel it is the implementation of Agile which is causing problems but the Scrum Masters don’t want to hear that. I don’t think the programmers have any problems with the concepts of Agile – after all it was originated by programmers who wanted more independence and trust in their competencies. But when it becomes the new bureaucracy which cannot be questioned then it will fail. Nice to see that experts such as yourself do not subscribe to blind allegiance. Constantly questioning what is working and what isn’t is a key to making the methodology work in the long run.


Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *