Nov. 4, 2013



Some impressions


The quality of the speakers has been very high, I have attended almost all of the keynotes, and were all very well followed, and engaging too. I have learned that there are still a lot of people calling themselves tester, who are clearly willing to part themselves from the "developers", which I find particularly strange in an Agile environment. Shouldn't it be all about the team? Shouldn't the team be a peer to peer team, with no hierarchy and no roles? Developing a product in Agile means making it shippable at every iteration, and that requires all the skills needed to make it happen! Which ones? It depends on the context… every product is different, and requires different skills and people to be developed.

I have met a lot of people and I have also rejoiced with some old acquaintances that I helped starting the journey toward Agile in 2009… and now they had quite some stories to tell, great! Overall it seemed a very well organized event, with fun in the evening, the right mixture of talks, workshops and also Open Space. One thing I would definitely change if I were one of the organizers, would be to cut the talk length to 45m maximum, so there would be more talks, and probably some would be more focused, I include myself in the category.

My opening keynote writeup in some way…

How it all started

It all started about a year ago, when I was asked to prepare a keynote for the Agile Testing Days, after having presented at the Agile Dev Practices in the same year. I was pleased to be asked to have the opening keynote, and on the other side also a bit puzzled, as I am no testing expert, as many of you may have noticed. I have been developing software for a very long time, and I still do it for fun, but now my main focus is on an overall organizational perspective, and definitely a mixture of Agile, System and Professional coaching (who doesn't after all).

Still I am pretty much involved in supporting teams, and I can still teach ATDD, BDD and TDD to pretty much any programming language (well it is not about the language after all). So I had to think about what should I talk about, for 1h, one year ahead of time? How agile is that? Then I thought, maybe I should ask what sort of keynote were they expecting from me, considering that a keynote should maybe open a lot of doors to more specific and vertical talks, I was still unsure about the focus.

At the end it went a bit on the provocative side, well you can't really argue that testing isn't needed, or is a waste (as someone likes to say, and with whom I disagree). Testing is one of the activities required to create a product (software or not, doesn't really make a difference), and it is not just about the compliance of what has been done with the expectations, but is about creating confidence in the team developing the product, that they are pursuing the right objectives, that what they are building is going in the right direction. Still some people tried to convince me that their job as tester is to find defects, which are a sort of trophy, a demonstration that they have been able to break the product (or even more explicitly the work those "others" developers did).

Why? As far as discovering things which do not behave as expected, or even discovering new things that nobody had thought about, testing is a discipline which helps a team refining its targets, and learning. Once it becomes a self-fulfilling prophecy, it looses pretty much its purpose and also introduces various dysfunctions. One of these, is the one I have exposed in my keynote as the "Show me the money!" dysfunction. If you are Agile, you know what I am talking about probably, such behavior is resulting from a fundamental distrust in the team and in what the team is doing. If there is no trust, then there is no Agile, but trust needs to be gained, it is not something we can "expect" as a precondition (sounds like testing a bit). And here is where I wanted to emphasize that being Agile requires to develop a certain mindset, which in particular is reinforcing the attitude to trust results based on the fact that we can validate them.


Testing as an attitude

This might seems natural to many, but if you have been in enough messed projects in your career, you probably will remember at least one time, in which people didn't know exactly why they were doing what they were doing. And this is where the Agile mindset, strongly focused on results and goals, and allowing individuals to commit to achieve a goal, by allowing them to pull the work from a list of defined objectives (normally called backlog).

People start thinking about how would they know when they will be done, before starting to do anything. This attitude is required especially when working in complex contexts, where often isn't clear what is the end results you are trying to achieve, or even it is a set of options and you need to understand if you are moving within the expected range. To strengthen the attitude, you need to practice, but before you can practice effectively, you need to try some approaches and understand what works and what doesn't.


Testing as an approach

So let's think at testing as an approach to experiment different ways in which a problem could be solved. If you think this is reflected in any sounding Agile thing you might be doing already since quite some time, you want to know what are the "Acceptance Criteria" of a User Story before committing to do any work on it. And once you have it in your hands, the first thing you start doing, in order to focus, is to identify what are the possible acceptance tests that you can derive from those agreed "Acceptance Criteria".

Good teams at this point are already looking into automating, to be sure they are not wasting time in doing the wrong things, and to make sure there is a safety net, which will remind them to refocus on the goal of that story. As you may know it is all about shorting feedback loops, and the most valuable ones are the one you can shorten through the conversations with the Product Owner and the stakeholders, while defining what to test and how to test. Agile people do all possible things to visualize anything, because by visualizing, conversation can be more structured, and focused. This is a great approach too. Now the practices come into place, testing is full of practices.

Dan North (@tastapod) pointed out in his keynote, that there are at least 120 different testing practices that he was able to count in his experience, and decided to categorize in four quadrants (how comes are always four…) based on two dimensions: deterministic towards "random", and manual towards automated (you can read more about this in his keynote Accelerating Agile Testing). Practices are useless if they aren't supportive of the approach you are willing to adopt. Many people just adopt practices, such as TDD, because someone told them they are good, and they do not really think about the value nor the economical impact of doing TDD. Maybe they will eventually end up stopping doing it, because they won't see any benefit (just another cool practice isn't it?). Well, if more people would understand that TDD is about design of the software, and not testing.


Testing as a practice

This is exactly the approach that I was trying to highlight in my keynote, by explaining that Agile people might decide to approach the solution of a complex problem, by defining a set of tests which a possible solution should be able to successfully pass. This approach - writing tests first - is a well known principle of eXtreme Programming, and it is embedded with very fast feedback loops into the TDD practice.

So TDD is not about writing automated tests (that's the output) but is about discovering the solution to a complex problem, by means of limiting the solution space through the definition of tests, which the solution has to fulfill. This leads to a more clean and focused design of the software, aiming at solving the "problem" and happens much faster (this is the outcome), than if you would sit and think at the solution from the inside out.

Finally I have made some back references to System Thinking and the Theory of Constraints, to highlight the importance of the behavior that a particular system is producing. I have presented as an example the behavior a push system is producing: focused on individual, competition, and compliance, while a pull system is normally producing a behavior focused on team, collaboration and value (as outcome). So if you really have complex problems to solve, you need people who can work in the most creative, safe-to-fail environment possible. This will require discipline, will require courage, and commitment, all of which is based on transparency, respect and trust.

With this in mind, invest in building great teams, and lead by example, coaching them developing the right attitude toward Agile. After a while, and some failed approaches, they will eventually find out practices which are supportive of their intentions, and will become more productive over time. Also don't think you can sit on a bench and enjoy the ride, because the Agile mindset is rooted on continuous improvement, and that means, your bench will change shape, and move… probably every couple of weeks :-)

My Storify of the session.

Image of andreat

Andrea Tomasini

blog comments powered by Disqus
Image of andreat

Andrea Tomasini


Latest Posts

Exercise for Systemic and Relational Engagement Utilising The Market of Skills

Use the Market of Skills to get a visual representation of the relationships inside a team

Image of elrich.faul

Elrich Faul


Webinar on the Product Backlog

Join coach Magnus Kollberg in a discussion about the Product Backlog on Wednesday, December 18, 2019

Image of magnus.kollberg

Magnus Kollberg

ORGANIC agility series of webinars

Get ready for the ORGANIC agility webinars with industry leaders starting in January 2020

Image of andreat

Andrea Tomasini


A new CST in South Africa

Regina Martins is the latest Certified Scrum Trainer in the South Africa team

Image of peterhundermark

Peter Hundermark

Peter has worked with iterative and incremental software development processes since 1999, focusing on Scrum and Agile practices since 2006. In 2007 he started Scrum Sense in South Africa. He has introduced Scrum into scores of development teams locally and in Brazil. He leads certified Scrum training classes in South Africa and elsewhere. He is a Certified Scrum Coach and Certified Scrum Trainer.

ORGANIC agility makes impact in Croatia

Andrea Tomasini met with the Croatian Agile community to discuss ORGANIC agility thanks to our local partner CROZ

Image of marion

Marion Eickmann
