Agile Testing Days Website
On the final day of the Agile Testing Days my presentation was due. Since it was my first conference presentation ever, I was very stagefright about the course. Though, here is my write-up on the other presentations I visited.

The One Thing You Need to Know… About Software Development

Mary Poppendieck presented a very good overview of the past decades of software development. She started with the statement that the software industry is in a crisis. This crisis started first in 1968. When she got to the Divide and Conquer approaches, I was asking myself, who gets to decide along which line to divide. Based on the size/complexity dynamic a whole new picture behind the division line may be created. Choosing the right line to divide is therefore very crucial in order not to blow the whole program or team dynamic. The same holds for the layered architecture approaches from Dijkstra. Mary mentioned the separation of concerns in the TCP/IP protocol. When considering todays webpages which can be changed independently of the particular viewer, there is true separation of concerns at work.

Regarding the cycletimes of waterfall approaches she claimed that the cycles through the complete chain need to be shorter than the cycle of changes to the system in order to succeed. If changes get into the system before the last bunch of changes were dealt with, over time the changes will queue up ending in lots of work in process and delays in the overall software development project. On one of the foils she drew two arrows from the requirements specification to the code and the test. Here code and tests will end up with made decisions that need to be analyzed if they do not match. On the next foil she drew the requirements and the tests together with a connection to the code. In that picture were clearly no additional decisions made up in the queue. If the code did not match the requirements expressed in the tests, then the system was wrong. The second system was better in regard to cycletime of decisions. Decisions were not waiting in a queue in order to get elaborated like in the first picture leading to a better flow through the overall system of Software development.

Therefore she raised the point that the product owner shouldunderstand customers and stakeholder very well to work out in an Agile context. In addition

People don’t want software systems, they want something else.

She raised the point for the software system to test itself. In the end the biggest defect is tolerating defects. Therefore we should not work around the problems, which is a clear tolerating of defects. We should prevent the defects to crawl into the software as soon as possible.

Learning is the key to Agile success

With his talk Declan Whelan truly saved the conference for me. His presentation was the first (and only) to mention Shu-Ha-Ri. Later I learned from him that he nearly had thrown that foil out for time problems. He did a similar, but longer presentation at Agile 2009 on the topic and reused some of the slides.

His introduction to the Satir model reminded me on Becoming a Technical Leader where Jerry Weinberg explains how he learned to improve his skills at flipper machines while he was a kid. More interestingly I saw a similar model beforehand applied to my lessons to get a swimming trainer license. The term coined there was called Supercompensation. In the world of sports this principle states, that by putting on a training impulse on the muscles, the muscle – over time – is decreasing its fitness level. During the retirement phase where the body recovers from the training, it is building a higher level of fitness which is – over time – decreased when the muscle is not exercised any longer. By setting the next training impulse right when the supercompensated niveau has reached its maximum, one gains more and more fitness. If the recovery phase is too short, one reaches a level of overtraining. Declan introduced the learning for team based learning with a rather chaotic phase which is necessary to recover. The team then – over time – is able to reach a higher performance level. According to my experience if no additional impulse is settled, the team retires just as the muscle will retire to the same level as before. On the other hand if there is an ongoing chaotic situation, the team is likely to reach a performance situation just as in the overtraining.

His presentation was filled with lots of practical exercises for the participants. This was very good and raised the attention of everyone in the room. Unfortunately the links to the exercises are not put on the slideshare link of the Agile 2009 presentation and I was not able to take notes there. There is one interesting quote, I needed to pin down in my notes:

In the beginners mind there are many possibilities, in the experts there are few.

At this point I was wondering how the flow of decisions and ideas in the system relate to this. Putting more and more burden on this Lean thinking applied to software development as I learned it from Cockburn stroke me. Apart from that he elaborated that the ideal pairing timeframe is 19 minutes referencing a study on this.

The slides introduced into Peter Senge’s model of the Fifth Discipline. The book seems to be very worthwhile to read. In the meanwhile I have put it on my orderlist. Based on Senge there are five key disciplines for team learning: Personal Mastery, Mental Models, Shared Vision, Team Learning and Systems Thinking. He elaborated each of the five, i.e. mental models by letting all draw a picture a hand in 45 seconds. Just one of the participants did take a look on their hand to do so. He discussed the distinction between the goal and the purpose for the shared vision of the team. For team learning to be able to happen you need dialogs, where mental models get exposed for the other to know. On the other hand discussions start to happen when none of either side starts to listen to the other. He pointed out to a video about tinkering school of kids working very focussed on wodden toys. I noted down some of the speakers sentences, which I found also meaningful for Software development:

And the kids soon learn that all project go awry and become at ease with the idea that every step in a project is a step closer to sweet success, or gleefull calamity. We start from doodles and sketches. And sometimes we make real plans. And sometimes we just start building. Building is at the heart of the experience. Hands on, deeply immersed and fully committed to the problem at hand. … Success is in the doing. And failures are celebrated and analyzed. Problems become puzzles and obstacles disappear. When faced with particularly difficult setbacks or complexities, a really interesting behavior emerges: decoration. Decoration of the unfinished project is a kind of conceptual incubation.

According to Gever Tulley in the video it’s crucial to be ok to make mistakes. If this is not the case, one cannot and will not learn from them. Declan introduced many concepts for team learning, like Etudes. In retrospection this was the best non-keynote speech I attended.

Promoting the use of a quality standard

Eric Jimmink kicked off his session with the big struggle of the vague and ambigious Definition of Done of most teams. He went over the unclear definitions and that people might not work as expected to the definition, leading to heroic test cycles at the end. In addition this might also lead to lazy short-cuts. His approach is to use a checklist for getting to know when the team is done. Over the course he introduced a Product Risk Analysis in order to be able to identify if the team includes all the necessary skills it will need to reach the Done for the team. Over the course I noted down the question “How does a common understanding of Done relate to the Vision of the project?” Unfortunately I was too stagefright already for my course after lunch to pay too much attention.

Investing in individuals and interactions

Stuart Reid presented interesting viewpoints about the first value of the Agile manifesto. He told the story of a company, where the testers existed mainly from other automated-away jobs in that industry. These testers were previously experts of doing the work manually. While their jobs got replaced by computers, they were responsbile to test the software that should replace them. Since they had the domain knowledge crucial for that job, they were transitioned to be software testers.

Another story he told was about the situation in an airplane. Like in Pair Programming or Pair Testing there are two pilots: the captain and the Co-pilot. “Which one of the two is actually driving?”, he asked. The more experienced is the navigator in order to make people learn. Unfortunately at this time I needed to leave the presentation in order to prepare for my own.

Panel discussion

In the evening there was a final panel discussion with Tom Gilb, Isabel Evans, Stuart Reid, Mieke Gevers and Alessandro Collino. Tom Gilb claimed the need for fewer engineers in our business and for more craftsmen. “We need more Craftsmanship.” In addition he stated that Quality Assurance is more than testing. Inspections, Design and other practices conclude his model of Quality Assurance. The industry should stop to hunt each new fashion arising, following childishly the newest methodologies. Instead people in the business should understand their practices well. Leadership defines the what, while the team needs to find out how to achieve it. He raised the question for what actually is fed into a scrum team and retrospected over the limits of available resources in the earlier days. Overall a rather chaotic picture was drawn of the current shape of Agile. Remembering back to Declan Whelans session I was wondering if current methodologies are in a rather chaotic shape, recovering from the past decade of Agility to something new and improved while recovering from the recession.

Dinner

In the evening I went out with Gojko Adzic, Declan Whelan, Mike Scott, David Evans, Rob Lambert, Stephan Kämper and Anthony Gardiner. In a conversation with Declan Whelan I was able to point out using the approach he presented to me in the morning, why he seemed to be disagreeing with Michael Bolton. Basically I think a portion of the Satir model also went into it, but I showed him that Michael was actually building up his mental model from the general testing perspective, while Declan mainly viewed the Agile perspective there.

Rob Lambert introduced me to a concept which I want to try out for some time. It’s called PAC. Everything needs a purpose, an audience and a context. I decided to note this down the next day and try to apply it over the course of the next few weeks, at work maybe, to see if it fits or not. Last but not least while listening to all the dinner discussions around, I build a model of why I think Exploratoy Testing works. I decided to put this into another blog post in the near future. Portions of the concept were already spread into the last few blog entries.