“Are you working as a tester or developer in your organization?” – Well, honestly this is a question I do not really have a good answer for at hand. I could say both, but that is sometimes bothering people as they tend to doubt this is possible. Another interesting question is the one about how many testers we have in our teams. Hm, none or let’s say the whole team. The best answer today to any of these kind of questions was given by my collegue Andreas : “We are working in projects where work has to be done and we have people doing this work.” Probably we are in a really lucky situation here as we have managed to spread the knowledge – and also the interest – for different tasks among most team members in our agile teams. This does of course not mean that we do not have core areas of knowledge or interest. But the roles needed in a scrum team should in my opinion not be assigned to fixed persons in a team, but there must be persons in the team that are able to fill out the required roles.
Quote from Twitter:
AndreasEK When can we finally replace “what’s the role of a tester in an agile context” with “what testing skills does an agile team need” #agiletd
Luckily there are as well a lot of other antendees with the same viewpoint here in Berlin. And we have had some very good discussions on this topic, which I personally find very interesting as a member of an agile team.
But now let’s have a look at the conference presentations of day one @ATD 2010 in Berlin …
Keynote: Agile Defect Managemant by Lisa Crispin
This presentation is timewise the longest in the past, so let’s see what I can still squeeze out of my brain. The questions is how much Defect Management is needed in agile teams and how big a tool do you want to “throw” at this problem. I found one point here especially interesting that a bug is not a bug if it is found during development in the same iteration. In such a case it should be simply fixed. I am especially happy as we do so already in our team and if a bug cannot be fixed immedietly then we put it to the whiteboard rather than into Jira if fixing it will still be part of the iteration. Of course there might be a need to keep track of bugs found in production as those can often not be fixed right away. Nevertheless one should rethink what possibilities there are in a team to keep track of these bugs.
Think of one thing your team can do to prevent defects, starting next week. – Lisa Crispin
It could be a full blown Defect Management System, which does not feel too agile. It could be Jira which is widely used in agile teams, but it can also be a note on the whiteboard or some automated test that has been written right away for this defect. As usual there are probably more solutions to this problem than one can see on first sight and teams (we) should not limit ourselves to what we think is the standard way of doing this. By the way: This fits perfectly fine with the presentation given by Rob Lambert and for that reason let’s jump to this presentation right away. Ok, almost right away as it must be mentioned beforehand that Lisa’s presentation can be downloaded here .
And more information on this topic can be found in the blog posts from Gojko Adzic and Markus Gärtner .
Structure kill testing creativity by Rob Lambert
Rob Lambert’s presentation was about creativity in agile teams and how powerful this creativity can be. Let’s therefore start with a very nice quote from his presentation:
Creativity is the process of having original ideas that have value. – Sir Ken Robinson
Basically there are four types of intelligence that can be distinguished (and not only for software development, but in everyday’s life)
- Academic Itelligence
- Creative Itelligence
- Practical Itelligence
- Emotional Itelligence
In the IT industry often only Academic Intelligence is really appreciated, while for example Creative Intelligence is something that should be left to the marketing department ;-), but that is wrong. Software development requires a lot of problem solving and in this creativity is often very helpful.
What is absolutly important for this is that people are encouraged to be creative. Some organisations and companies do the opposite by creating an environment of fear where people try to cover themselves as good as possible by following always all possible rules and not doing anything outstanding. This is of course a very bad thing to happen.
Self-education is, I firmly believe, the only kind of education there is. – Isaac Astinov
With agile we are trying to create an environment of trust where the team can come to creative solutions, by learning new things and working in small cylcles inspecting and adepting the work of the team all the time. Of course there is structure needed also in agile teams, but it should be as less as possible. Another blog post on this session can be found here.
Keynote: Deception and Estimation: How we fool Ourselves by Linda Rising
For me this keynote was definitly one of the highlights of this day together with Elisabeth Hendrickson’s talk that was so full of positive energy (as always :-)), but let’s continue first with Linda’s talk how we fool ourselves.
This was really one of these non-technical talks that give you some insight and inspiration not only for your working life, but also for your daily life and it will be almost impossible to put her presentation into this blog post properly as it was not only living from the topic as such, but also from Linda’s unique way of presenting it.
Linda was introducing her talk with the words that this will be the weird talk of the conference and that people will not like what they will hear in the next hour. At least for me this is not true I can say! So as software is developed by people, or to be more precise by people’s brains, it is definitly worth to have a look how our brains are working. And the first thing to start with is a defintion:
Deception: “Consiously or unconsiously leading another or yourself to believe something that is not true.”
The first good point here is that we deceive ourselves in the estimates we are doing in software development daily. But we do not believe that this is happening to us. Even if there are clear numbers and statistics people tend to believe that this is only happening to others but not to themselves. This is becaue we are optimistic by nature, we make emotional decisions all of the time and we filter out certain information we do not want to take. Linda was giving here the nice example of a questionaire among car drivers and whether they believe that they are exceptional good drivers. All of them responded that they are exceptional good drivers. Well, even those being in a hospital due to crashes they have been causing.
There are no facts about the future. – Linda rising
I really think it is very interesting to reflect on these things and to consider that one simply cannot avoid that this is happening for example in estimation meetings. It is not always only “the other” doing things wrong even though this is a nice thing to believe. (Of course I personally still think “the others” are doing things wrong more often ;-).) But getting the bridge back to agile one can say that estimation meetings are good because we have different persons there with different filters
estimating the same stories and tasks. This is at least increaing the probability to come to better results.
There is uncertainty in every project. – Linda Rising
And probably it is not really desirable to get rid of all this “protective mechanisms” and to see the world 100% as it really is (one nice guy from the audience was shouting “flat” in this moment, thanks for that one). But the only persons being totally honest with themselves are depressed or sociopaths … so not really what you want to be.
I personally always have been – and hopefully always will be – a very optimistic person at work as well as in my private life, but nevertheless I found it very very interesting to have a quick view “behind the curtain” and knowing this will give me at least the possibilty to reflect on these issues every now and then … well, hopefully.
Keynote: Lessons learned from 100+ Simulated Agile Transitions by Elisabeth Hendrickson
Elisabeth had the hard task to give the final presentation of the day when people are typically already a bit exhausted, but as already mentioned her talk was so full of great energy that she was having the full attention of the audience immediately after starting. The talk was about here experiences from over 100 simulated agile transitions. Unfortunelty I did not took the chance to join her tutorial where she was doing this, but I will do this for sure the next time I get the chance to do so.
Anyway the idea behind this is to divide the group into different roles like product managers, testers, developers or even computers. And of course there is also a customer and some work to be done. This work should be done in 15 minutes and then there is a reflect and adept session on the process and then there is the next 15 minutes simulation round. Typically there are up to four of these sessions during which the team is undergoing a lot of changes and is very often re-inventing a lot of ideas from the agile world (like CI and ATDD) to improve their way of working.
People add their own complexity and time pressure (to the simulation). – Elisabeth Hendrickson
Elisabeth was pointing out that every transition results in chaos (for a certain period of time). In the simulation this is typically the case in the second time the exercise is done. But this is ok as it will be passed by. It is also often during this phase that people have the feeling that they are lacking control and even want to have (back) their good old project manager as a role in the team. But it is not control what people are lacking, but visibility and this is what agile methods can give them.
Don’t use communication solutions for visibility problems. – Elisabeth Hendrickson
It can also be seen very well in this simulation that already small changes in the physical layout can make a huge difference in the productivity. Other important findings are that one should not think that daily standup meetings are status meetings and that tests can be used very good as an alignment tool. Because by looking at the team’s automated tests – that ideally are written in BDD-style syntax – one can check right away which functionality has been implemented and is working fine.
There was a lot more in this session and one also have to say that the slides have been great with all the little figures arranged there as team members performing certains tasks, but I cannot really recap everything here, especially as there was some good discussion evolving around the whole topic after the presentation was finished – despite the late time.
What else?
As I really like the Robot Framework and are very convinced it has really very good concepts I am of course very happy to meet Pekka, Juha and Janne here. They have been giving a tutorial on “Executable Requirements in Practice” using the Robot Framework and Pekka was also giving a presentation today about “Acceptance Test Driven Development using Robot Framework”. I liked this a lot even though there was not too much new things for me in this. In addition I felt a bit exhausted as I had just finished my own talk about “Testing Web Applications in practice using Robot Framework, Selenium and Hudson”. I really enjoyed giving this presentation a lot and of course I hope the people attending it did so as well.
I am looking forward to tomorrow’s presentations and should try to get some sleep now as the conference day is starting tomorrow morning quite early with some running at 7am. So just in case someone from the conference is still reading this and is having her or his running gear at hand just join us (Andreas and me) in the lobby tomorrow morning. Good Night Berlin!
Was this post helpful?
More articles
fromThomas Jaspers
22.2.2019 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Thomas Jaspers
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.