The Wrong Questions about Agile

When it comes to Agile, people often ask the wrong questions. I’ve used the term “wrong question” before, and it brought out the trolls, so let’s start with that. The trolls usually scream: “there is no such thing as a wrong question,” and then they launch into a discourse on why I’m an idiot.

However, the troll's (perhaps deliberate—we are talking about trolls, here) response is actually a misquote. What they mean to say is that "there's no such thing as a dumb question." That's true. There are no "dumb" questions.

A so-called "dumb" question is one that the questioner asks reluctantly because they believe that everyone else "gets it." Usually, though, nobody "gets" it. That's my fault, not theirs. A question like that tells me that I'm not doing my job of explaining things well enough, and I answer by trying a different (hopefully better) explanation. The questioner might think it's "dumb," but I don't.

There are definitely "wrong" questions, though.

A wrong question is one that's posed in such a way that there is no correct answer, usually because of a strong bias that precludes a new way of thinking. For example: "Should I put either 5 or 7 anchovies into my Crème brûlée" is definitely a wrong question. The only valid answer is "you don't put anchovies in Crème brûlée," but that's not actually answering the question. 0 is nether 5 nor 7. Things can get difficult when the person posing the question takes your answer as an evasion.

The only proper response to a wrong questions is to explain in depth why that's the "wrong question" and pose some "right" questions. The "right" question is "should I put smelly fish in my desert?" (The answer is: "Only if your guests are penguins.")

Wrong questions, when asked sincerely, are certainly not dumb questions. They are exposing a bias, however.

Let's move the discussion to agility. One of the more common "wrong" questions I get is "what's the role of the Project Manger in an agile shop?" The only correct answer is: "There is no Project Manager in an agile shop." That can't be a very satisfying answer to whoever asked the question because it's not an answer—it doesn't describe the role of the PM.

The questioner is assuming, of course, that agile approaches are a lot like what they're doing now, with only minor tweaks here and there. They can't imagine a shop without project managers, so they're confused when nobody talks about them. When I'm teaching, the most disturbing thing about a question like this, especially if it comes late in the class, is that the student has probably been filtering everything I've said up to that point in terms of this unconscious bias. I worry that nothing I've said has made any sense to them.

I'm grateful that they ask the question, of course, because it tells me that I have more work to do. Silence would mean that I never get a chance to straighten them out. Given that we're talking about a classroom, at least I have the opportunity.

In a consulting context, this problem is amplified. Usually, nobody has ever asked the role-of-the-PM question. When I walk around, I see that all of the Scrum teams have PMs attached. These orgs just assumed that a PM was a necessary part of the dev team, and they just veneered Scrum on top of their existing team structure. That PM will be destroying any real agility, however. Without self management, an agile team can't respond quickly enough to change.

The existence of PMs mean that this company is loosing a lot of money by not really being agile, and is probably not getting any of the benefits. I expect them, eventually, to claim that Agile is a complete failure and then dump the Scrum veneer. I've been hearing a lot of that lately ("Agile is a failure"). Most of the people who say it have no experience of actual Agile.

More to the point, correcting the problem essentially means that the organization has to go back to square one, and the sunk-cost fallacy kicks in: "We've already spent a fortune on training. We're not doing that again!" Don't get me started on incompetent trainers—many of whom are CSTs—who don't do their job by bringing up the issue proactively.

Here's another wrong question that I usually encounter in the same shops: "How do we improve the communication between the dev teams and QA?" Again, there's no way to actually answer the question. All I can say is "you shouldn't have a QA department. The testing function should be integrated into development. Everybody tests." That's not an answer, however, and the actual answer is probably unacceptable. It's too "disruptive."

So here are few more "wrong" questions. Many of these merit blog posts on their own, but for now I'll just list them, and I'll update the list when I hear a particularly interesting one.

Which certificate is better a CSM or PSM?

Neither have any value beyond getting you past HR filters for job applications to mediocre companies. Let's look at a real certificate, say as an Architect: 8 years of formal education including 3 years working as an apprentice under a licensed architect, a multi-day nontrivial exam requiring months of study, a second state-specific exam. Now the CSM: Sit through a 2-day class. Take a multiple-choice test with ~30 questions, and the "right" answer involves parroting back whatever you just heard in class.

How do I get my team to ...?

You don't. The team should be self managing and develop its own processes. If the team doesn't know enough to do that, train them. More to the point, who are you to tell the team what to do?

Which KPIs apply to agile development?

“ Working software is the primary measure of progress.” KPIs are ways for a distrustful command/control management hierarchy to monitor lazy workers. If that's your problem, KPIs won't fix it.

What's the best way to log defects?

You don't. You fix them. The only acceptable known defect level at release is 0. If someone calls tech support with a bug report, write down what they were doing when the bug surfaced. That's a story. Prioritize that story with other backlog items in the normal way.

Which is better for story points: Fibonacci or Linear?

Ron Jeffries invented points. Also, see Ron's article Estimation is Evil and my own #NoEstimates video.

Will switching to Kanban help?

No. It's never the process that's the problem unless the process was imposed on the team from outside. This question usually comes up because Scrum was imposed on the team. Imposing Kanban on the team will do nothing useful. The "right" question is "how do I change the culture so that teams are empowered to work in whatever way that they deem effective and educated enough that they can make appropriate choices?"

How do I establish milestones on an Agile project?

You don't. Milestones exist to reduce risk in an opaque process. Agile processes should be transparent. You gauge progress by looking at the working software, not by using milestones.

How would you provide bi-weekly release estimates with 90% confidence with no historical velocity data?"

This is not possible, and not because you don't have data. No amount of historical data, no matter how accurate, will change that fact. We learn as we work. What we set out to build is never the best thing, and is never fully understood in advance. You cannot estimate an unknown "with 90% confidences." Attempts to do that will drive you away from agility faster than anything else I can think of, because it will force you to define the work rigidly. Once you do that, you're not Agile by definition.

What's the correct ratio between developers and testers on an Agile team?

The answer is NaN. That is, the correct ratio is N/0, and divide by zero is not possible. Testers and developers are the same person. (Thanks to Augusto Evangelisti for suggesting this one!)

How do you deal with quality challenges in Agile development?

Agile software has no "quality challenges." When you're following the principles of the Agile manifesto, you have "continuous attention to technical excellence," and "the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." High quality is not optional, and you should constantly be making your high quality even higher. If you aren't doing that, you aren't Agile. So, the problem is not "quality" challenges; but rather, that you're challenged in being Agile at a fundamental level. Poor-quality software is a symptom of poor-quality agility. Focus on being Agile, and the quality will take care of itself.

So, I'd like to make that list longer. If you can think of others, leave a comment! Maybe I can write a book that can be more proactive in setting people on the right track.