Disclaimer: None of the following quotes reflects any specific individual, company, agency, or person.
From Corporate Land:
Why on earth would you need or want to go to this Drupalcon thing? It sounds an awful lot like your just going on a trip on the company's dime! Can't you just learn this stuff from a book?
If you want to go, you need to pay for it yourself and take vacation time.
From Agency Land:
We can't really afford to send all of you, how about we give you a fixed stipend to offset the cost. But we do really NEED all of you to go. Who knows who might be there who is looking for a job that you might be able to recruit. So, you all need to go.
From Independent Contractor Land:
Dear Husband/Wife - Drupalcon just seems like an excuse for you to spend our travel money. Why should you get to go to [insert city here]? And twice a year? We simply can't afford for you to do this!
So, what is the return on investment by going to Drupalcon? How will your experience change over several Drupalcons? What are the best reasons you can give your employer and/or significant other why you should go?
The time has finally come. You can sign up for volunteer jobs and time slots You may have received an email if you signed up previously on the general interest form or you expressed interest through Mailchimp. Sign up quickly for the spots you are interested in!
How can you help? We need tote bag stuffers, power strip placers and strikers, help desk helpers, and room monitors. What's in it for you? Well, first of all awesome karma and the knowledge you are contributing to our amazing community.
Not convinced? Well, you will also get a nifty t-shirt that calls you out as one of the elite - an awesome volunteer!
How do you sign up? Fill out the form below or go directly to the signup sheet.
This post has become an annual tradition. Each year, I take some time to look back on the year - I reflect on the good and the bad. A couple of years ago, the sad events surrounding my leaving pingVision sent me down a path of starting a company and beginning work with Examiner.com. This year has really involved the maturing the Development engine at Examiner with a great deal of focus on process.
Examiner starting using Drupal 7 before it was much more than a twinkle in Webchick's eye. It was barely committed to HEAD and wasn't even barely close to being ready for prime time. After 1 year of officially having D7 released, Examiner.com started looking at its coded base and the length of time it was taking to upgrade its core to the lastest security release. Many of the forks were related to Examiner's need to have incomplete chunks of D7 working. This year we undid what we had done making core upgrades much simpler.
Being able to do multivariate testing became a high priority for the company this past year. Using Google Optimizer and some clever work from our theme team, multivariate and A/B testing became a reality. Being able to test different layouts and determine the relative success of each layout is a powerful tool in any Website's toolbox.
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 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.
That all said, I think the message is pretty good. You get a little history lesson on Project Management. I focus on Cowboy, Waterfall, and Agile. I talk about communication and expectations. The presentation then discusses, with quite a bit of detail, how our development process has evolved and where we are at this point in time. I'm really proud of the work we've done at Examiner.com - and I'm so very impressed by our team. Everybody has been involved in moving this football.
There are cats, manholes, fighter jets, pyramids, castles, waterfalls, ravens, monsters, wine, books, and just a little H.P. Lovecraft.
Thank you to Examiner.com and to Drupalcamp Austin for facilitating my sharing. You all rock. If you're interested in seeing my remarks - here they are.
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.
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.
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.