Agile Methodology Context
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.