Set expectations:Real story of a software product development teamNot focused on a tool“Why” & “what”“How” in a follow-up deep-dive workshop
The Beginning:Strict waterfall processSpecialized people organized by their functionLong release cycles
PM’s goal was to prepare the specification document before the “specification freeze”.Working ahead of development.
Dev’s solely responsibility was to write code.No influence on product design => creativity in code (layers, patterns, abstractions for the sake of themselves).No responsibility for quality.
Fear of blame leads to over-specificationOver-specification leads to inconsistent and outdated specs as soon as development beginsInconsistent specs cause blameHow much business value does a complete specification alone contribute?
QA’s goal was to find and file as many “bugs” as possible in the rest of the time -> much stressHow much does a filed bug contribute to quality?How much rework does it cost?
Metaphor: Ivan Krylov‘s fable about a swan, a pike (fish) and a crayfish, who teamed together to carry a wagon. Despite of their good will and effort the wagon stood still because each pulled in a different direction.PM were flying in the sky, Dev drove the product aside, while QA slowed the product down by creating rework.
At that time we started to implement Scrum.It was the same waterfall, compressed to fit into four weeks sprints.It became apparent that we could not deliver planned business value while following old habits.Specification by example helped us to “invert” our workflow and made Scrum actually work.
The “Bridging the Communication Gap” book by GojkoAdzic was a breakthrough for me:The best way to explain and specify something is to provide examples;Software specification is a collaborative effort;QA is better involved from the beginning, thus building quality in, not verifying it afterwards.
So what is a spec?Why do we need one?What makes it good?
Although agile values working software more than comprehensive documentation, documentation is still an important function of a spec.Up-to-date documentation is costly.
Spec provides a foundation for validation.Automated validation is not the goal of specification.
The main function of a spec is communication of the product intent during development.Short releases prevent big mistakes in the end of the project, but don’t save us from doing smaller mistakes each iteration.Mistakes are rework.
We must preserve intent at least.
At best we aim to understand real business goals and derive the scope from them.
Spec defines not only what the product should do, but also what it should not.
Good spec is a lo-fi, just-in-time tool for transforming blurry ideas into crisp products.
This is an example of a specification by example.Who can spot a disambiguation in it?Nevertheless provided with examples this specification leaves no room for misinterpretation.Given this example, a team will further discuss the price calculation model, discount precedence etc.A critical mind will even ask, how a group is identified? Can two separate registrations build a group for a discount?This discussion is exactly what specification is for.This time is exactly right for this type of discussions.
Specification by Example
Specification by Example<br />and a journey towards it<br />Software Craftsmanship and Testing Camp,Germany 2011<br />Sergey Shishkinhttp://shishkin.org<br />@sshishkin<br />