several customers, several teams, and of course several users with which we need to co-ordinate our changes, and change plan. Again, much like with application development, the scrum of scrums provides the forum to do that. A representative discusses what happened last week, what's coming up this week, and most importantly what we're going to put in the way of our customers . While Engineering Services occasionally needs to affect product stability, or build expectations, the ripple effect can be felt across multiple teams.
Although the team most closely affected (i.e. the product developers and testers) might have “signed off, other teams may not be able to support a disruption of the planned sort. One great example of this is a shared component team, or product consumer. Perhaps, Project Management may have a time-line planned that doesn't allow for the planned disruption. The scrum of scrums provides a forum where cross-product (and if you're really lucky cross functional) teams can sit down and have these conversations.
Closing the Loop: Demo!
Our Engineering Services holds a demo of our work, at the end of each three-week sprint. We invite all of our customers to the same room (whether in person, or virtually) and work our way through all the stories, displaying and discussing the changes implemented during this time. This activity closes the loop on a story, and at the same time, provides an opportunity for the various stakeholders to learn about each others needs, based on our workload.
Unfortunately, many Engineering Services stories are difficult to show. Installer changes, code changes to the build system, these are all easy to demo; but infrastructure changes such as network rewiring are obviously difficult to show. For those stories, an Engineering Services team needs to mention what was done; there is nothing demo-able, unless you're lucky enough to impact build times!
One of the most common surprising outcomes of our sprint demo, was backlog stories. Having done some work for one team, another realized they could benefit from a similar investment, or had the same need. This approach has helped our team build credibility with multiple (geographically diverse) teams, as well drive future work and investment. While the demo helped close the loop story-wise, it also increased the amount of need, which is always a good thing.
The end of one sprint demo blends almost seamlessly into the start of the next sprint. We hold our demonstration the afternoon prior to our sprint planning and retrospective, which means that after the demo, I (as the Engineering Services product owner) groom the backlog. Usually I'm weeding out stories that we happened to complete, removing stories that no longer make sense, or most commonly ordering stories.
I'll also add stories, based on either the outcome of the sprint demo, or perceived need. Again, this is where VersionOne helps. We use VersionOne to manage our entire backlog. We use the Discussion tab frequently, to ensure that we can track emails, or conversations associated with a story. I use VersionOne to order the backlog prior to the sprint planning session, which ensures that all our data is available publicly, allowing anyone at any time to see what Engineering Services is up to.
After the sprint demo, I order the combined backlog, in preparation for the next day's sprint planning. Negotiations are help with customers (if necessary), with the goal of entering the sprint planning session with an understanding of the absolute minimum customers need. As a rule, we always aim to surpass that minimum,
Wrapping it Up