Tag Archives: Specification by Example

About Agile: New Class Schedule for Agile Testing in June 2015

New Training Schedule for Agile Testing Released 

The next batch of public training sessions from About Agile for the ICAgile Accredited Agile Testing course is set down for June and will be held in Singapore and in the Australian cities of Sydney, Melbourne and Perth.

You can book through EventBrite or contact us directly to negotiate better pricing for multiple attendees and avoid Eventbrite fees.

You can read about real benefits of taking the course by reading this interview with AgWorld from Perth.

We can also run the course in-house.  Please contact us if you’d like to do this and realize more savings over the public training.

Later in the year we will be releasing new ICAgile accredited courses focused on the Fundamentals of Agile, Agile Programming and Agile Product Ownership.  Special discounts are provided for early adopters of these courses.  Please be in touch if you are interested in these.

We have other courses available and in-house coaching whereby training can be rolled into a longer engagement and course fees can be reduced significantly as a result.  Please be in touch if you want to know more.


From an exercise in the course – students create an agile testing manifesto of their own


Agile and Efficient Requirements Workshop Tips

Agile requirements gathering is an ongoing task that occurs throughout the build of an application or project.  We never, ever, generate the full requirements up front as this assumes we have learnt everything.  This is hardly ever the case as we learn as we go as we get better at the domain we are working in and the feedback we receive from users.  It also means we don’t waste time on ideas that may not be needed. This great article gives more reasons as well. We must be careful to also focus on goals and avoid creating solutions (e.g. the system shall…) as we gather requirements.

One of the tools available to a team is the Requirements Gathering Workshop.  This is a focused and time-boxed activity to increase our learning and understanding of the domain.  Gojko Adžić has written about this quite extensively.  Other ideas like Deliberate Discovery and Feature Injection assist as well.  But for workshops Gojko provides solid reasoning.

I’ve summarized his thoughts on requirements workshops from his book Bridging the Communication Gap.  He builds on this in his subsequent book Specification by Example.  If you buy Specification by Example you can get Bridging the Communication Gap for free from Gojko.  This is a summary so don’t expect a full explanation here.  Hopefully you still find similarity in your own experiences and a reason to seek out Gojko’s pragmatic and useful books.

He also gives great training (from what I hear/read from Perth Western Australia – he’s in the UK).  I also include this in my course on Agile Testing for which this post is also a little plug for.

  • Diversity is an advantage.   Avoids GroupThink and embraces Wisdom of Crowds.  Diversity includes different roles, backgrounds and don’t forget the stakeholders.
  • Agreement should be reached within the timebox. Max 4 hours for a two week iteration.
  • Knowledge Transfer is key. It will allow suspect issues to be surfaced quicker.
  • Challenging of ideas is encouraged until agreement is reached.
  • Ok to come to a workshop with ideas – but they need to be critiqued.
  • Go to the source – avoid third parties and telephone game info.
  • Output are examples, not solutions. This will limit flow and is the wrong time to discuss solutions.
  • Examples are good, the most important output is Shared Understanding
  • Run Feedback exercises to measure understanding. Differences in feedback indicates misunderstanding exists
  • Common Language to avoid translation between business and technical jargon.  Use the language of the domain.
  • Not a Meeting and favour smaller workshops to remain focused
  • Not a Presentation – not how the system will work.
  • Open Discussion focussed on goals

Who can Facilitate – a role for a Business Analyst

Don’t have access a professional facilitator?  Got a Business Analyst?  Use them.  The role business analysis is transformed in an agile team.  No need to fear as a BA can provide constant and valued input at an increased level of effectiveness than in a traditional process.

The role is transformed from ferryman of information using the lowest bandwidth communication (documents) to a facilitator using highest bandwidth communication (human communication face to face).  Developers benefit from your valued input via the facilitation during the workshop, chasing down pesky issues, chasing greater business value. Because they don’t miss the vital points and aren’t subject to ambiguity and misunderstanding as before, you’ll have time to do this.

By automating the specification into an executable specification trace-ability is improved and tracking of progress is improved as well.  Costs come down and more value is delivered quicker.  Value can be created elsewhere (see the Pareto chart here).

Your confidence goes up and stress levels come down and rituals like CYAM are removed.

The role of the BA has a lot to offer in an Agile setting!  Here’s a great drawing from Lynne Cazaly summarizing the role of a BA in a talk given by Bernd Schiffer and Chris Chan.

Role of BA

Question the Goals

I’m putting together a course on Agile Testing and using Specification by Example by Gojko Adžić as one of the inputs.

In revising the text I just had to write about asking questions to obtain business goals rather than blindly following the requirements.  Gojko mentions this a lot in Chapter 5 – in fact it’s crucial to delivering the right thing.

I have some examples that vindicate this approach.  These are my personal examples.

1. Many years ago in the mid 1990’s I was asked to write a Visual Basic program for a system’s administrator.  The Software Development Lead had thought of the solution and asked me to do it.  Being the curious type I approached the sys admin guy and asked what he was actually after.  After hearing what I he wanted I suggested a much simpler solution that required batch files only and could easily be accomplished by himself.  Going past requirements and solutions and asking for goals in this simple example saved a few days work.  Not too bad but the manager looked somewhat incredulous… ooops.

2. This example was not such great result.  I found out much too late.  Here a project, from the early 2000s, costng $250K was created to ensure some legacy applications could run under the new OS Windows XP.  I thought that for the amount of people using it and the expense incurred this could easily have been hosted in Virtual Environments at a fraction of the cost.  Even keeping a few clunkers running the old OS would have been sufficient.  What’s even more appalling that the functions these applications performed were replaced by a new system that was currently being built at the time.  This solution was not in the interests of the vendor at the time who’d be focused on quarterly reporting and unfortunately the client was none the wiser to alternatives.  Too late on this one.  This reminds me of the example from Chapter 5 of the book – a 100,000 Euro rewrite was replaced with Citrix within a day.  Luckily in this case, the proposed rewrite was caught just in time.

There are actually more.  I’m sure there are more from others – I know I hear the complaints.

Gojko suggests asking how a solution is useful to provoke a discussion and prevent offending others – especially those in bigger organisations.  I’m reminding myself to do this as well in my previous blog article, Ask How (don’t say no).  However this is probably another malady that requires separate attention – something incorporating Peter Principle anti patterns.