I was fortunate to attend Gojko Adzic’s Specification By Example training. Although I was familiar with the topic and the content of his book Specification By Example, I learn a lot. In this post, I will share insights around:
- How to build software right the first time.
- How to facilitate a specification workshop
- The secrets of great test automation
By the way you may have heard of Specification By Example through it’s other pseudonyms: Acceptance Test Driven Development, Story Testing, Feature Testing.
How to Build it Right the First Time (Zero Defects)
As illustrated in the diagram below, Gojko argues that the key problem in software development is a lack of shared understanding about what needs to be built. Language is imprecise and different assumptions lead to errors.
A powerful way to justify spending time developing specifications is that it takes much less time to specify the behaviour of something than to build it. If something takes a long time to specify, this is a clue that it will also likely take a long time to implement it. The secret is to ask good questions and keep the examples rather than trying to create a written specification. It turns out these simple, small steps save a lot of time.
When everyone – domain experts, developers and testers – all have the same shared understanding, software will be built right the first time. This is the most essential property of Specification by Example – having a shared understanding.
Whether or not you create automated tests is somewhat of a secondary concern. It’s a good idea for sustainable development, but not required to deliver correct software.
And best of all is that everything here will work with a waterfall team as well as an Agile one.
How to Facilitate a Specification Workshop
A big part of the training (which I recommend) was participating in a simulated specification workshop so that we could see how they work and learn how to facilitate such them.
The most important thing is to call it a “Specification Workshop” and not talk about tests or test cases or automation so that it is easy for busy business people to attend.
The diagram below illustrates the key points:
- Cycle between large group and smaller groups
- Look for differences in language, models as well as where there was lot’s of discussion and conflict
- Seek to converge on a shared model using a ubiquitous language
- Conflict is a sign that there is a business decision to be made.
Secrets of Good Test Automation
The final bits of wisdom came from reviewing real examples of test automation to determine how valuable they were.
- Have a concise description
- Have a clear model
- Use business language
- Show a clear connection between inputs and outputs.
This is true whether or not we automate them. Automated specs need to be readable for business folks.
The other key point is that the automation layer needs to be kept very simple – just wiring of the specification to the system under test (SUT).
How to Evaluate the Quality of Your Specification/Examples
There is a really simple test to see if you specification/examples are any good. But it’s scary.
Here is what you do:
- Hand the specification to someone and have them read it.
- Don’t say anything.
- Don’t say anything. (This is the most important step, so I am repeating it).
- Write down questions they ask – these are clues of how the spec can be improved.
- Looks for the “ah-ha” moment when they understand. If you don’t see this, then there’s something missing.
I am deeply grateful to Gojko Adzic for delivering such an interesting and engaging training. He is a master storyteller and has an immense collection of real-world examples. If you get the chance, I highly recommend this training.
I would also like to thank the Toronto Agile Community for brining Gojko Adzic here as part of Agile Tour Toronto.
Thanks also to my classmates who made our time together challenging and fun. And especially to Paul Carvalho for reminding me what testing expertise really looks like.
Guy Lawrence – former CEO at Vodafone – tells of an organizational transformation effort that is intrinsically tied to office renovation – he says: “Conventional offices and working is dead”.
A Simple Recipe: Death to cubicles and offices
- Buy everyone in the company a cell phone and a laptop.
- Remove all offices and cubicles. Open plan office with desks.
- Remove all personal material so that every day starts fresh
- People sit with the people they need to work with that day.
- Meeting rooms are just for meetings of 6 or more people.
- Build coffee shops in in the center of each floor to create a “buzz”
Innovation & leveraging Gen Y
The motivation for undertaking these sweeping changes is to have people from Generation Y (born after 1982) actually want to work at Vodafone. A basic requirement here is that the tools they get at the company are as good or better than what they have personally. Nobody wants to use an infrastructure that sucks but for Gen Y this is a real problem.
Gen Y work on a collaborative model and do not tolerate a dominant hierarchy. Their employee engagement score plummet and they quit in droves.
Subversion of Management Hierarchy
A central part of the plan is to put the organizational hierarchy in the background and push communication and decision-making lower down in the organization. Part of the idea of getting rid of offices is to reduce the power differential between managers and subordinates. Guy reported that 49 of his 5000 staff did not make the adjustment to this brave new world.
The net of all this is to create a place that can rapidly respond to changing events. To use open networks of communication to tap into people’s creativity.
Video of Guy’s Talk at Google
What About Teams?
I am curious about teams in this brave new world. Agile Software Development and many others observe that building stable teams is a great recipe for high performance. My suspicion is that this model would be further enhanced by having a clear role for teams.
Curious About Culture
One thing very interesting is that Guy is leading a cultural transformation without clearly outlining the culture of the organization the way many other great organizations such as Zappos do. Instead, he uses simple rules to subvert traditional corporate behaviour. I imagine that this type of transformation could be even more successful if accompanied by an explicit culture model.
What’s next? Rogers Media/Telco!
I have been involved with Agile at Rogers (based in Toronto) on more than one occasion and it is by and large suffering from the typical culture and bureaucratic challenges of any large organization. I have been wondering what hope there is for the organization to truly transform without top-level leadership in a new direction.
Guy starts at Rogers in December, 2013.I am truly delighted to see that he will take steps towards a people-friendly work culture. I am also very curious to see if he will be able to overcome deeply entrenched resistance to change. Go Guy, GO!
Once upon a time, I was visiting with a client that wanted to do a reality check of the planned ship date for the release. Here is how you can leverage the wisdom of crowds to get a accurate prediction for the release date in just 30 minutes.
Step 1: Get the team together
Call everyone over. Set up a meeting. Whatever. Aim to get all roles: product, dev, QA.
Step 2: Assess Understanding of Scope
It is a good idea to see how well people understand the scope of the project/release. This will tell you how much stock to put in their estimates/understanding. It will also tell you how much people are working in silos. On healthier teams I coach, everyone on the team knows the whole release scope and can walk people through it. It’s sitting on the wall in the team room where they can see it every day.
This team came up with about 6/10 where 10 = full understanding.
We can see that the team thinks it has an OK handle on the work.
Step 3: Confidence in the Existing Release Date
The next step is to ask the team how confident they are in hitting the release date. This team came up with about 5 wisonout of 10 where 10 = Yes, we will make it for sure.
As you can see the team is strongly divided between “not a chance” and “confident”.
Step 4: Estimate Time Remaining
The final question is where the real gold is: How many months before we will ship?
As we can see there are three votes for 5 months and three votes for 6 months. (Sorry, didn’t notice some of the 5 month votes were in the wrong place before taking the picture). Using Wisdom of Crowds, we can see that the release is about 5 months away. Not the 3 months that was expected. Bad news for sure, but good to know now.
Step 5: Conduct a Retrospective (optional)
While you have the team together, you may as well conduct a retrospective to identify what the team can do immediately to work more effectively. Chances are if a project is in bad shape, they cut retrospectives a while ago. You will need another 1 to 2 hours for this. In the case of the example client above, we did a retrospective and the team started acting on their findings immediately to turn their ship around.
Many organizations, even “Agile” ones do not like talk about inconvenient truths such as not making a release date. See: Red Pill, Blue Pill
Why Do We Need This?
You may be on a well-run Agile project. In which case, release forecasts are updated on a regular basis and tough decisions are made about scope and date. But many Agile teams still face the challenges of fixed scope + fixed date and the pressure that comes with it.
The team I was working with in this story was supposed to be doing Scrum but was in an ad-hoc mess that bore no resemblance to the Agile I know and love.