Iteration Forecasting

So I was handed the project plan and the edict “Make the date or die!” (ok, not quite, but something like that). With such an agressive schedule, we needed to know that at any given step, we were headed in the right direction. At this juncture, the Agile methodologist in the audience would shoot his hand in the air, “ooo ooo me me, I know the answer” waving the agile manifesto in his hands. However, scrum recommends 1-month cycles, and extreme programming recommends 2-week cycles. Both of which would not provide enough feedback in the 1 month implementation time allotted (we had already eaten through the 1 month design phase doing mostly rampup). So, we decided on four 1-week iterations, mostly because it seemed like a nice round number, even though I couldn’t find much precident for it in the literature I saw (has anyone else seen 1-week iterations?).

Then we threw out the project schedule, and went back to the sponsor and asked “It’s been a while since the schedule was put together. Based on the WBS, exactly what high-level features do you need by the deadline?”. He gave us that list, each item having a relative priority. That in itself sounds like a typical 1-month release cycle you find in scrum. However, when we overlayed the feature-list on top of the four 1-week iterations, we ended up with what amounts to an iteration meta-plan: a forecast of what features would go into the upcoming iterations. Then, we honed down the details of the first iteration, and started executing.

It worked out really well for us for several reasons:

  1. Typically, agile projects focus exlusively on the release at hand, taking it on faith that the project sponsor or customer will push the right features at the right time. But when you’re dealing with stakeholders used to more regimented management approaches, that’s a big leap of faith. With all the deadline-sensitive features assigned to an iteration, everyone was confident we COULD meet the schedule.
  2. All the developers were fairly new to agile software development, and were uncomforatable putting off some of the internal quality issues that professional pride and crafstmanship demand be resolved. So for example, by knowing that integration between modules A and B was scheduled for week 3, they could sleep at night with the digital duck tape and bailing wire used to complete A and B individually.
  3. Because the team and the sponsor had a basic iteration template to go by, we saved time on our weekly release planning.

So by doing a simply hybrid of PMI’s “progressive elaboration”, and agile iteration planning, we made the deadline, everyone got paid, and I rode off into the sunset with the girl (in the minivan with the 3 kids, that is).

20 Years Of Agility: Reflections, Tough Questions & Surprising Answers

As we approach the 20th anniversary of the “Manifesto for Agile Software Development”, it’s time to ask some big questions: Are projects really any more successful these days? Have companies truly shed any of the bureaucracy? Are professionals actually feeling the empowerment we’ve been fighting for so long? And where are things headed in the next few years?

Leaders Lean Into Ambiguity

This past year has taught me one lesson over and over: people need clarity to do great work. Yet too often, we hesitate to be the ones to provide it. When the path forward is unclear, we hold back, waiting for someone else to step up. But here’s the truth: clarity...

YES, Racial Justice Matters at the Office

We are at an inflection point in the american conversation about institutional racism. As project managers, departmental directors, VPs, scrum masters, we have influence in that institutional system. Therefore, we have a professional obligation to create a safe space for our black and brown colleagues, during this crisis moment. Here are 5 things you can do to promote racial justice and equality at your office.