Come and join us for drinks, socialising and a special presentation
This will be a really informal session, with plenty of opportunities to ask questions and interact. If that doesn’t sell it to you, how about the FREE DRINKS??
Completing the circle: Automated web tests, ATDD and Acceptance Tests as a team communication tool
Acceptance Test Driven Development, or ATDD, has proven to be a very effective technique, both for driving and guiding development, and for enhancing communication between developers and other project stakeholders. But why stop there? Well designed Acceptance Tests can also act as a formidable documentation source and communication tool. Indeed, when written in a narrative, BDD-type style, Acceptance Tests have the potential to document in detail how the user interacts with the application.
In this talk we will look at the role of automated Acceptance Tests not only for testing, but also as part of the whole development lifecycle, from writing the user stories right through to deploying the application. We will also look at ways to make your automated acceptance tests more expressive and how to use them more effectively as a communication, reporting and documentation tool.
Finally, we will present and demonstrate a new open source library that helps developers and testers write automated acceptance tests for web applications using WebDriver/Selenium 2. This library also produces clean, narrative-style reports illustrated with screenshots that effectively describe the application’s functionality and behaviour, as well as any regressions or pending features.
CEO of Wakaleo Consulting, John is an experienced consultant and trainer specialising in Enterprise Java, Web Development, and Open Source technologies. John is well known in the Java community for his many published articles, and as author of Java Power Tools, and Jenkins: The Definitive Guide.
John helps organisations around the world to improve their Java development processes and infrastructures and provides training and mentoring in open source technologies, Test Driven Development (TDD, BDD and ATDD), Automated Web Testing, SDLC tools, and agile development processes in general.
A fascinating subject that should give you some great ideas and techniques to take back to your team.
This is our first joint event and we’d really appreciate your support. We’ve booked a big room and need to fill it! PLEASE BRING YOUR FRIENDS…
Thursday, June 23, 2011 from 5:00 PM – 8:00 PM (GMT+1000)
Combined Services Club (upstairs)
5-7 Barrack Street
(Cnr of Clarence, next to Officeworks)
Sydney, New South Wales 2000
So complete the free registration at: http://bettersoftwarebriefing.eventbrite.com
Centrum Systems will be sponsering Agile Australia 2011.
Agile Australia is going to be packed with case-studies of how leading businesses are adopting an Agile approach to stay ahead! As well as Agile dignitaries Alistair Cockburn and Martin Fowler, international Agile guru Jean Tabaka, and celebrated Australian industry author Rob Thomsett
- Learn how to respond quickly to change, minimise overall risk, improve quality, and enhance project outcomes
- Discover compelling examples of innovation and business value achieved through Agile
Please come to our stand and say hello…
Some not so good News
Its around 4pm on a Tuesday, we have completed our Review at the end of the third iteration and we are about to start the Retrospective in what is now going to be a four rather than three-iteration Initial Release.
Since starting the project – using Scrum for the first time – the scope has increased nearly 40%, the time frame has gone from 6 weeks to 8 weeks, the expected investment has increased by a third and two of the four person team have been put onto other assignments. To top it off the team’s performance this iteration has gone from a velocity of 31 points per “standard iteration” to just 10 points.
Reporting news like this to a steering committee or a project owner/sponsor would have many project managers bracing themselves as they stepped over the threshold and into the meeting room.
Inspecting and Adapting in Action
What’s striking about this meeting is there is a calmness to the conversations – there’s no upset, no raised voices, no withholds, no pursed lips or forcefully contained admonishments, no blaming, no looking for reasons, no CYA, no resignation. Just conversations about what happened and what there is to learn from what happened.
This is the Inspect and Adapt part of Agile practices applied to the Agile Practice itself in action and what was informing and shaping the conversations was what was being shown on the dashboard.
Two weeks later a very happy Product Owner takes delivery of the Initial Release, clear that the project delivered on time and within budget. At a company dinner a few weeks later colleagues listen attentively as team members share enthusiastically what it’s like to “really do Scrum”.
The team goes on to sustain this healthy productive collaborative environment through a further 5 iterations for a second release and the product is now in production serving the needs of the stakeholders with a very satisfied Product Owner.
The Power of the Dashboard
This experience really put a spot light on the power of a Dashboard to inform and shape conversations.
Informing and Shaping Conversations About What Happened
Between the first and second iterations the number of story points delivered in an iteration had increased by 50% whereas the effort invested over the iteration had decreased by 33%. One story had been added, two stories has been re-estimated and one story removed.
The dashboard made it easy for us to see the impact of this variability on the project’s budget, timeline and scope.
Something that was immediately obvious is we could see how the investment performance (as measured by the dollar cost per story point) had doubled between the first and second iterations.
Informing and Shaping Conversations for Time, Budget and Scope
However even with the increase in team performance, completing the release in three iterations looked doubtful. When the team raised slipping the schedule from three iterations to four for the same scope we got confronted by the way the dollars per story point increased by a third, and with that the conversations began to focus on how we might minimise the work required to get each story complete and thereby avoid slipping the schedule.
At the same time, everyone was good with increasing the number of iterations to account for a net increase in scope… when the product owner added a net 6 points to the backlog everyone could get why the number of iterations had increased by 1.
Informing and Shaping Conversations for Performance
Looking back its clear that something had shifted for the team… it was like everyone’s attention was now focussed on managing to minimise the dollars per story point. Managing for investment performance was a new context from which to operate and organise our thinking as a team.
And so when the team met at the third iteration review managing for investment performance was available as a context for interpreting the most recent performance. When we entered the numbers all the key performance measures for the iteration were impacted…
- Dollars per story point tripled
- Velocity was down by two-thirds
- Estimation variance also dipped
Informing and Shaping Conversations for Performance Improvement
As a team we could readily see the impact of committing to 3 stories, gong after 4 and delivering 2 on the performance measures. Which lead to the next question… What has been the impact on the overall project timeline and the budget and is this drop in the performance measures indicative of things to come?
The team put the drop in performance down to not paying enough attention to the conditions of satisfaction that the product owner had put into the stories… something that could be readily addressed in the retrospective as a lesson learned.
A Retrospective Free from Distractions
So when it came time for the third Retrospective the team got to engage in looking at what worked and what didn’t free from distractions about what had happened and what it meant for the project. And one iteration later…
…a very happy Product Owner takes delivery of the Initial Release, clear that the project delivered on time and within budget. At a company dinner a few weeks later colleagues listen attentively as team members share enthusiastically what it’s like to “really do Scrum”.
Being part of a new environment and meeting new people gives us a different perspective on things. Let me tell you how I rediscovered paper (as well as handwriting).
I have been practising Scrum and Scrumbut for a few years now and I always had an online tool to help along. Being guided by the “Go Paperless” slogan, I assumed that if it was online, it was simply better. In many cases, I can safely say that online is better but I recently rediscovered the joys of paper.
In my current project, where Scrum (and not Scrumbut) is practised, we started out by maintaining the product backlog, iterations, stories, tasks and burn-down charts in JIRA. The results were quite satisfying, especially since we have access to Geenhopper (Agile tab). But updating the task board during the stand-ups felt a bit unnatural and broke the flow somewhat.
In the next iteration, our excellent agile coach, Alex Bould, suggested we maintain a paper version of our stories, tasks, burn-down charts and so on. Being the open-minded and easy-going people we are, we gave it a go. The experience was surprisingly positive. The action of taking a card off the wall and putting it “in process” gave me an extra sense of ownership with regards to that card. I was not only reading it, I was also touching it. Maybe using more senses had a similar effect to enhanced understanding when reading something out loud. Furthermore, writing tasks on cards (making it legible took a few tries), adding up quarter-days and hand drawing the burn-down chart engaged my team just a little bit more than the online version did. Finally, being able to see the task wall along with the burn-down chart whenever we are in the office gives us a good sense of progression, not to mention that it is easier and cheaper to set up then higher technology versions.
An iteration later, we decided to go back to the online version to see how it compared with our new experience. Once again, the experience was good, but in the spring retrospective the team unanimously voted to revert back to the good old paper way, and we have not looked back since.
Disclaimer: It goes without saying that a few preconditions need to exist in order to adopt the paper way. Having access to a large wall is essential and having a co-located team really helps.