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.