Chapter 5 Deriving scope from goals |
75 |
Make sure teams deliver complete features
When: Large multisite projects
Wes Williams blamed the division of work for the problem described in the section “Understand what outputs the business users expect.” Teams delivered components of the system (in this case the domain layer and the user interface), which made it hard to divide the work so that they could discuss the expected output for each team with their customers. So they reorganized work into teams that could deliver complete features. Williams commented:
It took us about six months to put it to feature teams. This made a big difference especially in the sense that it removed some duplication, a lot of repeating, and a lot of rework. Fortunately, we already had a lot of tests that helped us do this. We did have to go back and add features but it was mostly adding—not changing.
When teams deliver features end-to-end, |
they |
can get more thoroughly engaged |
|||||
with |
business users in |
designing scope |
and |
determining |
what needs to be built, |
||
simply |
because |
they can discuss full features |
with the |
users. For more informa- |
|||
tion |
on |
feature |
teams, |
seeFeaturethe Team Primer.6 |
|
|
|
Even without high-level control of project scope, teams can still inluence what gets built by:
•Actively challenging requirements
•Understanding the real business goals
•Understanding who needs what functionality and why
The result will not be as effective as it would be if the right scope had been derived from business goals from the start. But this approach prevents unnecessary rework later in the process and ensures that the business users get what they need.
Further information
At the moment there’s a lot of innovation in this ield. True to the nature of this book, I’ve only written about techniques utilized by the teams I interviewed.
6 http://www.featureteams.org
76 Speciication by Example
Emerging techniques deserve to be written about, but that’s material for another book. To learn more about cutting-edge techniques for deriving scope from goals and mapping out the relationship between them, look for resources on these topics:
•Feature injection—A technique to iteratively derive scope from goals through high-level examples
•Effect mapping—A visualization technique for project scope through hierarchical analysis of goals, stakeholders, and features
•User story mapping—A hierarchical mapping technique for user stories that provides a “big picture” view
Unfortunately, there’s little published material on any of the emerging practices. As far as I know, the only published work about feature injection is a comic7 and the next best thing is a set of scans from Chris Matts’s notebook on Picasa.8 The only published material on effect maps is a book in Swedish with a poor English translation called Effect Managing IT 9 and a whitepaper I published online.10 Jeff Patton features a lot of great material about passive and reactive scoping problems on his blog,11 and he’s been writing a book on agile product design, which I hope will offer more coverage of this ield.
Remember
•When you’re given requirements as tasks, push back: Get the information you need to understand the real problem; then collaboratively design the solution.
•If you can’t avoid getting tasks, ask for high-level examples of how they would be useful—this will help you understand who needs them and why, so you can then design the solution.
•To derive the appropriate scope, think about the business goal of a milestone and the stakeholders who can contribute or be affected by that milestone.
•Start with the outputs of a system to get the business users more engaged.
•Reorganize component teams into teams that can deliver complete features.
•Investigate emerging techniques, including feature injection, user story mapping, and effect mapping to derive scope from goals effectively.
7 |
See www.lulu.com/product/ile-download/real-options-at-agile-2009/5949486 to download a |
|
|
free |
copy. |
8 |
http://picasaweb.google.co.uk/chris.matts/FeatureInjection# |
|
9 |
Mijo |
Balic and Ingrid Ottersten,Effect Managing IT (Copenhagen Business School Press, |
|
2007). |
|
10http://gojko.net/efect-map
11www.agileproductdesign.com
6
Specifying collaboratively
Speciication by Example is conceptually different from traditional speciication or testing processes, especially in the way it relies on collaboration. Speciication by Example won’t work if we write documents in isolation, even if we imple-
ment all the other patterns described in this book.
In Bridging the Communication Gap, I focused on large, all-team speciication workshops as the primary tool for collaborating on speciications. Probably the biggest lesson I’ve learned in working on this book is that the situation is a lot more complicated. Different teams in different contexts have their own way of collaborating on speciications, to the extent that even teams from the same group approach collaboration differently.
In this chapter, I present the most common models for collaboration on speciications, including big workshops, smaller workshops, and the most popular alternatives to workshops. This will help you understand the beneits and downsides of various approaches to collaborative speciications. I also present good practices for preparing for collaboration and ideas that will help you choose the right collaboration model for your team. But let’s irst deal with the question of whether collaboration is required at all.
In order to properly present an example of a collaboration on speciications, we also need to review a related practice: illustrating using examples. You’ll read an example of how a speciication workshop would play out in chapter 7, in the section “Illustrating using examples: an example.”
Why do we need to collaborate on specifications?
Specifying collaboratively is a great way to build a shared understanding of what needs to be done and to ensure that different aspects of a system are covered by the speciications. Collaboration also helps teams produce speciications that are easy to understand and tests that are easy to maintain.
77
78 Speciication by Example
According to Jodie Parker, failure to collaborate on speciications was one of the biggest problems when they started implementing Speciication by Example at LMAX. She says:
People just don’t realize how valuable a conversation could have been. Developers initially thought that testers aren’t interested in the conversations because they were technical, but testers could learn about how to interrogate the code base or they could advise on the potential impact on other tests or changes to the language. Testers also thought that they were too busy. You can only see how valuable this [collaborating on speciications] is by doing it.
Even with perfect understanding of the business domain covered by a software system (and I’ve never seen a team with that), it’s still worth collaborating on speciications. Analysts and testers may know what they want to specify and test but not necessarily how to organize that information to make it easy to automate and drive development—programmers will. Marta Gonzalez Ferrero worked on a project where the testers initially wrote all the acceptance tests themselves, without thinking of them as speciications. She says that, frequently, the developers couldn’t use such tests:
At the very beginning, testers were working on FitNesse tables and handed them over to developers. This caused problems because developers were coming back saying that pages weren’t easy to understand or easy to automate. After that, they started working together.
A failure to collaborate on deining speciications and writing acceptance tests is guaranteed to lead to tests that are costly to maintain. This was one of the most important lessons about test design for Lisa Crispin. She explained:
Whenever we had to make a change, we had too many tests [executable speciications] that we had to change. It’s hard to refactor when you have many tests. I should have paired with developers to help me design the tests. I could easily formulate the questions; I see what’s wrong. Testers knew basic concepts as Don’t Repeat Yourself but didn’t have a good understanding of the tools.
Because Crispin didn’t collaborate with developers on writing and automating executable speciications, she wrote too many speciications and they weren’t automated in a way that made long-term maintenance easy.