Go Agile for the bigger picture: Act 2

explore-assurity 8 July 2013 Adam Howard

In Act 1 last week, I talked about how, at Assurity’s recent company conference, a band of intrepid software testers and novice filmmakers gathered together and formed a small cross-functional cast and crew – the first step in an agile filmmaking journey.

Today, we continue the exploration of our quest to create a ‘mockumentary’ film that conveyed Assurity’s cause and look at how we used group estimation and some of our context-driven testing techniques to develop our Assurity Oscar-winning screenplay.

As with many big software development projects, the set of requirements was pretty extensive. In fact, hand such a list to a big budget Hollywood director and you would likely see them throw their hands in the air and declare themselves “unable to work under such conditions!” However, we didn’t have such an egotistical director… we had 10!

Our film was to be a ‘mockumentary’ called The Blair Pitch Project – but it also had to convey Assurity’s core values. Not an easy marriage. Everyone had their own ideas on how we could parody the original material and their own suggestions as to how we could use the genre to convey Assurity’s mission. And they all added value.

In the end, we had to decide as a group how to get the most value out of the ideas we had. We knew we couldn’t include all the suggestions. After all, this was a four-minute movie, not a Titanic style epic. So we engaged in an impromptu and unplanned session of group estimation to select the most effective ideas.

Group estimation is a technique which enables the whole team to come together and estimate the amount of effort a certain piece of work will take. It means that you quickly get a collaborative view of how complex people think a piece of functionality is and how long they think it will take to deliver.

The idea is that each item of work in the backlog, or each piece of functionality that the project wants to deliver is estimated for, with representatives from each area of the project team – the business, the developers, the testers and whoever else – all involved. And all getting an early sight of the scale of the tasks ahead.

If there is disparity between the estimates, then the group discusses why the different estimates have been made and then, more informed, re-estimate. This process continues until each work item has an agreed estimate from the entire team, meaning everyone is on the same page and generally understands the scope of the work and the effort required.

These estimates, along with the prioritisation value given to each work item by the product owner, can then be used to plan which pieces of work will be tackled first – or which pieces of work may not make it into a project if the effort required to deliver everything is more than you have available.

When it came to making our film, we achieved this in a fairly ad hoc way. But the process was the same. Each idea was discussed and each of us, with our different roles, suggested how long it would take to achieve. If we wanted to film a scene on a hill overlooking the forest, it would take 45 minutes to trek up there!

In conjunction, as we were all essentially joint product owners for this venture, we weighed the estimates of the effort each idea would require to pull off against the value it would add to the picture as a whole. That hill shot? It didn’t make the cut, because nearly a quarter of our allotted time for a dramatic panning shot simply wasn’t worth it.

Once we had marshalled our backlog and trimmed the fat, it was time to delve a little deeper. We were going to be working in separate units – multiple film crews, an editing team and roving cinematographers and set designers. As such, we needed to make sure that everyone had a clear picture of what we wanted the finished film to look like.

At the same time though, we didn’t have the time to sit down and write out detailed dialogue for every scene in the movie. On top of that, we didn’t really want to – because if we wrote out a script, it would simply restrict the natural comedy and improvisation that would surely develop when the cameras were rolling.

So instead of scripting our dialogue, we merely storyboarded each scene and wrote a few rough outlines of what the characters would do and say. By this point, we knew pretty much what the film would look like and we really just wanted to take the characters and the plot and explore them to see what extra value we could find.

This reflects a testing technique that is not strictly agile, but is certainly a way to add value to your project (and will definitely fit in an agile environment). Instead of engaging in detailed and time-consuming scripted or ‘factory method’ testing, you may find more value in engaging in a context-driven approach to testing.

This approach is less restrictive and allows the tester to take a more exploratory approach to their testing. They will set a charter or objective to guide their activities and will have an idea of what it is they want to validate through their efforts, but their testing is more guided by their experience and instincts and so can uncover a wider range of information about the product.

What’s more, this is often a faster and cheaper way of testing as it enables actual testing practices to begin earlier, shortening the feedback loop for the product. Testing in this manner is best paired with a modelled approach to test planning. We often use mind maps to visualise the system quickly and ascertain the amount of coverage required and any key relationships or inter-dependencies.

While making our film, we were strapped for time and resources, so this approach was great for us. Our storyboard acted as our visual model of the film and we were then able to let our instincts guide the actual filming process. This enabled us to seize some great moments of improvisation – such as a feigned argument between our leading actors – that we would never had captured had we had a script to follow.

So we were nearly ready to roll the cameras. In an hour, our small, cross-functional unit had collectively prioritised and estimated the effort involved in realising the distinct parts of our vision and visually mapped the overall journey we wanted our film to document – thanks again to the implementation of specialist agile and testing techniques.

Check back next week for the final part in this series to see how we keep it agile when the cameras start rolling…

You may also want to read

explore-assurity

Assurity officially recognised as provider of Scrum.org training

As a member of the Scrum. org Professional Training Network (PTN), Assurity is officially recognised as a provider of Scrum.

More

explore-assurity

Explore the future of analysis at BA Development Day

BA Development Day will take place on 17 November at Shed 6 on Wellington’s Queens Wharf with the theme of...

More

explore-assurity

Turning a single JIRA status column into a Scrum board

On a recent assignment, I was responsible for testing changes in a System Integration Test (SIT) environment.

More