Day 1 at the PMI Global Congress at Amsterdam came off to a bumpy start. After 3 days of varying degrees of value at the PMI Leadership Institute Meeting, I was ready for a real dynamic conference experience.
Logistical Snafus
However, I learned rather quickly that WiFi was limited to 3 isolated hotspot. This meant that I really couldn’t Twitter the days events as they were happening. Furthermore, the A/V setup experienced problems at the opening session, the keynote, and the third slot. We had almost finished the first day before the staff seemed to have gotten the conference running smoothly.
Pecha Kucha Meets Agile
Matthias Petren of the Agile-minded Swedish firm LeadWay emceed the conference’s opening session, which happened to be a plenary session for Agile Project Management. The topic was done in Pecha Kucha presentation format, where speakers present 20 slides, using 20 seconds each for a total of 6 minutes and 40 seconds to get your point across. Think of it as “Lean Thinking for Presentations”. I’ve included an example for you below:
First up was Juliet Andrew from EMC/Conchango talking about “The History of the Agile Development. Second was Gabrielle Benefield who helped introduce Agile to Yahoo. She talked about “Agile Roles”, comparing Scrums 3 roles to RUP’s 27 roles. Next up was Petri Haapio of Reaktor Innovations, talking about “Agile in the enterprise.” where he addressed several misconceptions about Agile in a traditional organization. Finally, we had Bjorn Granvik, CTO of Jayway, a sister company to LeadWay, where he talked about Shock Therapy, which he said boosted productivity 250% for one of his teams and 400% for another.
After this blitz of four 7-minute presentations, the group then went into 4 breakout sessions, facilitated by each of the speakers. The breakouts were conducted in an Open Space format, and I ended up in a conversation about “when to do Agile”. There were 5 of us who realized that managers are often called upon to prevent a team’s failure. If they were to pull back, you’d experience some failure, and hear lots of excuses. However, we’ve all heard these excuses before, regardless of project setting:
- I’m too busy with too many projects: Agile emphasizes fully dedicated resources
- No answers to my questions: Agile emphasizes colocating a customer expert or representative with the team.
- The part that failed is not my job: Agile emphasizes team-based responsibility and commitment
- I had no idea we were in trouble: Agile emphasizes metrics around work-remaining vs. time-remaining, as well as daily standup meetings to surface issues
- That might be what I asked for, but it’s not what I need: Agile emphasizes a customer-commitment to short-term scope, with customer-flexibility on long-term scope.
It occurred to me that Agile provides (1) an accountability mechanism for surfacing excuses we already know and (2) a suite of best practices (e.g. Face to face communication) for addressing those excuses directly to improve performance. The PMs in the conversation really wished they could have thage degree of accountability and transparancy on their projects. They left in deep contemplation, thinking “maybe I really can use Agile on my project”.
Agile Part 2
After a mediocre keynote, the conference tracks started, including a session by Nathalie Udo and Sonja Koppensteiner for “An Agile Guide to the PMBOK Planning Processes”. Things got dicey when the presenters had to start without a projector. Later on, the lapel mic started buzzing, and the lights went out in half the room. One person cried out “I can’t hear what you’re saying, this is unacceptable”, and seemed ready to storm off to demand a refund.
Nevertheless, the Agile sessions made the most of the circumstances. After an intro to Agile, the ladies had the room breakoff into teams to do an exercise in iteration planning. My group of 4 was stumped by the assignment. “We have a backlog with priorities and estimates; what planning is left to do?” I tried to point them to potential risks/tasks/resources associated with the theoretical project to install solar panels, but to no avail. After 20 minutes of haggling over what we were to do, we were summoned back to the room to debrief our findings.
It turns out, we were the only ones to make zero progress. One team brainstormed the new feature of adjustable panels. Two teams drew a mockup. Another team realized the planning exercise was too big for the alloted time, so they split up to 3 sub teams for risks, tasks, and roles. Another team produced more concreate questions about priorities: “what if you have to cut down trees to get to sunlight?”. All the other teams made progress with their iteration planning, but my team was not able to get anwhere. Because of that experience, I realized that even within PMI, different teams have different tolerances for ambiguity. I may have been placed with a team wanting more details before doing anything. Other teams just blazed forward. Perhaps this is why some Agile teams demand Iteration 0, while others decry it as waste.
During Q&A, one attendee raised a very provacative question: “Aren’t you less Agile as you move further along into a project, because you learn most of what you need to know? Isn’t it then that you transition to be more lean, because you don’t need as much investment/waste as you did when you got started?” When the two Agile presenters admitted to being stumped by the question, the audience chuckled seemingly unaware of the Agile vs. Lean debates popping up on message boards recently.
Agile part 3
Nils Akervall and Arne Linder gave a session entitled “Applying Project Management Models for Agile Development”. Unlike the previous sessions, which were more interactive, this topic was straight lecture. Nils gave a 45-minute intro to Scrum, and Arne explained how he adapted an enterprise governance approach to his Agile teams. The content was okay, but it was hard to stay tuned in to a lecture format after such a long day. During the Q&A, they did make two comments that didn’t align with other speakers:
- “Yes, Agile is primarily focused on IT” – Sonja and Nathalie referenced Lean Thinking as an example of Agile principles being extensible outside of IT.
- “Yes, we may have oversimplified when saying you don’t need an architecture phase/team” – Julie mentioned the ‘tracer bullet’ technique that builds out a single feature to test each architecture layer, without building out each layer completely.
Whew, a long day of Agile stuff, and I actually learned a few things. Tomorrow promises even more.
{ 1 trackback }
{ 0 comments… add one now }