This is a follow-up from Working with the testing debt – part 1 [1] and part 2 [2]. The reason for the clarification is that you so easily come up with a tip without a context or example.

Tip 3: Grow into a jelled team (read Peopleware [3] by Timothy Lister and Tom deMarco for inspiration). Peopleware identifies, among other things, things that you should NOT do in order for a group to grow into a jelled team. As a team it is so much easier to gain momentum in testing and especially so if you are jelled. Do you need to reconsider how you work as a team?

In one project I was test lead and tester. I had two fairly inexperienced testers assigned to me. I used a somewhat exploratory test approach to the planned tests, but they were far from organised and not well communicated. The tests consisted of a long list of one-liner test cases/test ideas. They were quite vague, thus enabling the tester to think for him-/herself. I had added some very specific test cases that were meaningless to run several times, but they were mixed in with the more vague ones. The testers thought it was meaningless to run the test cases several times, but I wanted them to do it anyway. Still, my intention was that they only use them as a guide. I did not communicate well and the testers did not feel like they were part of the test planning (which they weren’t) and thought I had set it up wrong. The mood in the team was foul. The testers had a hard time working with me for several years after that. Looking back I think they spent quite a lot of time that did not give any new information from what we had.

In another project I was assigned as tester together with my regular test group. We worked as consultants at the time. We did not know the project manager, test lead or any of the other testers that well. We were assigned test cases in different areas of the product suite. The test lead walked around and handed out test cases. There was no collaboration in the team. Sometimes when we talked over a coffee we noticed that we had done double work. Some tests were to be run in quite advanced configurations that took 90% of the time to setup. After a while we realised we spent 70-80% of the time setting up configurations, 10-15% of the time reporting bugs and the rest actually testing. By collaborating more we could have saved time to better switch tests around in the configuration that were needed between us. The team composition was 70% new consultants and 30% perm. employees.

And in yet another project the test team had worked together for quite some time. The whole team was involved in creating test missions/charters. Everyone tested and assisted in changing the test plan. When there was a major area that needs to gain some focused testing we assembled a group who generated test ideas, did some test design and did collaborative notetaking on the specific area. During the day the group debriefed several times and changed the test scope based on the feedback. Everyone was involved and felt great.

At one company we had assembled all testers into one big team (see [4] and [5] for setup) where we assisted all projects, the support organisation, the marketing organisation as well as taking on special missions from managers at different levels. When we started we had some unresolved conflicts, but as the team grew and as time went by the conflicts diminished. We worked hard together serving the organisation as best we could. As the team set forth we had the Black Team (inspired from Peopleware) in mind. We challenged the organisation to give us more to test, we could take on anything. We might have taken a bit too much pride in our work, but still I think that was needed after years of being looked upon as the nagging, complaining test team.

At the same company as above we sat in groups of four. When we got a new build we were armed to the teeth with test ideas, assigned areas for investigation and energy to shot down (not literarely) anything coming our way. During testing someone could shriek out in delight as a critical bug was found. The whole group would sometimes plung in and attack the same area from different angles to root out more issues, then continue on the track that they left earlier. We longed from the untouched (by testers mind) new features. We overwelmed the organisation with bugs, never having to consider that we might be the bottle neck at any time.

We all act differently depending on the context. With experience you hopefully learn from many of your mistakes. After you have been in a jelled team, you wish to be in the same situation again. You now know how good things could be and when you are not in that flow, you try to determine how it could be so. The book Peopleware is one of those things that might get you ideas on what you or people around you should stop doing  in order for your team to become jelled. Do not be afraid to tell management things that they that will stop you from growing. In some cases they might not know that they are doing it in a way that corrupts.

How does this affect the testing debt?

The benefits are obvious, a sentence to rise a cautioning finger about, but perhaps somewhat valid in this context. Part of the dilema is how you perceive the team that works well together. Do you see it is as a Clique (roughly described as an arrogant group) or as a Jelled Team? For my description I emphasises on a team that see itself as a jelled test team. When I say to increase the testing debt I mean that your backpack is getting heavier. Each time you start a new task, new project or new assignment you take the content of your backpack into consideration. Being a jelled team enables you to move more smoothly and become more flexible, thus able to become quicker and hopefully deliver better result.

We should also consider that there are differences between a team that is jelled consisting of various roles (such as a cross-functional team) and a team with only testers. Both constallations have different issues and both will have an ever growing testing debt. Some tips would apply to one constallation and not the other, naturally.

Kay Johansen and Anthony Perkins identified a few interesting ideas in their paper Establishing an Agile Testing Team: Our Four Favorite “Mistakes” [6] that I think is relevant to building a jelled testing team. We also have a paper by Elizabeth Hendriksson on Agile Testing [7] that identifies things you should not do as a tester if you intend to be agile. They are most relevant when considering what role testing should have in a cross-functional team or what your attitude is as a test team. Brian Marrick has made a compilation of articles [8] on Agile Testing, somewhat old ones but still valid as a way to consider when trying to become more effective and build a jelled test team. Marrick has also created the article Classic Testing Mistakes [9] that is valid still and should be considered when trying to identify why your team is not jelled yet. I’ve also written two blog posts about growing test teams: Uncertain team composition [10] and Progress [11]. Both tries to focus on things you should not do in order to get a jelled test team.

Some specific things that I see a jelled test team do, that decrease the testing debt, is:

• Build on each others test ideas. With this I mean that we are triggered on each others test ideas to create new ones until we have no further ideas.
• Easy of changing direction. I often promote the concept that the test team or the team in general need to be flexible, thus the naming of The Flexible Test Team. If the team works well and trust each other it will be easier to accept change.
• Collaborative notetaking. In a team where you want to work together and where you enjoy cooperation it is the teams effort that counts, not the individual. This is also true for taking session notes. This is no best practice (as none exists), but a practise that is good in some situations. That the team have the ability to do this is a bonus.

With an unjelled team, a group of people that do not collaborate as well as they could, thus increasing the testing debt, I instead see:

• Stacking of test ideas. This means that each individual identify test ideas and they are summed up, with duplicate ideas removed. An unjelled team is more inclined to do this than a regular jelled team.
• Double work and duplicate testing. This might be the result of bad leadership and test leading, but based on my experience I think it is more common than in a jelled team.

What things do you consider for a jelled test team or a jelled team that has mixed roles but with testers in it? What have I missed as you see it?

References

[1] Working with the testing debt – part 1 - http://thetesteye.com/blog/2011/05/working-with-the-testing-debt-part-1/

[2] Working with the testing debt – part 2 - http://thetesteye.com/blog/2011/06/working-with-the-testing-debt-part-2/

[3] Peopleware - http://www.amazon.com/Peopleware-Productive-Projects-Teams-Second/dp/0932633439/ref=sr_1_1?ie=UTF8&qid=1310020112&sr=8-1

[4] Flexible testing team - http://thetesteye.com/blog/2008/05/the-flexible-testing-team/

[5] Resource planning in a flexible test team- http://thetesteye.com/blog/2008/05/resource-planning-in-a-flexible-test-team/

[6] Establishing an Agile Testing Team: Our Four Favorite “Mistakes” by Kay Johansen, Anthony Perkins - http://agile2004.agilealliance.org/participate/examples/EstablisingAnAgileTeam.pdf

[7] Agile Testing by Elizabeth Hendriksson - http://testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf

[8] Agile Testing by Brian Marrick –  http://www.exampler.com/testing-com/agile/

[9] Classic Testing Mistakes by Brian Marrick - http://www.exampler.com/testing-com/writings/classic/mistakes.htm

[10] Growing test teams: Uncertain team composition - http://thetesteye.com/blog/2010/04/growing-test-teams-uncertain-team-composition/

[11] Growing test teams: Progress - http://thetesteye.com/blog/2009/10/growing-test-teams-progress/

This began as an answer to Rikard’s post http://thetesteye.com/blog/2011/06/a-word-of-caution/ where the discussion on “traditional testing” came up.

I often hear comparisons with our “industry” and the Automotive industry.
In that context, you could say that “traditional testing” corresponds to the methods and practices that are applied in line production of large car companies. And the unorthodox testing can be compared with those specialized and often smaller custom car builder companies out there.

The major issue with this kind of comparison is that large car companies makes thousands of the exact same type of car. Instead this means that the “traditional testing” approach is an attempt to apply line production methods when building custom cars. Applying “traditional testing” as if every project and product were the same is both wrong and dangerous.

And this comparison is not that far-fetched… It seems to me like “traditional testing” is promoted as practices that suits many (if not all?) projects and should be followed in order to enable success. Well, good luck!

Further, many practices that we use today comes from the automotive industry (at least in their latest form).
If we fail to see why they implemented them in the automotive industry and just take them as good practices for being effective in line production, we are doing the opposite of what the automotive industry did. They did some investigation on how they could improve their work. Some of that included seeing the human beings as intelligent and social creatures; utilize the diversity of a group of people; etc. And their productivity and efficiency could be measured by measuring number of cars and their quality. So by treating humans as humans they became more efficient (number of non-defective cars) and improved their work methods (analyzing quality of work).
When Lean development is implemented in psychiatric nursing or software development today, the focus is very often on the quantity measuring part which then misses the whole point. Measuring patients or software as uniform units is very wrong and dangerous.
It’s not that Lean or Kanban is to blame, it’s the implementation; and perhaps mostly the implementors.
The role models for Lean implementations in many healthcare institutions in Sweden have been some successful nursing teams that have increased their efficiency and quality of their work by using Lean development as a method. What those successful teams really did were to take command of their own work and found a method that supported their initiative and commitment. (Anyone had similar experience? Me!)
The problem is that when this is implemented by management at the whole hospital or nationwide, the focus is shifted from “Quality of work” to “Quantity of work” because that is the obvious driver for management and really the only incentive for they to implement it. They only need to say that this is a “best practice” and then it’s OK…
I do need to emphasize that you don’t automatically get high quality work by implementing “best practises”!

This is happening all the time; and the last flavor of the month is Agile.
If you read the Agile Manifesto and then think that you must play planning poker or have standup meetings you are obviously not understanding the Agile Manifesto.
I’m with Matt Heusser on his interpretation here: http://www.softwaretestpro.com/Item/5036/My-%27take%27-on-Agile—-or-the-Manifesto-elaborated/Testing-Software-Test-and-QA-Teams-Strategy-Agile-Development

This was originally meant as an answer to the (ironic) thread http://thetesteye.com/blog/2009/06/long-live-the-waterfall/ where a new thread was forked when Ola Janson launched a couple of questions regarding agile development. My answers and thoughts on those questions are listed here.

In one reply to Ola, Rikard says that he has “…never worked in a truly Agile project…” but what is a “truly Agile” project really?

I have worked in both agile (quick and well-coordinated in movement) and Agile (http://www.agilemanifesto.org/) projects.
Here are my thoughts and observations.

• Being agile as a team could apply to any jelled team with a developed group dynamic which manages to quickly respond to problems that might arise. It could also be applicable for any team that has ability to minimise the cost of change instead of trying to avoid the change. I have been in such teams.
• Being Agile as a team is when the team agrees upon the Agile Manifesto (Note: remember that the Agile Manifesto is a set of values and not a set of laws). I have been in such teams.
• XP, Scrum, DSDM, Lean, Kanban, etc are process tools in that they help you work more effectively by, to a certain extent, telling you what to do. These process tools must live up to the Agile Manifesto and are described practises for how to work in an Agile fashion more or less structured; each method has its benefits and drawbacks and none of them are comprehensive. That is why you often see combinations of different “Agile” processes e.g., XP (developing method) and Scrum (team management method) and Continuous Integration (incremental build method).
• You can work in an agile team and still utilize Agile methods such as Scrum or XP; but you could also use other non-Agile methods and still be agile.
• You can work in an Agile team and don’t utilize any of the big recognized “Agile” methods.
• Being a tester in an agile team (or project) is gold.
• Being a tester in an Agile team (or project) can be a smooth experience but it could also be painful. My experience is that if you as a tester are not engaged or involved in the team you will have difficulties. E.g., since documentation is not prioritised you need to know more about the software continuously and therefore there will be problems if you are not engaged in the day-to-day development of the project. And many times the team has been forced into working according to a specific Agile method that does not seem to be suitable for the context of project; and it might be very well suited for programmers but not at all suitable for the testing tasks.

The key thing with the agile movement, as I see it, is that the methods on how to develop software have evolved from the project context and, perhaps most importantly, being defined by the team members themselves. Therefore I believe that those projects have had a successful outcome, at least from the team-perspective. Many times it has correlated with business success.

The Agile movement on the other hand, which originally has sprung from the agile movement, has become more and more strict and promoting “best practises” on how to work Agile. This has become the new cash cow for many consultant firms and they of course promote and teach the “real way” of doing things. But I guess that many founders of the Agile Manifesto really think that it should be more agile than Agile…
So nowadays there are, and will be more and more, voices raised which question the new face of agile/Agile and instead promote the “original” thoughts; or at least the thoughts that they believed in then and still do.

My conclusion is: Find out what matters for you; your team; and project. Define a process that will work for you.

Read more about Agile vs. agile:

• Agile Versus agile Development - http://www.agilejournal.com/articles/columns/from-the-editor-mainmenu-45/18-agile-versus-agile-development
• Defining Agile Methodology - http://www.satisfice.com/blog/archives/45

Find out if your team is agile (or is it Agile?)

• Back-of-a-Napkin Agile Assessment - http://testobsessed.com/2008/11/28/back-of-a-napkin-agile-assessment/

Examples of reactions on current Agile methods:

• Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism - http://arxta.net/
• Cargo Cult Agile – http://www.exotribe.com/node/16
• WAgile - http://www.parlezuml.com/blog/?postid=708
• Who Stole Agile? - http://www.satisfice.com/blog/archives/51

Group dynamics

• Read about “Jelled team” (and other interesting topics) in Peopleware - http://www.dorsethouse.com/books/pw.html

Agile development methods are becoming a more popular way of producing software in contrast to traditional project processes. This has affected the testing profession in many ways, which has given us both benefits and new challenges.

In a way, agile development methods can be seen as a reaction to a couple of traditional project risks. But even if some risks have been addressed by these methods, there are certainly new risks that are introduced.
I have more than 5 years of experience working in Agile development teams and I love this way of developing software. Still, I have seen a lot of new risks that has been introduced with these approaches; risks that sometimes are ignored, and sometimes they hit the project with full strike.
So,
* what new risks have been introduced in Agile development?
* And especially, what new risks are introduced for testing in agile projects?
* Which risks are applicable for testers in a project where developers do unit tests and testers are supposed to do acceptance tests?
* Which risks can affect the testing in a project where you end up as the only tester out of 8 team members of a Scrum team?
* Which risks are to be found in an agile project where one test team is supporting several agile development teams?

So, can we (I invite you all to this task) identify and define 5 core risks that are applicable for testing in agile projects?
By core risks, I mean risks that would be so common that they could be considered to be valid in most contexts.

And…

Can we try to find out about how risks can manifest in agile projects and what their transition indicators are?
I guess this would be a good way of learning how to mitigate and take actions to minimize the costs for the risks to materialize.
As risks are something that will always exist in software development, it is better to manage them than to ignore them.