We experienced this on our latest project. Ironically, this was while building Serena Agile On Demand, a work management tool for teams (and teams of teams) using agile methods to create software! The team had been Sprinting together for quite some time. Probably in the neighborhood of 15 or more 3 week Sprints that included 3 releases to production of a SaaS product. As we approached the completion of the third release, we started getting pretty clear feedback from some team members that they didn’t really understand the product vision.
This perplexed some of us. We always maintain a product vision. We refresh it often, especially at the
beginning of the release. It’s not
a heavy weight document. It tends
to be about 15 or so PowerPoint slides that capture market, business and
product information. The product
stuff is usually high-level Use Cases, release themes, goals, and key
high-level features. We had
created these artifacts and reviewed them with the teams before every
release. And in fact, after review,
we agreed that the team actually executed against them effectively as
well. So we had a vision, we
communicated the vision, our teams delivered on that vision, yet they said they
didn’t understand it!
It took some discussion with the team, but we did get to what we believe the root causes were and took action to remedy them. Firstly, we now communicate vision early and often. Previously, we were doing the early part. Communicating vision to teams at the beginning of the release, but we fell short on often. Now we’ve formalized reminding the team about key elements of our vision at the end of each Sprint in the Sprint demo meeting. We’ve also employed corporate marketing communication tactics by posting release goals and themes in many of the public areas.
The second remedy wasn’t quite so obvious. While the team said they didn’t
understand the vision, they also meant they didn’t understand why certain User
Stories were so important or didn’t agree that others were the right User Stories. Part of this was that they “couldn’t
see the forest but for the trees”.
The teams do use “Story Time” for Sprint pre-planning. These meetings typically occur towards the end of a Sprint in preparation for the next Sprint. In Story Time meetings, the Product Owners bring candidate user stories and other items to the team for vetting and discussion. This allows the Product Owner to have more effective (and shorter!) Sprint planning meetings once the next Sprint starts. Story Time is a great tool for teams to use to improve User Story quality and make Sprint planning more effective and shorter but typically important planning discussion have already occurred where these Stories were decomposed from broader themes, goals, or Epics. In our case important people and important considerations were missed during the pre- story time elaboration.
Our solution was to introduce “Feature Time”. Peter Goubert, our Chief Product Owner coined the term. Feature Time is a regular (at least weekly) meeting. It will have one or more specific topics that will be discussed. The Chief Product Owner coordinates the meeting. Participants include Product Owners, software engineering leads (or architects), usability experts and others depending on specific topics. We try and keep attendance as compact as possible. The purpose of feature time is to look at course grained groups of features, Epics, and Stories and to understand and evolve the product design. Outputs include preliminary and revised Story backlogs, user interface mock-ups, and high-level domain models. These artifacts are used to translate the product vision into actionable work for the team. We also make participants in Feature Time “holders of the vision” and responsible for evangelizing the vision to their teammates.
Keeping teams focused and motivated is both challenging and rewarding. While agile and Scrum methods are great steps forward for building energy and momentum in application development organizations, practicing them at scale requires us to extend the agile toolkit a bit and we’ve found Feature Time to be an effective new tool!