I’m looking for a new project. Under “Work with me” you can get some information about me, like work examples and even an ‘old-fashioned’ profile. But that’s only a part of the story: I think the project purpose should match the team members’ personal values. Therefore, it makes sense to describe my ideal next project team; my “dream team” so to say.
So what does that dream team look like?
It’s a diverse team: People come from various fields, there are programmers, administrators, designers, maybe a tester… whatever the projects needs. People also come from all over the place (read: Earth), have different levels of experience and skill. As PicardTips has put it on Twitter:
Picard management tip: Don't let a crew member's age blind you to their skill level, in either direction.
The team has started to follow agile practices, but wants to get better at agile and/or lean development. It experiments with new ways of achieving the goal of the project. It also found ways to work together well as a distributed team, even though it may be spread across time zones. It also values working remotely.
I’m sure we’ll have a couple of exiting days talking about software testing. And not only talking but also some hands-on stuff using Ruby for fun and (fast) feedback.
Before I publish more information about my workshop, I’d like it to…
The last conference day started with a very personal & inspiring (and slideless!) keynote from Antony Marcano, entitled “Don’t Put Me in a Box”. He made a good point about how people have many ‘labels’ outside their job such as mother or father, friend, cook, helpful neighbour etc., while in a job there’s often only one label: The job title. In fact, he asked as few listeners in the audience about what they do and everyone answered with a role or a job title.
He explained how this may be an impediment for agile teams. If (or when) we stay in the box of our job title, we might not get a chance to help in an area that’s outside the main focus of our job description.
The following talk “Pull Requests and Testing Can Be Friends” by Alan Parkinson presented some very interesting points. One of them was this: While it may not be necessary for testers to be able to write code, it may be very useful to be able to read code.
His presentation was mainly how his company uses pull requests in Git. I found it interesting that they use pull requests for a lot of things, including reporting and tracking bugs found when testing the change that implemented the pull request. The reason they do so is simple: The context in which that bug was found is that pull request, therefore these two should be kept close together. They implemented this by having a discussion for each of their pull requests. To me this makes a lot of sense for a development team.
After that I attended Chris George’s talk “Easing the Pain of Legacy Tests” (Be sure to watch the slides, they’re great!). He explained how his team started with a long running (as in: 16 hours) test suite that reported about 20% of the tests as failed; and not always the same 20%. After some iterations of working on the problems they had significantly faster as well as much more stable tests. So, for his team it was well worth the effort.
In the afternoon, I attended Selena Delesie‘s workshop “The Best Agile Managers Thrive When Teams Do”. An introductory exercise showed how stressful it can be for both the manager and the team, if the manager tries to control the progress, instead of allowing the team to solve the problem at hand.
Often it’s better to make the goal visible to (and understood by) everyone, and then let the team work out the solution. One thing I found particularly interesting was this: In a more controlled environment people sometimes have to wait (or at least feel they have to wait) for the next task given to them by the manager. This waiting is not always necessary, but happens anyway. In a more team oriented environment the waiting is more often caused by the work itself, for example when one can only continue testing after some serious bug is fixed. To me this ‘work constrain’ related waiting is a lot easier, because one understands the reason for waiting. The ‘management constrain’ related waiting often seems to be unnecessary and therefore can be more annoying.
At the end of the workshop we, the participants, were asked to answer the question: “What does senior management value?”. For the answers, see the photo below.
I believe that our (the workshop participants) overall model of senior management is far too simple (or simplistic).
The last keynote was Alan “The Evil Tester” Richardson’s “Helping Testers Add Value to Agile Projects“. His story was full of insights and entertaining and I like how he explained that he doesn’t want to be called a ‘QA’:
As a final note: I had a lot of fun talking to some of the other contributors to Lisa & Janet’s new book “More Agile Testing“. I wholeheartedly recommend this book — but may be I’m biased, since I’m a contributor. 😉 As I had the book with me, I got some signatures, not only from Janet & Lisa, but also from other contributors I met at the conference.
Thank you everyone at the conference! I’m already looking forward to seeing you again next year.
The first keynote of day 2 “Test First Saves The World”, was Joe Justice who talked about applying Scrum in non-software industries, including the automobile industry. He also presented a very exciting project which attempts to build a car: http://wikispeed.org/car/
In fact, he brought parts of a car and invited the conference attendees to join a Scrum team and build a car in the hotel lobby.
Building a car at the Agile Testing Days 2014
Joe also pointed to another project he started: The MicroHouse, that aims to provide a clean bathroom, a clean bedroom, a lockable front door at less than 100 USD. It is this project that is linked to the “save the world” part of the presentation title.
In the second keynote Fanny Pittack and Alexander Schwartz presented “Insights from Happy Change Agents”. Both of them have presented at previous conferences, but this time they went for a pair presentation and a keynote — even though they have never worked together before. I found this one very inspiring, to say the least. They demonstrated how a coach can take on the perspective of a team, rather than using her (or his) point of view from the outside. In addition to that, there was also a pair exercise for the attendees to do. They also shared their slides:
To me, the talk was not only about changing your point of view, but also about trust in a team as well as a single person. When the question session started, I made an unusual (for me) move and asked whether someone from the audience was willing to prepare a pair presentation submission for next year’s Agile Testing Days. Then two things happened rather quickly: First José Díaz announced, that if I find a pairing partner, then the session is already accepted:
#AgileTD@jdiaz_berlin is the most agile conf organizer anywhere. Love that he accepted @S_2K’s session proposal on the fly! :->
How awesome — and trusting! — is that? The second thing to happen: The first person I noticed to signal willingness to co-present with me was George Dinwiddie. We met in person for the first time at this conference, have never worked together before and we’re separated by the Atlantic Ocean. I expect to have great fun and learn a lot while working on our presentation. I am sure that we will figure out how a distributed team (of two) can work.
Even now as I write this — a week later — I’m amazed, impressed and honoured by the trust and friendliness of all this. Thank you all: Every single one in the audience in general and George & José in particular!
After this, I had a short break from the ‘regular talks’ and attended the Open Space session (there were six of them, throughout the conference!) facilitated by Alex Schladebeck and Meike Mertsch. Since there were not too many people attending the sessions, we changed the format to a Lean Coffee. I like it a lot when a format is changed ‘on the fly’ in order to match the circumstances, instead of sticking to a plan that doesn’t fit well anymore.
Among other things, we discussed the question “What makes a good session at this conference?”, brought in by George and me, since we wanted to know what it is that people like about a session. Thank you for voting on this topic to everyone who attended!
The third keynote of the day was David Evans’ “The Three Pillars of Testing”. He explained how testing and agile fit together and placed just the right amount of puns into his talk. He explained the classic order of capitals, what ‘Euthynteria’ is — and what is isn’t:
What ‘euthynteria’ is — and what it is not
This was the end of a very pleasant and entertaining second conference day.
