Drupalcon Munich is just around the corner. I'm busy revamping my presentation on Project Management, thinking hard about what I've learned since the last couple of times I've presented on this subject. The truth is, I'm constantly learning new tips and tricks from the people I work with. These days, I'm busy learning the styles of an almost whole new crew of folks. One guy, Morbus is a well known quantity.

My role at Trellon is somewhat different than what I was doing at Examiner. Examiner was leveraging my overall experiences and allowing me to take part in some strategic decisions - but wasn't fully making use of my experience since 1995 when I got into the crazy business of information technology. Strangely enough, my work in Technical Theatre was some of the best preparation for the Internet world. I'll write more on that another time.

In Munich, come to my session and learn why:

Here we go again! Drupalcon Munich is just around the corner - August 20 - 24th. That may seem like a long time, but for a veteran of organizing one of these events, I can tell you that the work is ramping up rapidly. All my best to our friends and colleagues over the pond who are, undoubtably, working like crazy. I'm looking forward to enjoying the next convention not being behind the scenes.

Agile Gymnastics and Timebox Tumbling - A Hybrid Approach

Over the last few months I've presented on Agile Scrum twice. Once, as one of the Drupalcamp Austin Keynotes and a second time at Drupalcon Denver with my good friend Stacey Harrison. The presentation evolved from one of the events to the next. I've continued to wear my presenter hat and am ready to do Mark III on the topic of Hybrid Agile Project Management.

Learn from the experiences of Examiner.com's team. We've done it all - cowboy, waterfall, extreme, and agile scrum.

Learn why...

• Waterfall doesn't always work
• Agile has a place, but isn't the holy grail
• Cowboy can kill the relationships you have with your stakeholders
• How "Fixed Scope" is a lie
• That a combination of approaches is the answer
• The Examiner team has carefully honed, updated, improved, and iterated its process for over two years. It continues to evolve, improve, and make development more consistent and predictable.

The next few days are like a timer counting down. Sometimes the conversations feel a bit like a NASA control room. We review and re-review our plans because this deployment isn't going to be a small one. It is likely in the top 3 in scope since I began over two years ago.

Day 12 - Testing

We started with Scrum, Scrum, Scrum, and Scrum of Scrums.

Testing continued on Day 12 - and all the while we continued to work through Product Manager user stories. Supporting artifacts were shared as well. This segued into the Project Managers reviewing points and starting to assign teams for the next timebox. For this cycle, we found that our story points were roughly double to the number of the points available for the next timebox. This requires a feedback loop with the Executive committee to prioritize completed set of user stories.

The Executive Technical Leadership Committee met where we discussed a variety of issues, successes, and follow ups from the prior week. This committee fulfills the role of a CTO.

Finally, I also reviewed a patent application.

Day 13 - Testing, Stories, and Horse Trading

We continued to work through user stories and test. We had a 90 minute meeting with the Executive Committee to discuss the priorities where some items were shifted lower on the priority list and, for intents, got knocked out of the upcoming timebox and into the next.

Testing is coming to an end at this point. Day 14 will be release day and so only the most critical items are prioritised to be addressed before we release. This means several status meetings throughout the day. In this timebox, we were still engaged with status meetings until later in the evening. This was partially due to a timebox that was 25% smaller than our normal 20 day period. It was also in part because we launched our new mobile experience transitioning from a third party, Verve, to an entirely Drupal based mobile site. This shift greatly enhances the user's experience on a mobile device by leveraging block logic from the desktop site and providing access to all Examiner.com content. The Verve experience was limited to the previous 30 days.

We Were Busy
Today was an extraordinarily busy day in the timebox. We're in the midst of attending to revealing defects in our current release, some fairly significant configuration work to support America Inspired, reviewing tons of user stories, writing user stories, and continued work on setting up JIRA with Greenhopper to replace our ticketing system.

The Scrums
The day started out, as usual, with three scrums that cover the work our three distinct teams are working through. The scrums at this point are less about the developers telling us what they've worked on, what they are working on, and what blockers they have and more about the QA team reporting on results that have come through testing. We do look at our story board spreadsheet to confirm that stories are either green or nearly green. We also make hard decisions on features that might not be ready for release in the time box. Those are noted and we socialise that news with stakeholders as appropriate. We're also looking at any stories that might be at risk and identify alternate plans for those stories. That might comprise a) deferring the story for completion in the next timebox or b) completing the work during the QA week or c) releasing the new feature partially. Finally, the project management team got together for a scrum of scrums where we identify any problem areas that might have emerged.

The last few days have pretty much been nose down to the grindstone coding like crazy for the development team. Days 5-9 were pretty much the same with a few exceptions.

Day 7
On this day the Epics and High Level User Stories were delivered and these helped define user stories that needed design artifacts. The project team started sifting through the stories to identify any pitfalls or problems. As the Technical Product Architect, I start to think really hard about approaches that we might be able take when we get down to the Drupal part of the implementation. Are there any contributed modules that might fit the bill? Sitting down with various Product Managers we began detailing how the product vision would technically be handled.

Day 9
Largely the user stories were delivered. As a team we really started doing a great job of reviewing individual stories. Certain members of the development team had their features code complete which opened them up to help review the stories that were being delivered. We started looking at wireframes.

During these two days, the Executive Committee were helping continue form priorities for the next Timebox.

Day 4 of a Drupal Timebox
Yesterday was the first day that the Examiner.com development team was really coding. That became conversations in IRC and the beginning of features being sent to code and theme reviewers. The spreadsheet that we keep our user stories in is starting to move yellow stories to green and the salmon stories are being turned yellow (white is uncommitted stories, grey is deferred, yellow are committed to being developed, salmon need more information, and green are ready for manual QA). This is the time when the developers really get their heads down and are working hard to complete the stories they have allotted in the time period available and work on the bug backlog.

In the first two posts in this series I wrote about the planning days at Examiner.com and how those planning days set up the beginning of the code sprint. I also discussing the ancillary activities that set us up for the next timebox - locking down the priorities for the next time box.

Today, Day 3, the coding portion of the sprint begins.

The scrums started out by reviewing the salmon stories (salmon are stories that still need more information to be actionable) in the Google spreadsheet. Each story, as clarified was turned yellow - indicating the team in committing to completing the effort to complete that work. After these stories have been reviewed and clarified, the different groups are tasked with different tasks.

The morning began with three scrums. Each scrum represents a practicing unit that includes:

Day 2 - More Planning

Day 2 of this shortened timebox was the second of our Technical Planning days. As I mentioned in my previous post, we have two half days of Technical Architecture/Planning at the beginning of the time box. We continued to review details on the user stories for this box and also tightened our estimates a little bit for remaining stories. We look at whether we need to write code from scratch, we can make use of community code, or enhance community code from the Drupal project.

We colour code our stories - white for not scheduled, yellow for scheduled and committed to, greeen for QA ready, salmon when we need more information, and grey for stories that we defer for future timeboxes. We re-reviewed stories from yesterday for which we needed clarifications. These visual queues make it really easy to scan the Google spreadsheet(s) and see the status of a given story.

Our story spreadsheet header describes the information we're looking to capture for hand off to the development team.

An Introduction to the Next 15 Work Days
I've been writing a lot about process lately. Examiner.com is one of the largest Drupal sites in the wild. It was migrated from Cold Fusion to Drupal - a process that began about two years ago.

The Examiner development experience has moved through a wide variety of styles, tools, and methodologies over the last two years. Through blog posts and presentations, a fair bit of information is being shared about how we operate. When I was in Austin presenting, a fairly significant number of folks asked specific questions about our "Generic Timebox". I wanted to answer all the questions, but ran out of time that afternoon.

For this timebox we are using a compressed time-line. Our normal interval is 20 days - in this case we are shaving off a week and making it 15 days because of the holidays. Still, all the elements that are in our normal period are reflected in this series of days making it pretty much perfect to (hopefully) answer the questions I was being asked.

In the previous post, I wrote a bit about the tools I've used in project management. This post is going to focus a bit on process and how one might assemble usage of the tools.

First off, if you work in a development shop - you really should devise a process that works for your team and stick to that process. As Malcolm Gladwell says, you need to practice any "art" whether it is ice hockey, singing, lawyering, etc for many hours to perfect it. Context switching between processes will disrupt your flow state and make it tough to learn efficiencies. That doesn't mean to say you shouldn't have retrospectives at the end of a development cycle to discuss what worked and what didn't work. However, you shouldn't alter your process specifically to please a client - it doesn't work.

If you work for a company where you are making improvements to the site, you should define a process and stick to it to provide predictability to your stakeholders. They want to know what to expect and when.