Component teams and Given, When, Then

[Lancer Kind]

If an organization has their teams working on components of a feature (rather than feature teams--yeah, I know this is a bad way to organize engineering but that's the current situation), then features are never completed by just one team but are the result of several teams and multiple sprints. On average, a feature takes 2-4 sprints of time, 2-4 component teams of effort. The sprint starts and stops are synchronized across the teams.

A specification by example in this environment means most Given, When, Thens (GWT) won't pass until the fruits of several teams' labor are combined after a few sprints.

How to do BDD in this environment?

One idea is:
One feature=one set of GWTs. Each Scrum team implements their GWT steps based on what end-to-end testing means for them. This results in each GWT may have one to many steps.

This delivers:
- Business domain knowledge as the GWT language is kept at a business level.
- Traceability/understanding/perspective of how team deliverables contribute back to the feature.
- Incremental test automation for each teams' functionality, each sprint.

I'd love to hear more ideas or hear about people's experiences in doing BDD with component teams.

[Gojko Adzic]

On Sun, May 12, 2013 at 3:31 PM, Lancer Kind <lance...@yahoo.com> wrote:

If an organization has their teams working on components of a feature (rather than feature teams--yeah, I know this is a bad way to organize engineering but that's the current situation), then features are never completed by just one team but are the result of several teams and multiple sprints. On average, a feature takes 2-4 sprints of time, 2-4 component teams of effort. The sprint starts and stops are synchronized across the teams.

A specification by example in this environment means most Given, When, Thens (GWT) won't pass until the fruits of several teams' labor are combined after a few sprints.

How to do BDD in this environment?

in a component team structure, the real danger is that the big picture gets lost and that people overcomplicate and overengineer, or on the other hand under-deliver so the thing does not come together. One solution I've seen work nicely (there's even a case study of that in the book) is to have a separate, "integration" team that is responsible for maintaining the specs and making them run as tests (including working with individual component teams on setting the interfaces for automation). different component teams then run technical tests depending on their coverage of a particular workflow, and component functionality. the integration team works on the big picture and coordination.

Having said that, from my perspective, it's always much more important to discuss how to define the examples (or GWT) than how to implement them. this tends to deliver a lot more value. once you have the right examples, the implementation follows. in the case I mentioned, a senior cross-team product group creates the examples together, and then divide the work technically across components. 

I also strongly believe that people should try to slice things so that each iteration produces something useful, otherwise the concept of iteration is being cheated. so if a feature takes 2-4 sprints, then in effect your sprints are of variable length and actually 2-4 times longer than you consider. Instead, I'd look into slicing work so that different teams actually do produce something coordinated that can produce reasonable feedback in a single sprint. this is much easier said than done when the division of components is on technical lines - try using this method, it might help: http://gojko.net/2012/01/23/splitting-user-stories-the-hamburger-method/

gojko