Agile Methodology Context

In a response to my post on Adopting Agile as the Default Methodology Lidor Wyssocky makes the point that:

The methodology wars are 90% psychological. If we would just stop using the names of one methodology or another in our discussions, most of our disagreements will disappear. At the end of the day, it all comes down to common sense.

It’s a relevant point and one I tend to get caught up in. The point is really to adjust the process to fit the needs of the team and the context while making forward progress.

I suppose my passion for arguing hard for the word Agile or Scrum at my current company is that I fear returning to our old painfully familiar waterfall process that fit very few projects. It may be a bit irrational, but I just dread doing piles of needless and nearly worthless documentation. I dread even more the huge lags between waiting for a requirements document and actually being allowed to move forward. I’ve been stopped multiple times in the past for merely moving forward with the project and not following “the process.”

Anyway on the current critical project with a two month timeline things have evolved. I think the product owners and the project managers assume we’re still doing waterfall, but an enterprising tester on the project felt the need to step up and get the project moving. So today he held a meeting with everyone but the product owners and the PM to go through what we know about the requirements so we can:

  • Modify our regression tests.
  • Get started on the coding which is already underway.
  • Get a list of questions together for the business to answer.

This is really one of the best possible outcomes since a regular team member was willing to lead the way instead of waiting to go over the waterfall in a barrel.

People will often succeed in spite of the process.

5 responses to “Agile Methodology Context”

  1. Hi Ed,

    I’m glad to see that things are working out.

    I think however that people are not succeeding *in spite* of the process. They are just adapting the process to the concrete needs of the project – they are creating a customized process. They are not using the terms Waterfall or Agile – they just do things right.

    That was exactly the message I was trying to send…


  2. The story reminds me of something Ken Schwaber said during our CSM class about “stealth Scrum.” It really doesn’t matter what words you use, it’s the substance that matters. If some people are nervous about the words “agile” or “Scrum” for a critical project, you can just avoid those words and talk about transparency, feedback, and that sort of thing.

  3. Ben Fulton says:

    I don’t think that’s true at all. All the time I hear, “It’s too hard to go back and write tests for all this code” and “We have to get everything designed up front so we don’t make any mistakes.” and “You should have thought of that at the beginning of the project, it’s too late now.” Transparency and feedback are alien concepts to a lot of companies _and_ developers.

  4. Hi Ed,

    I couldn’t find your email, but I included this post in the May 4th Carnival of the Agilists.

    Great job!

  5. Ed Gibbs says:

    Actually if we followed our official process we’d be reviewing the first draft of our requirements document now, with the final sign-off in about two weeks. Then the developers would have to write a second detailed requirements document and get that signed off. Only at that point could coding begin. Our process is a strange contractual waterfall adapted from EDS, so you can understand the pain points.

    Anyway thanks John for including it in a Carnival. I haven’t been to a carnival in years unless you count the California State Fair.