Methodology Matters, But I Don't Fit Your Mold

 

I am in the process of a paradigm change for a project team I was recently assigned to.

I have discovered (once again) that methodology matters, but perhaps not in the way you are thinking right now as you read this.

What I Don't Mean

No, I'm not saying that Scrum or CCPM or Waterfall are "the" best method of managing projects.  When people start talking about how one methodology is better than all the rest, their perspective is often clouded with ideology.

What I Mean Is...

The processes you use to manage projects does matter.  Mostly, the project environment, team(s), and stakeholders will lead you towards a way of managing projects that is a hybrid of the well-known models out there plus lots of organization-specific pieces that you won't find in any manefesto or "how-to" book on project management.

My Example

For my example, I am working on a large federal contract with a small team who is responsible for 2 of the 8 or so subsystems within one segment of the project.  The project as a whole, and the individual contractors are using traditional waterfall methods and EVM, with multiple releases of the subsystems (a.k.a progressive elaboration).

My team has had experience with Agile methods in the past, and they love working that way.  So do I.  So.....

We have collaborated on a hybrid approach that uses some of the aspects of Agile (Scrum in particular) that we can gain clear value from while throwing aside some of the other aspects that just won't work well in our environment.

For process, we will be doing 2-week sprints with the standard major releases, product backlog, and sprint backlog.  We did our first sprint planning session today which went awesome, and we'll do informal retrospectives too.  We will have daily tag-ups for 15 minutes each morning to ask and answer the following questions:

1. What did you do yesterday and how much is left on those tasks?
2. What will you do today?
3. What worries or obstacles can you see currently or on the horizon?

For tools, I started with a Scrum template from Petri Heiramo from Digia and modified it heavily to fit our unique needs.  I added resource-loading capabilities to the template and other key pieces of functionality, including a tab which translates the Scrum-ish progress updates into a format I can easily update our main project schedule with.

Not Throwing Out the Baby, But Some of the Bathwater Must Go

We are not doing the standard software development you might see with Scrum. 

We won't have discrete releases at the end of each sprint, so we've thrown that part of the Scrum methodology out.  Instead, each sprint gets us closer to a major release with clarity of planning and the ability to respond to the changes we enjoy on a daily basis.  Our subsystems are almost entirely database systems, but they support and integrate with all of the other subsystems and so many changes in those subsystems impact us directly.

Which is why I'm also throwing out the idea of a sprint baseline (sort of).

We've decided that after the initial sprint plan is finished for a given sprint, I'll save it as a baseline but then a working copy of the tool will be modified on the fly, daily.  We'll remove and add tasks, adjust estimates, whatever it takes to respond to the constant changes around us.  We'll get better at estimating as time goes on, anticipating potential changes and rework coming from outside the team, etc.

So Agilists will say we're not doing "real" Agile.  And Waterfall enthusiasts may glare at us.  So what?  I've ensured I can meet or exceed expectations for advanced and short-term planning, and excellent status reporting.

We've worked out a promising process that meets all our needs and my team and I are jazzed about.

And I couldn't be happier.

Image:  Cookie cutters by G & A Sattler via Flickr

What do you think?  Got a comment on what I'm doing, or a story of your own to share?