Darryl Booth

2008 Year-End Wrap-Up

It’s been an extremely productive, busy, and exciting year.  Below are some of the highlights from the perspective of my desk… What were your highlights from 2008?

My 2008 Highlights

• Completed 12 EnvisionConnect Deployment Projects!
• Booked 21 Iterations of EnvisionConnect
• Delivered over 118 EnvisionConnect Online Training Sessions
• Completed Approximately 1,420 Product Backlog Items
• Delivered 17 New Named Workflows
• Hired Four Talented Folks in Client Services and Three Skilled Team Members in Development
• Implemented Scrum Across All Departments
• Hosted Successful Annual User Training and Conference
• Reviewed/Tuned Technical Support Processes
• Launched EnvisionConnect Resources Wiki (password required)

My 2009 Expectations

• More and More EnvisionConnect Deployment Projects!
• Tuned EnvisionConnect Iteration Schedule
• More EnvisionConnect Killer Features Including Multiple Page Layouts, Tabbed Interfaces, and Awesome Drop-Down Combo Boxes

Have a fantastic holiday season and a great new year!

Changing Seasons and Tuning Processes

As I write this entry, we're in the middle of Sprint Planning for our coming 30-day development sprint. The development team is behind closed doors.

More than any time in recent memory, this planning session required tough trade-offs. Part of the trade-offs were prompted by recent changes in our processes. I'll explain.

In previous development sprints, we generally offered a release at the end of the sprint. On the positive side, customers could choose to have early access to new features and bug fixes. On the negative side, frequent updates represent change and our capacity to absorb change is not unlimited.

In response to these conditions and customer feedback, our management and development teams collaborated to tweak the process slightly as follows:

There will still (generally) be a release available at the end of each sprint, but in most cases it will be a patch release. Meaning that it will only include bug fixes. The good news is that a defect can still be fixed by the end of the following sprint.

New feature releases (generally considered higher risk) will be announced with less frequency... perhaps once each quarter or less. Here's the trade-off... we have approximately 32 Product Backlog Items that represent functionality that customers identified specifically. In previous sprints, that work had the potential to be released at the end of the sprint. Under the tuned process, that work will be released as part of a subsequent sprint.

We believe, however, that this strategy will improve quality because patch releases have a smaller chance of introducing new defects (because the changes are targeted and specific).