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.

Having been officially adopting Agile from the top down approach for about 8 months now I was really surprised by a recent project kickoff meeting.

I just assumed that we’d be using our official Agile methodology on this high profile project. Some assumptions I made were:

• The two product owners, business analyst, project manager (ScrumMaster), developers, and QA tester all have prior experience on an Agile project.
• We have two months to deliver on the project with no wiggle room because it’s a regulatory project, so if we fall back to our old waterfall style we’ll likely fail.
• All of our official piloted agile projects have been successful ventures so far and viewed that way by their product owners.

I turned out to be on a different page then the rest of the room. There idea appeared to be that we would run this as a traditional project. Traditional for us means a sort of strange version of waterfall, but waterfall none-the-less. The problem is we could easily be weeks just getting the requirements in place in lengthy documents no one wants to read. (The system shall …)

I thought there was no way we’d allow for this, but it appears to be exactly what we’re going to do by default. So the question is how to fight this perception that Agile isn’t our default.

I fear that despite the pilot projects, many of the participants haven’t understood how powerful Agile is for just this sort of high profile, short deadline project. We’ve adopted pretty much vanilla Scrum up to this point so maybe they thought with 30 day iterations Scrum just couldn’t work. Given the timeframe I’d say we should be using maybe 1 or 2 week iterations. A truly lightweight process might be just a product backlog, a short planning meeting every week, daily standups and a short 30 minute review of the progress at the end of the week.

I’m not giving up though, maybe I can convince the players to hold an impromptu planning meeting tomorrow.

Sometimes, despite your best efforts you get forced to stretch a developer across more than one project. Johanna Rothman posted on this recently arguing that many managers just don’t get the difficulties of asking their people to multi-task. Sometime, I don’t really get a choice.

I’m very familiar with the pains of context switching since as a manager it’s often a part of my world. My day continuously involves getting pulled in to help review a prototype for a developer or talk a system admin giving us read access to log files. Since my job is to make my people more effective I can’t complain too much when I get interrupted.

Still things come up. Business owners request certain resources they emotionally feel are the only safe choice for a high profile project. As a development manager part of your responsibility is to work with your customers. If they are so attached to this opinion that you are unable to sway them, you’re forced to give them the resource they ask for even if it’s just to appear at meetings and help a bit with the coding.

Long term the customer should be convinced that the other developer who’s doing the bulk of the coding is perfectly capable of handling their high profile projects. Still in the short term you’re forced to split one of your developers across contexts and damage their own productivity. I haven’t found a better way to handle it, and in many ways I doubt I ever will.

Sometimes technical folks selling enterprise software can be so very honest. We had an IBM architect, of which they have many, mention in a presentation on SOA admit:

“This is not easy stuff to implement. You got a Ferrari but it came in boxes and pieces.”

I don’t know if we got a Ferrari. Considering we bought the Websphere solution based on feeling safer with a large application platform vendor versus going with a best of breed type solution, I doubt it will ever turn into a Ferrari. I’d settle for a Ford Taurus that actually did something out of the box.

And the bit about not being easy to implement, no kidding. As software development is swinging towards greater simplicity with open source frameworks, dynamic languages making a comeback, and even J2EE slimming down with EJB 3.0, enterprise vendors are still pushing complexity.

One unexpected bonus of implementing TDD in our shop came up this week. Mocks can be a development tool as well.

The situation is pretty simple, our legacy development environment is down. Since it is our main data source on the project in the past this would have left the team dead in the water. Turns out they’ve mocked all of the DAOs that return some predetermined data using Spring. No developer downtime at all. Of course they can’t turn over the current new code for testing by QA against the real legacy system, but at least they can continue on without interruption. They didn’t even really mention the mainframe environment being down as an impediment in the daily Scrum.

So mocks have come in handy not just for a lot more than enabling unit testing. If you have to depend on some flakey resource they can be a lifesaver.