Discovering Essential Technical Practices

Many teams seem to get in trouble because they do not have good technical practices. In Scrum terms, they can’t get “Done”. Is Scrum flawed because these teams do not “discover” such practices?

From the web …

On the leanagile list, Mary Poppendieck commented:

I see lots of floundering Scrum initiatives, typically due to the assumption that essential technical practices will be discovered by “the team” and they are not.

Ray Tayek followed up:

http://tech.groups.yahoo.com/group/extremeprogramming/message/148184
[M]aybe it [is] not so clear that these technical practices will be discovered?

Discovering technical practices is not the problem

I’d agree that many teams do not do important technical practices. It is hard to tell what the cause might be, but I’m quite sure it isn’t failure to “discover” technical practices.

There’s really only one explanation for the lack of good technical practices. You can phrase it in a lot of different ways, depending on your Agile Religion:

  • The team is not properly doing Inspect and Adapt.
    There are two issues: you have to recognize that there is a deviation from what is possible, and you have to figure out something to do about it.
  • The team is under pressure from manager, Product Owner, or themselves to “go faster”.
    Under pressure, we cut corners, almost always.
  • The team is not following Lean principles.
    Lean’s principles are arguably more explicit than those of Scrum. Maybe if we taught the team Lean principles they would do better.
  • The team is not following XP principles and practices.
    XP’s principles and practices are unquestionably more explicit than those of either Scrum or Lean, and they are pretty much custom made to be just what the Scrum teams mentioned here need.
  • [Your favorite explanation here.]

These all come down to the same thing. Either the team (and its leaders)

  • do not recognize the situation as a problem, or
  • they do not know a solution, or
  • they choose not to implement the solution.

Frankly, I think you’d have to have a room full of coneheads not to know a solution. I think the notion that Scrum teams do not “discover” technical practices is probably a red herring. There is almost always someone in the room who has heard of XP, TDD, even Lean. Most of them have heard of the Internet and Google. There are lots of other solutions out there, and a little bit of thinking will find things to do. I have never encountered a team who, recognizing a problem, couldn’t think of some useful things to do.

Therefore, either they do not see the problem, or they choose not to fix it.

See no evil

Sometimes teams do not recognize the problem. This is not a failure to discover technical practices, but a failure to recognize the need.

I’ve encountered quite a few teams who seem to believe things like this:

  • It’s normal to write code and only discover much later that it isn’t what is wanted;
  • It’s normal to write code and only discover much later that it doesn’t work;
  • It’s normal to have to wait days or weeks to hear back from “QA';
  • It’s normal to have to wait days or weeks to get a database change;
  • It’s normal to have a long delay called “Code Freeze” or “Stabilization”;
  • It’s normal to have a bug list that requires Oracle to contain it;

These things are only normal in the sense that they happen a lot. By that reasoning, obesity and myopia are normal. For sure, they are not ideal.

I often tell teams that apparently my purpose in life is to tell people that the sensation in their butt is called “pain”, and that they should get rid of it.

It is possible to know you have a problem, and know what you should do, and yet not do it. There are two main causes of this, Skill Failure and Schedule Pressure. We’ll discuss them in turn.

Skill Failure

Knowing that you are supposed to do something is one thing. Knowing how to do it well enough to make it practical is another. Sometimes, I encounter teams who know that they should be doing TDD or Customer Tests or Refactoring, but they are not very practiced in it. They say they haven’t time to do it, or that they tried it (probably for a day or so) and “it didn’t work.”

The result, sometimes, is that a team does not do technical practices because they do not have enough experience with them to know how to use them to make the situation better.

Again, it is rare that they do not discover the practice. They usually know what to do and do not do it.

In my experience it’s usually not lack of skill. It is lack of will.

Schedule Pressure Destroys Quality

I have lost entire clients for pointing out what follows, so listen up. It’s important, and it is hard to hear.

You can have all the practices you want on your mandatory practice list, and it will not help if you don’t do them. And all it takes to cause the team not to do them is to make them believe that what really matters to you is that they get more features done at the end of the week. There are lots of ways to make them believe this:

  • Measure stories released by person and consider more to be good;
  • Measure stories released by the whole team and consider more to be good;
  • As product owner, ask frequently whether there isn’t a “quicker” way;
  • At planning meetings, press for just one more story;

All of these and many more have the same effect. They say “Pay no attention to all those posters and that coach over in the corner telling you to do TDD and keep the code clean. Just keep those features coming!”

Doing TDD and refactoring and all that are hard. They require support and nurturing and praise to be sustained. They need almost nothing to be suppressed.

Bottom Line

For me the issue here is not failure to discover technical practices. The primary reasons for poor technical practice are shedule pressure, which suppresses good work quite effectively, or a failure even to recognize that there is a problem

It is quite rare for a team to recognize that they have a problem, and to be unable to come up with something to do about it. If they keep doing recognizing problems and coming up with solutions, they will ultimately prosper.

2 Responses to “Discovering Essential Technical Practices”

bria526

February 5, 2009

2:03 pm

permalink

There is only one thing to say about this: Amen, so true, well said.

(Hm, maybe that’s 3 things…)

Cheers
MB

beckfordp

February 17, 2009

7:37 am

permalink

Hi Ron,

You miss another reason why people don’t “discover technical practices”. Its simple really, they just aren’t looking for them.

Cynefin Theory makes it clear that organisations aren’t optimal, and that there are often many, conflicting agendas at play. Not everyone defines success in the same way. Change in itself can be perceived as a threat by those who feel that they only have something to loose. So why go looking for new stuff?

It was working as a manager, that made me acutely aware of these other agendas. Once I started to take them into account, the erratic and irrational behaviour of others suddenly started to make sense.

PS. The views of Mr Jurgen Appelo for instance seem to me to be more motivated by political ideology than the desire to reliably to deliver working software. Yet another agenda to throw in to the mix :)

Paul.

Recent Articles

Emergent Design

Martin Alaimo asked about the Manifesto Principle "The best architectures, requirements, and designs emerge from self-organizing teams."

Codea Calculator II

Ignatz and Jmv38 on the Codea forums commented on the previous article. I had hoped to do more anyway so here's the next one.