Context, My Foot!

There’s too much context going around.

Martin Fowler has recently posted a note on Flaccid Scrum. Related posts such as Jim Shore’s The Decline and Fall of Agile have made similar points. Lots of discussion has ensued. The fundamental observation can be put this way:

There are a lot of Scrum teams out there who are not performing well.

Jeff Sutherland, co-inventor of Scrum, says he has never seen a Scrum team become hyper-productive without adopting the XP practices. Less elegantly, I have said that teaching Scrum teams how to get Done-Done is why I have such a lovely blue convertible.

In our justly famous “Nature of Software Development” talk and course, Chet Hendrickson and I show rather clearly why Agile is good for business. We also show how Agile demands that you solve certain problems that can only be solved in the XP way. The stories on my site about Kate Oneal make a similar point, from the viewpoint of someone who puts our advice into practice.

A recent thread on the XP list has described a team who are not using good technical practices, and who are falling further and further behind in “technical debt”. (“Technical Debt” is a polite phrase describing the situation of a team who are writing crappy code on a regular basis.)

Through Deep Snow, Uphill, Both Ways

From the beginning of XP and the other forms of Agile, we have been plagued with people reporting that they tried Agile and it didn’t work. It used to be my practice to ask them about a dozen questions, like

  1. Was your Whole Team together in one place?
  2. Tell us about your Onsite Customer.
  3. Describe your Release Planning process.
  4. Tell us about your automated customer acceptance tests.

… and so on.

This approach was unpopular. People said that I was trying to find some aspect of XP that they didn’t do and then blame the failure on that. Well, not exactly, but on the other hand, hell yes.

If you don’t do what we suggest, then don’t call what you do by the name of what we suggest. Don’t call it XP if you don’t do the XP practices. Don’t call it Scrum if you don’t Inspect and Adapt, and while you’re at it, how about heeding the Jeff Sutherland hint up above?

XP and Scrum and Agile are not guaranteed to succeed, and they aren’t the only way to succeed. The only way to succeed — other perhaps than catching a really lucky break — is to build a team who work well together and who get things done. XP and Scrum are the best ways we know to work well together. They are not necessary — there might be other ways — and they are surely not sufficient — there are a million things we must do to be successful, and they’re not all written down in books.

You have to do right things, and you have to do things right, in order to succeed.

What right things, you irritable curmudgeon?

Let’s take a simple example from the “Nature” talk. We begin that talk by showing why the business people need to see real software getting done, on a regular basis. We’ll skip that derivation for now.

Given that you’re going to ship software from the beginning to the end of the project, it is clear that you need to

  • start with a simple design, because at the beginning, you won’t have enough of a design to support all the software;
  • have a more and more robust design as the project goes on, because you can’t make progress with insufficient design;
  • wind up with a fully robust design, capable of supporting the whole project and its future needs.

There is no choice. You must evolve your design. You must improve the design of existing code.

Guess what!?!? That’s the subtitle of Martin Fowler’s book, Refactoring.

In order to do Scrum or XP or any form of Agile successfully, you must refactor. Sorry, not optional. Necessary.

There are many more practices, generally outlined in XP and elsewhere, that are just as essential as this one. There really is no choice. If you want to succeed, you’ve just gotta do them.

Situational Ethics

As XP / Agile / Scrum have become more popular, many teams and individuals have wanted to do them, or “be” them. This has led to a school of Agile methods that wants to be called “context dependent”. The idea is that whatever brand of Agile is under discussion is “too rigid” and “doesn’t fit our context”. So we have to modify Agile because God knows we can’t modify our context.

Well, my dear little children, I’ve got bad news for you. It is your precious context that is holding you back. It is your C-level Exeuctives and high-level managers who can’t delegate real responsibility and authority to their people. It is your product people who are too busy to explain what really needs to be done. It is your facilities people who can’t make a workspace fit to work in. It is your programmers who won’t learn the techniques necessary to succeed. It is your managers and product owners who keep increasing pressure until any focus on quality is driven out of the project.

There is an absolute minimum of practice that must be in place in order for Scrum or XP or any fom of Agile to succeed. There are many other elements of practice that will need to be put in place. And yes, the context will matter … and most commonly, if you really want to be successful, it is the context that has to change.

Want to succeed at software? Then it can’t be business as usual. Study the material, do the practices, get help. Or get out of the way.

7 Responses to “Context, My Foot!”


January 30, 2009

8:55 pm


Hi Ron,

I have a question regarding “Was your Whole Team together in one place?” I understand that this is optimal but what team do you think would perform better ? A team of 8 distributed developers all of whom had a high level of competence and agile aptitude (who proactivly communicate in spite of being distributed) or a collocated team of 8 with the typical mixture? (In my experience this looks like two strong performers with agile aptitude, 3 average programmers, two terrible programmers and one saboteur).

I’d be interested in your thoughts on this, I’ll follow up with the reason for the question.

— Jonathon


January 30, 2009

9:22 pm


Obviously a sufficiently good distributed team will beat a sufficiently bad collocated team. On the other hand, that same sufficiently good distributed team would likely be twice as effective were they collocated. (And happy about it.)


January 31, 2009

12:34 am


I agree 100% as to your second point.

The context of my question is that on more than one occasion I have worked with organizations that due to a circumstance beyond their control, Geography, they will never be able to hire the appropriate collocated team. So, what these teams do is continue to swim upstream with the best possible hires they can find that as you say in this post write “crappy code on a regular basis.” They continue to hope against all logic that eventually the “crappy coders” will become competent by the good example set by the minority.

It seems that companies in this circumstance would be better served to widen their pool and allow for a distributed team or a partialy distributed team. Yes, you’re sacrificing the one principle of a colocated team but isn’t that better than sticking to this principal at the expense of all the other practices (TDD, Refactoring, Iterative Design, No Crappy Code)?

P.S. You can coin a new XP buzzword, NCC ;-)


January 31, 2009

8:32 am


I don’t agree in general, Jonathon. The crappy coders in a collocated group can only stay crappy if the whole group either values crappy or does not work to bring them along. Working together doesn’t just mean being in the same room ignoring each other. If the team values the practices, they’ll do them and teach them to the noobs if necessary. If that’s not happening, that tells me that the group doesn’t value those things, and they won’t value them any more highly when distributed. They’ll just have more trouble coordinating.


February 3, 2009

9:45 am


First, off, I agree with about 95% of what you wrote. I’ve seen way, way, way too many people fail at “scrum” and “XP” (in quotes) – both because they weren’t really doing either.

Likewise, it is to my great personal chagrin that people are using context-driven methods as an /excuse/. Waa-waa-waa my HR people won’t let me do this my facilities people won’t let me do that.

Context-driven says adapt your process to the /essence/ of the business – which turns out to be a non-trivial task. All that stuff above is adapting the process to the /accident/.

There is a big difference.


February 4, 2009

7:12 pm


As someone who’s recently experienced the whole “We tried Agile and it didn’t work” exercise in blame-shifting, I can say that Mr Jeffries has perfectly nailed our situation.

We had all of the best intentions as we went about our business, calling ourselves Agile, but we unfortunately did so rather haphazardly. We suffered from Product Managers who couldn’t do the job – understaffed, untrained and, in the final analysis, unavailable – as well as executives who seemingly could do nothing about that dire predicament. We also went almost two years with little or no professional Agile coaching (which was more my fault, as Agile Manager, than anyone else’s) and therefore continued to flounder, all the while blaming the development teams who in most cases were actually doing quite well, under the circumstances. We allowed schedule pressures to compromise principle after principle, and then wrung our hands in frustration at the inferior results that those poor decisions produced.

I also observed first-hand another oft-cited phenomenon of Agile: that it will reveal all of your weaknesses. That it did; we just didn’t do anything with that information, no matter how many times Agile flung it up in our faces.

Attempting to “go Agile” was an interesting enough journey, in fact, that I got material for two books out of it (“The Real-Life Adventures of AgileMan” and its sequel, “More Real-Life Adventures of AgileMan”). And I don’t think that would have been true of any other two years in my 22-year career! So that’s something, I guess…


February 5, 2009

4:31 pm


I recently saw anther notable description of advice-giving and rigor, surprisingly similar in tone….

Recent Articles

Codea Calculator

Based on a simple example on the forums, I decided to write an article showing all the stuff I might do on a production calculator project. Wow.