With my last post here I passed the half-way mark in my ‘top ten’ responsibilities of product owners. Here I want to talk about number six on this list: good product owners talk with the designer, lead coder, and lead tester about what’s coming up in future sprints.
In the movie When Harry Met Sally, Harry Burns is explaining to Sally Albright that he truly has a dark side. “When I buy a new book, I read the last page first. That way, in case I die before I finish, I know how it ends. That, my friend, is a dark side.” While such an approach to novel reading may sound bleak, it is vital for the product owner to talk with the designer, lead coder, and lead tester about the end or goal of the product ‘story’ – even though the Agile development process assumes that somethings will change along the journey. There are a number of important reasons why the team needs to know what will be coming up in the development process.
1. Talking with the designer, lead coder, and lead tester about upcoming sprint work helps everyone understand what is being developed. Traditional models for software development might be content to have technical specs that simply describe what a proposed feature is supposed to do. The creative and collaborative process of Agile development recognizes that a fully engaged team builds better products when everyone understands the big picture of what is being developed.
2. Related to this idea, communicating with the development leads about future sprint work provides a valuable context for the features currently being developed. Knowing how the different components are designed to fit together and understanding how current development efforts will lay the foundation for future work which all culminates in a finished product helps the team collaborate around developing the whole product. Again, traditional models frequently result in ‘silo’ development where individual pieces are built in isolation and then hopefully fitted together in the end; Agile keeps the end goal of a finished product in mind along each iterative step on the journey, generating a more coherent result.
3. A third benefit of having product owners talk with the designer, lead coder, and lead tester about what’s coming up is that it allows initial questions to be investigated before the work needs to start. User stories that might be clear in the product owner’s mind may be less clear to the developers, or these stories may raise questions that the product owner had not anticipated. Waiting until the start of a sprint to figure out these questions only serves to slow the development process, while giving the designer, coder, and tester time to dig into the plan beforehand means that their initial questions will already be resolved. This in turn results in higher development velocity because the team does not stop development and look into questions at the beginning of each sprint.
4. Related to this, discussing upcoming functionality allows potential approaches to be vetted before the development sprint begins. Taking time to research possible avenues for solving a problem prior to when the work on the solution begins means some approaches can be ruled out and a good path toward the solution can be identified before the coders have to build the solution. The innovation that all members can contribute to the process is fostered by this kind of communication and planning before a sprint begins.
5. On top of this, knowing what things will be coming up in future sprints helps to make sure that the current features being developed are not architected in a way that would make this future work more difficult. Decisions are made each sprint that build a framework for how problems will be solved by a product; knowing what some of the future problems will be helps the designer, coder, and tester propose solutions that will not close off paths that will be needed later. No one wants to hear during the third month of a project something like, ‘If I had known you were going to need this feature a month ago we would have built the whole thing differently.’
6. All of these benefits to having the product owner talk with the designer, lead coder, and lead tester about both near-term and long-range plans for future sprint work support the final reason why this is important. These conversations and planning sessions allow the development team to hit the ground running when a new sprint begins. There is a natural rhythm to even short sprints that involves planning, iterative development and retrospectives; this rhythm works much better if the team is well prepared to launch into each new development cycle. Losing time because user stories were not well articulated is something I talked about in an earlier posting. Here I want to decry the way that not talking through future plans with the team can create roadblocks on the path to faster and better software development.
The folks at the Silicon Valley Products Group advocate what they call the ‘dual-track scrum’ in which each sprint consciously involves both working on planned development tasks and digging into plans for upcoming sprint work. The article at this link spells out some of these ideas well: http://www.svpg.com/dual-track-scrum/. Part of what makes this dual-track approach – and the whole Agile methodology – so valuable is its emphasis on the fact that innovation in product development comes from all members of the team. As scrum teams talk together about future sprint work, all parties have the chance to learn from each other about both the business and the technology elements of the project.
This dual-track approach can offer a great way for the product owner, designer, lead coder, and lead tester to provide a steady stream of fuel for the entire development team. Knowing where the project or product is heading and taking the time to investigate and plan collaboratively prior to the start of a sprint can keep the entire development process moving forward smoothly and provide added innovation as the whole team contributes to finding creative solutions. Of course, in truth it’s not that simple.