A journey to #agiletd (1)

Agile Testing Days 2011 – Potsdam

In October I started a series of posts on agile. For me there were three reasons to start writing those posts. First, I worked in an agile environment, second, I felt there had to be more to agile than its most commonly mentioned method SCRUM and third it was a way of preparing myself to go to the Agile Testing Days. Now that I have returned from the conference I would like to share my experiences with you in several posts. I am going to use the discussion  with Huib Schoots about going to conferences as a starting point to describe the social aspect of going to a conference. Other posts will go deeper into the content when I have digested the information bombardment.

Why should testers attend conferences?
My argument at the time  was: “Conferences typically are the place where you can learn the latest developments and opinions, submerge yourself into the testing mindset, confer with your peers, refresh your ideas and expand your network”.

Well at the Agile Testing Days this was absolutely true. But, and this is something I will have to be adamant about, this does not happen automatically. There are a few conditions to consider. Preparation You need to prepare yourself; for instance by knowing who the speakers are and what their subjects are. And not only to determine to which talks you want to go but also to ask yourself if it would be interesting to talk and discuss with them about it. Being Approachable Most of the speakers and delegates, as I have experienced, are very approachable and like to talk to you about almost anything. A conference can be so much better if you are open to this yourself and are courageous enough to step up to others and start a conversation. Look beyond the program Conferences, typically those that host different nationalities of speakers and delegates, do not stop when the talks are finished. Get together with the people you meet. Go out and have dinner with them, or get a drink at the bar. Why would you lock yourself up in your hotel room. A conference is not like a class room where you enter at a scheduled time and leave once class is over. Enjoy Go and talk about what you have on your mind. It does not even have to be about anything from the conference or testing even. There is great stuff to learn, great people to meet and lots of fun to have. And even if you think you have nothing to talk about there is a lot to gain by listening and watching the interaction. But I am pretty sure once you are there conversations will happen.

So what did I do?

Having said all of the above you might question how I fared myself. Well I started with inquiring who else, other than my colleagues (Frank Pellens, Huib Schoots, George Stevens and Robert Copoolse), was going to go the Agile Testing Days by sending out a few tweets on this matter. As it turned out there was a division between either the Agile Testing Days and with EuroSTAR within my followers. After some conversation Lisa Crispin and I agreed to meet on the Sunday evening before the conference. Now having set a date others would be able to join in. We ended up having a very enjoyable and entertaining dinner at Petite Pauline with Tamara Taxis, Liz Keogh  (Picture: Liz folding origami animals from Euro bills), David Evans, Stephan Kämper, Huib Schoots, Bob and Lisa Crispin and myself. Back at the hotel we went for another drink at the bar and found that several people that we as a group knew, like Michael Bolton, were to be found there also. So even before the conference had started I was meeting new people, talking to them and started a rolling snowball that would keep on growing during the rest of the conference.

Now that I had made contact and kept an open spirit I found myself getting to know lots of new and interesting people during the conference. Additionally I reconnected with people who I had met before and all of them added to my story of these Agile Testing Days. A story that enriched me and let me have much more content, context, depth and interactivity during the conference than when I had only gone there to listen.


One of the other highlights was something Huib Schoots and I organized. Having heard about lightning talks and rebel alliances at other conferences we kind of felt the Agile Testing Days should have something similar. And if it were to happen we wanted to be part of it. So what better way to ensure that than to organise one ourselves. We contacted the guys from Diaz-Hilterscheid and after some explanation we were allowed to rent a room at the venue. Shortly after we made an initial selection of people we would like to meet and that we knew were coming to the Agile Testing Days. In that mail we called our gathering the Potsdam agile Testers Session or PaTS. We planned to start with the people who reacted positively on our mail and would see who else would like to join us whilst in Potsdam. On the third day of the conference we (Rob Lambert; Rob van Steenbergen; Daniel Lang; Janet Gregory; Simon Morley; Brett L. Schuchert; James Lyndsay; Stevan Zivanovic; Jim Holmes; Bart Knaack; Lisa Crispin; Olaf Lewitz; Mike Scot; Jurgen Appelo; Thomas PonnetCecile Davis; Michael Bolton; Huib Schoots and myself)  got together in the TestLab, ordered some beer and pizza and started talking.

We started by making up a prioritized list of subjects of which we did the following:

    • What makes a good tester (Nice post on this by Olaf Lewitz); Quote by Michael Bolton: “To see complexity in apparent simple things And to see simplicity in apparent complex things.”
    • Manage / lead testers to become great; Qoute by Michael Bolton: “Learning does not stick if it does not sting a little bit.”
    • DEWT / Peer groups (DEWT = Dutch Exploratory Workshop on Test)
    • Acceptable level of risk

My following posts will be go deeper into the content or the conference and PaTS, but for now there is the following post by Jean Claude Grosjean; “Agile Testing Days 2011: Day 1 – What a fabulous day

Exercising agility

Sprint 0 – The idea

While getting in the mood for the Agile Testing Days 2011 in Potsdam I remembered  seeing a XP exercise sometime before. Essence of the exercise was to use the agile manifesto, its principles and to link them to development practices. This really felt as a great practical extension to my previous two posts on agile. Only trouble was that it had forgotten who wrote it so the exact steps were unknown to me. Also I remembered that it originally targeted an XP development audience and  that I felt that it needed some adjustment to be useful for (non-coding) testers.

At the same time I was getting ready to participate in the TestNet workgroup theme night with the Agile Testing workgroup. While e-mailing with the workgroup chair, Cecile Davis, I offered to use a recreation of the exercise suitable for testers and to translate the manifesto and principles into Dutch along the way.

Sprint 1 – Proof of Concept

At the following meet the other workgroup members liked my idea and draft version of the exercise. So at the TestNet workgroup night on November 8 I have presented and executed the exercise in front of some 30 people.

All in all the execution of the exercise was a success and I received positive feedback. Several participants were interested in doing the exercise with their team. But personally to be honest I quickly saw after the introduction that in spite of the good idea the six exercise steps I had written were not going to work with such a large group. So the exercise was saved by improvising, getting some goodwill and by offering additional explanation during and after the execution. Also I discovered that trying to keep it inside the period of an hour was a real challenge.

In good agile tradition I concluded the evening with a retrospective. Combining feedback from the participants with my own feedback I put new items on the (virtual) backlog. First one was to write this post, second to do a re-write of the exercise in general and thirdly to make an adaptation of the exercise steps in order to make them suitable both for smaller and larger groups. Both the content and the ‘new’ exercise steps of the exercise will be part of the following sections. The Dutch version, containing I believe the first complete translation of both the agile manifesto and the principles, will be placed on the TestNet ‘Agile Testen’ workgroup page [TBD].

Sprint 2 – The exercise (published version)


  • Large separately printed sheets of the agile manifesto and the twelve principles
  • As many  A4 / Letter print outs with the practices on them as you have participants
  • Post-its or similar
  • Markers
  • Introductory presentation about the agile manifesto, the principles and the practices
  • Know what you’re talking about
  • A room with possibility to form groups, walk around, and hang the print outs on to the wall.

Step 1:
Give a (short) presentation on the Agile Manifesto and its principles.
Depending on the agile experience of your audience this can be shorter or longer. Check my previous two posts for to get additional information or inspiration.

Step 1B (small groups):
Group members discuss what the principles mean to them and how they map to the Agile Manifesto.
Depending on the time you have and on the familiarity of your audience with the Agile Manifesto you can spent longer or shorter amounts of time on this. In larger groups this tends to take a lot of time and is probably best added into the step 1 presentation or left out all together.

Step 2:
Present the practices and handout a hardcopy version of them to all participants.
Depending on the experience of your audience (and the time you have) you can provide information about all of the practices (takes a lot of time), or let the audience indicate which ones need to be elaborated or skip explanation al together.

Step 3:
Have the group go up to all of the principles and have them discuss  and map the practices that they think fitting to the principle. Mapping should be visualised by writing the practice on to a post-it and sticking it to the top of the sheet if it is a good fit, to the bottom of the sheet if it only fits partially.
The group should form a consensus on the which practices fit and to what extend. The aim here is to learn by actively linking practices to agile principles by discussion and argumentation. When necessary the facilitator should provide additional information and elaboration about the practices. 

Step 3B (Large groups):
Divide the audience into smaller groups of no more than 6-8 people. Then execute step 3 by letting them go by all principles from a different starting point.
To aid the visual result you can hang multiple versions of each principle (as many as you create groups) next to each other and differentiate the groups choices in this way.

Step 4 (Large groups only):
Have each group pick one or two of the principles and let them explain why they chose those practices and why they placed them higher of lower on the sheet. The other groups should be able to ask questions.
This step is more about sharing information and reasoning then that it is about argumentation and justification. A single group will have done this automatically during the exercise.

Final step:
Have all members evaluate what they have learned and taken away from this exercise. One of the take aways should be to pick one or more practices that they are going to actively work on during the next period. Then execute a (quick) retrospective on the execution of the exercise.
Depending on the group size and time you have left this can be down by letting each member express this to the group or to let them do this individually later.

The agile manifesto, the principles and the practices

To conclude this is what it is all about. Starting of with the practices:


A practice is something that has proven to be valuable in a certain context and offer insight into solutions that may or may not work in your situation.

You can do this with the list below for a start. But preferably create you own shorter, longer or more suitable list. Basically you can do this with any kind of practices not just test related practices.

  • Manage risk
  • Execute your project in iterations
  • Embrace and manage change
  • Measure progress objectively and understandably
  • Test your own test cases
  • Leverage test automation
  • Team change management
  • Everyone can test (and owns quality)
  • Understand the domain
  • Describe test cases from the user perspective
  • Manage versions
  • Co-locate
  • Leverage patterns
  • Actively promote re-use
  • Rightsize your process
  • Continuously reevaluate what you do
  • Test Driven Development
  • Concurrent Testing
  • Pair Testing
  • Specification by example
  • Acceptance Test Driven Development
  • Plan sustainably
  • Stand-up meeting
  • Plan in relative units
  • Configuration management
  • Learn by doing
  • Whole team approach
  • Shared Vision
  • Use Case Driven Development
  • Risk Based Testing
  • Evolutionary (Test) Design
  • …..

The agile manifesto

We are uncovering better way of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • Continuous attention to technical excellence and good design enhances agility.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Remembered who the original exercise was from: David A. Koontz

A journey to agile basics (part 2)

In part 1 of my journey to agile basics I travelled back to the Agile Manifesto and its twelve principles. In this second part I will make a small tour to each of the seventeen attendees of the original meeting.

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Dave Thomas

How and why they met is briefly explained at the Manifesto itself, so I will not go into that further at this point. A few of the authors have written a recap of events at the manifesto meeting and where ever I have encountered them I have added them here too.

Some of the authors I had heard about at conferences, read work written by them or have seen them mentioned by others. But for quiet a few of them it started of as a journey into the unknown. As I travelled further I found that for some of them their work obviously spoke louder to me then their name. I might not have heard of recalled their name, their products or ideas I did recognize, appreciate and use nonetheless.

My approach to the overview of authors is that I present them in alphabetical order. I tell something about what the are doing  and for what they could / should be known. If possible I will provide links to those particular items providing possibilities for you to dig in deeper yourself.

Although the trip proofed to be taking a bit longer than anticipated I really enjoyed myself and I can only encourage you to have a go at the material yourself and treat this blog as a starting point for your own journey.

The authors

Kent Beck

Kent Beck is a software engineer. He is the founder and director of Three Rivers Institute. He is the creator of Extreme Programming (XP, 1996) and has rediscovered Test Driven Development (TDD).

Kent Beck typically is not known to be a tester. Most of his work is oriented on organizing development processes and teams. His ideas on this have had a visible impact on how agile teams are seen today. He has emphasized embracing change, stressing customer satisfaction, customer participation and the use of feedback. Testing is as such is recognized but limited to what I would call development testing (or checking). In short he sees testing as:

  • All code must have Unit tests
  • All code must pass all Unit tests before it can be released.
  • When a Bug is found tests are created before the bug is addressed (a bug is not an error in logic, it is a test you forgot to write)
  • Acceptance tests are run often and the results are published

Mike Beedle

Mike Beedle is Founder and CEO at New Governance and e-Archtitect. He also is, together with Ken Schwaber, the co-author of the first Scrum book, Agile Software Development with Scrum. Scrum has probably become the most popular agile method. Over the years Scrum has gotten many supporting organizations, training facilities and lately even certification has come available.

Arie van Bennekum

Arie van Bennekum joint the conference as a member of the DSDM consortium. Arie van Bennekum started with working on RAD, followed by DSDM and is currently more involved in Atern. He provides a nice introduction to Atern on his website (in Dutch).

Alistair Cockburn

One of the authors I had not heard or read about outside of the manifesto, kind of rang a bell and turned out to be quiet interesting. Alistair Cockburn was an advocate of the use of use cases. Later on Alistair Cockburn joint an initiative similar to the manifesto: “The declaration of interdependence for modern management”. Which declares the following:

“We …

  • increase return on investment by — making continuous flow of value our focus.
  • deliver reliable results by — engaging customers in frequent interactions and shared ownership.
  • expect uncertainty and manage for it through — iterations, anticipation and adaptation.
  • unleash creativity and innovation by — recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
  • boost performance through — group accountability for results and shared responsibility for team effectiveness.
  • improve effectiveness and reliability through — situationally specific strategies, processes and practices.”

Finally Alistair Cockburn has described a group of lightweight methodologies in the Crystal family.

Ward Cunningham

Ward Cunningham is known for contributing to OO, Paterns and Extreme Programming (together with Kent Beck and Ron Jeffries). Ward Cunningham is however best known for his invention of WikiWikiWeb, better known and used as Wiki. Testing wise Ward Cunningham is known for his invention of the Framework for Integrated Test, a.k.a. Fit, an automated, open-source, tool for user tests. Fit is often used with a third-party front-end Fitnesse.

Martin Fowler

Martin Fowler focusses on understanding how to design software systems ( Patterns, Refactoring, Domain Specific Languages) and on promoting agile approaches. On his website he has a fairly nice recollection of the meeting in Snowbird in which the Agile Manifesto came to life.

James Grenning

James Grenning is a name I actually did not recall from before writing this post. But he was the first on which the initial (alphabetical) search results turned something about software testing: “Test is not about finding bugs“. James Grenning applies agile development to the embedded world. He is an XP coach, but his biggest contribution to agile is the invention of Planning Poker. Personally I find his blog, after reading several posts very entertaining.

Jim Highsmith

Jim Highsmith is the creator of Adaptive Software Development embodying the principle that continuous adaptation of the process to the work at hand is the normal state of affairs. On contrast to the other authors (so far) Jim Highsmith is more about project management and team work than strictly programming. Together with Martin Fowlers he works at Thoughtworks Inc. and was co-author of the earlier mentioned Declaration of Interdependence.

Andrew Hunt

Andrew Hunt co-authored the The Pragmatic Programmer and together with Dave Thomas founded the Pragmatic Bookshelf providing a series of books on software development amongst were books about the Ruby programming language. In one of his blogs I found the following rules, derived from Improv:

Rule one, agree.  Don’t reject current agile practices, but don’t accept them as written in stone either. What constitutes your current set of agile practices isn’t “done”: it’s not finished, it’s not established as canon, and it never will be. 
Rule two, add your piece.  It’s up to you and the rest of your team to evolve your agile practice, to keep it alive and keep it moving.

Ron Jeffries

Ron Jeffries is together with Kent Beck and Ward Cunningham one of the founders of Extreme Programming. His website is very informative on XP and its core practices. (Do not be fooled by the shortness of this item and visit the XP website!!)

John Kern

There is not a lot of typical information on John Kern. I suppose a good introduction is supplied by his recollection of the Snowbird meeting. In addition his blog provides a nice introduction to Ruby.

Brian Marick

Over time Brian Marick has gradually shifted from software testing to a more on general development oriented approach and is currently focussing on Ruby. He was at the time of the Agile Manifesto one of the (few) software testers present.

Brian Marick has an old and a new blog that are both worth visiting. The old blog did have slightly more focus on testing whereas the new blog is more about agile development with a focus on how testing fits in. The old blog also has a good introduction on agile testing with a series of links to interesting blog posts. Most noteworthy, to me, is the test matrix that Brian Marick developed that later on also was successfully used by Lisa Crispin and Janet Gregory in their book Agile Testing.

Robert C. Martin

Robert C. Martin also known as Uncle Bob Martin is a software consultant and author. Robert C. Martin is well-known for his books on agile software development, e.g. Clean Coder, and as a leading member of the software craftmanship approach that produced the following manifesto as an extension to the Agile Manifesto:

As aspiring Software Craftsmen we are raising the bar of professional
software development by practicing it and helping others learn the
craft.  Through this work we have come to value:

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

A nice anecdote the at a keynote for the Agile 2008 conference Robert C. Martin added a fifth value to the Agile Manifesto; “Craftsmanship over Crap” which he later changed to “Craftsmanship over Execution”.

Steve Mellor

Stephen J. Mellor is known for his books on Essential Modeling Techniques and Executable and Translatable UML that was derived from Schlaer-Mellor method.

Ken Schwaber

Together with Jeff Sutherland Ken Schwaber formulated the initial versions of the Scrum development process and are authors of the definitive Scrum Guide, of which recently an update version became available. He is a founder of the Agile Alliance, and he is responsible for founding the Scrum Alliance and creating the Certified Scrum Master programs and its derivatives. Follow Ken on his blog to see what his opinions on the development of Scrum are.

Jeff Sutherland

As mentioned previously Jeff Sutherland works closely with Ken Schwaber. Ken and Jeff formalised the Scrum development process at OOPSLA’95 in the Scrum Paper of which an updated, 224 pages, version is available. Additionally this article is available on his blog and explains where the idea came from. Jeff is very active in providing training and you have ample change to meet him in this capacity.

Dave Thomas

As mentioned before Dave Thomas co-founded the pragmatic bookshelf and wrote the “The Pragmatic Programmer” together with Andrew Hunt. They also went on to write about the Ruby programming language in the book Programming Ruby and Agile Web Development with Rails, a book on Ruby on Rails which also touches on Ajax and the Ruby programming language. Dave has also coined the phrase ‘Code Kata‘.

This concludes my visit to the authors of the Agile Manifesto. In part three of the blog I will visit some of the other authors / persons that I have found noteworthy since I have gotten interested in agile.