Breaking people's balls since February 1970

Do agile organisations need a Test Manager?

I have had this discussion a few times in the last few years, the question whether or not agile organisations need Test Managers keeps coming up. Now that the agile transformation wind is blowing stronger over traditional software testing departments, more and more Test Managers have their role challenged.

This blog post is not about the need of a Test Manager during a transition to agile, this blog post is about the need of a Test Manager within a mature agile organisation.

As software development professionals, the first thing that we should do when somebody is asking us to build a software product, is to ask “what problem are we trying to solve with this product?”.

Software products are financed and built for the same reason people are hired and paid, that is “to resolve a problem”. Software products are built to resolve a problem for users and people are employed to resolve a problem for organisations.

If we look at traditional software development organisation with phases, gates, siloed development and test departments, a Test Manager resolves the following problems:

1) Communication/Negotiation with other silos
2) Schedule/Resource allocation
3) Process improvement
4) Quality signoffs
5) Test strategy
6) Skill and Resource Development
7) People leadership

Now let’s think about a mature agile software development organisation.

Problem 1 disappears with the existence of a cross-functional team where people with all skills are sitting together and don’t need an intermediary to communicate.

Problem 2 ceases to exist because testing, in an agile team, is a continuous activity, there is no need to schedule anything. On resource allocation, testing is a shared activity and everybody in the team will help; the team itself will know if one or more testers are needed. Through retrospection the team will identify skills shortages. No need for somebody to call the shots from outside.

Problem 3 evaporates. Continuous improvement is a team activity, again, retrospectives will trigger changes, not an external entity.

Problem 4 gets sucked into a black hole and implodes, agile teams don’t need quality signoffs, quality is owned by the team, the team is accountable for it and a high five is all they need.

Problem 5 is not relevant. The test strategy is part of the development strategy and is defined by the team. Let’s remember that we are talking about a mature agile organisation where teams have the necessary skills.

Problem 6 can be resolved by a Test Guild or Test Community of Practice that don’t need a Test Manager for functioning, it simply needs people passionate about testing and software quality.

Problem 7 is still a problem we need to resolve. We need a people leader, so let’s solve the problem and hire a people leader then!

I was a Test Manager, I had a choice, fight the system and create problems that didn’t exist anymore so I could justify my role or embrace the new challenge, learn new skills and start resolving real problems for my organisation. I chose the latter and never looked back.

What team do you play for?

One team One goal

One team One goal

“If you had one wish for software testing this year what would it be? I found this interesting question in a forum on Linkedin a few days back and it made me think.

Many ideas came to mind, around better automation strategies, better understanding of one’s context, better collaboration and knowledge sharing, et cetera and then it hit me.

For 2015 I wish that testers would understand what team they play for. I wish it was the year when testers realise there is no us and them with developers and business analysts. I wish testers focused on delivering value over acting like the quality police. I wish that testers stopped cracking developer’s jokes. I wish that testers started looking at the whole and stop (sub) optimizing their process. I wish that testers stopped trying to resolve problems that don’t exists and embraced collaboration with developers and BA’s to prevent defects and save their companies a lot of money in the process.

You might say “hey! that’s a lot of wishes, not one!”. No it’s only one.

It’s I wish testers chose to play for the right team.


The Resource Utilisation Paradox – On why less is more

Aim for 100% resource utilization

Trad Mgmt: aim for 100% resource utilisation

Traditional management approaches have often put high resource utilisation levels at the top of managers agenda as a recipe for effective management, assuming that existing not fully utilised resources are waste. When managers do capacity planning, they focus on utilising all the resources they have to the max, and this approach has often been considered a universal best practice among managers.

For the purpose of this article a resource[1] is a person that works within a team on a product.

Now, let’s have a look at a system where 100% utilisation works well:

Think about an oil pipeline. It would be really wasteful to build a massive pipeline and just push a little quantity of oil through it. Engineers will calculate the optimal pressure and volume of oil that can be moved and the oil will fill the pipe in a constant stream. That’s what I refer to as 100% resource utilisation.

Based on a similar principle, management believe that they should utilise all their resources 100% so that they can push through a stream of value to be delivered to our customers. 

Oil Pipeline

Oil Pipeline

So, what’s the problem? You might say. It is easy to agree with that approach but the issue is that by applying the laws of fluid dynamics to people delivering value through software, we underestimate the impact of variability. Human beings introduce levels of complexity and variability that are of an order of magnitude higher to the ones found in an oil rig. Oil will flow in a pipe at a steady pace at 100% utilisation, on the other hand a system made of human beings delivering value through software will be affected by countless variables and will not stay steady at 100% utilisation.

So, for a better comparison with software development, let’s use a system that is slightly more similar to a software delivery team than an oil pipe is because it includes human variability. Let’s use traffic flow.

100% utilization = traffic jam

100% utilisation = traffic jam

Let’s now look at what happens when we try to get 100% utilisation, that in traffic terms means all lanes used with as close to constant as possible flow of vehicles. Human variability factors in this time include for example a driver that gets distracted and doesn’t move when there is space in front of him, or a car that breaks down, or a driver that tries to overtake in between lanes or even a driver that falls asleep at the wheel. The result is something like in the picture to the right.

What’s efficiency for a traffic system? I am simplifying but the throughput of cars would seem to me as a good metric. So let’s say that our measure of efficiency is C/h = number of cars that go through a section of the road in one hour. A traffic jam implies low throughput and high cycle time.

We have all been in a traffic jam and we should know that it is certainly not the most efficient way of using the capacity of the road. When you are in a queue and are not moving, you are not being efficient, you are wasting time and petrol. Starting and stopping is not efficient either as, when breaking, you waste your momentum you gained when accelerating, burning petrol and breaks.

Laess acthan 100% utilization = Highway flow

Less than 100% utilisation = Highway flow

Now look at the picture on the left and tell me, is that more efficient than the traffic jam? Will the C/h of the second picture be higher or lower than the one in the first one?

Believe it or not, the answer is higher.

But, we are not using all our resources! Look at that unused space between cars, surely this can’t be right!

Now look at the two pictures below and see if you can identify similarities with the traffic system.

Comparison 1

Comparison 1

Comparison 2

Comparison 2


This is a simple visual representation on how 2 similar systems can obtain higher throughput by limiting the work in progress (cars in transit). It is a counter intuitive idea, but limiting the amount of cars that can be on a road at the same time, can increase throughput. Similarly you can increase your software delivery throughput by limiting work in progress. For the moment I am going to leave it for your imagination to think and speculate whether this is true or not. In the next chapter of this blog post I will use mathematics to demonstrate it. Stay Tuned.

 [1]I generally don’t like referring to people as resources, but in this case I will make an exception because it makes the story I am about to tell you, easier to understand.

How about you stop lying and take responsibility for your actions?

Stop lying to yourself

Stop lying to yourself

Stop saying “I don’t have time to do X”


You have 24 hours per day as much as me and any other human being, animal, plant, rock on this planet.

Be honest with yourself and take responsibilities for your actions.

Say “I chose not to do X because I consider Y and Z more important”

On empowerment and the 2 types of downtime



In a recent LinkedIn discussion, the topics of testing downtime and what should testers do during it was examined. I read and reread the answers a few times and I became convinced that I have a completely different view of what downtime is and how it should be utilised.

The first thing that I noticed was that test managers and leads had a substantial list of items to ask testers to do during their downtime but none of them seemed interested in asking the testers themselves what they thought they should do when in such situation.

This made me reflect on different levels of testers empowerment and respective managers levels of trust. Asking a tester to do something during downtime is not a bad thing “tout court”, I can see some situations where it could be helpful. On the other hand fostering an environment where we assume people are going to do nothing if not asked to do something can be a self fulfilling prophesy.

I believe that by fostering and rewarding a culture of awareness and collaboration while assuming people’s good intent, leaders can help and motivate people to do things because they want to, not because they are asked to do them.

The second observation that made me reflect is the fact that most of the activities proposed were activities that generally testers that work with me do as part of their normal day to day job and not as a once off during downtime. Among things of this type, LinkedIn users suggested:

analyse coverage and issues root cause, learn automation, cross skill with subject matter experts, review of tests, document procedures on wikis, read a work related book, blog, watch a video, self placed training, knowledge transfer, and other “improving” activities.

This point made me think that maybe my downtime is different from other people’s downtime. We do most of the activities suggested in the thread (apart from some wasteful ones) as part of our normal work, so let me tell you what my 2 types of downtime are.

Good downtime that we need to encourage and Bad downtime that we need to fight.

Good downtime: good downtime is planned downtime that we introduce into our process by limiting resource utilization for example by setting WIP limits and allowing for slack. This downtime is designed so that people don’t burn out. During this time people can do whatever they want from searching funny memes on the web, to going for a walk in the park, or if they prefer, studying something they want to learn, there is no limit to what people can do during good downtime. In my experience this downtime generally is of the form of 1 to 2-3 hours with cadence that depends on the specific context and can be fine tuned depending on project and people needs.

Bad downtime

Bad downtime

Bad downtime: This is unexpected downtime due to us waiting for something to do because the flow of work is blocked somewhere else in the system. Say for example the build is broken and can’t be progressed for us to do exploratory testing or the business analyst is on holidays and there is shortage of new user stories coming through. This is bad downtime because it is affecting the flow of value towards our customer. In this case t-shaped testers can help a lot to fix the issue, in fact they are able to support the developer stuck with the broken build or help in the creation of new user stories. When issues like the above happen, using tools like Kanban can be extremely helpful, in fact you will be able to visualize the issue immediately in the form of a bottleneck. The next thing to do is for the team (including but not limited to the people in downtime) to swarm around the bottleneck, reduce it and restart the flow.

If you want to continuously improve your flow, swarming and resolving bottlenecks is necessary but not sufficient. It is important that you resolve the root cause of the downtime and related bottleneck. One effective way to expose bad downtime so that we can identify patterns and fine tune our process is the waste snake, extremely easy to set up and use, I’d strongly recommend it.



Next Generation Software Engineering

Next Generation Software Engineering

Next Generation Software Engineering

I am excited!

When somebody like Mary Poppendieck during a keynote at the Lean Kanban Central Europe 2014 presents a slide named “Next Generation Software Engineering” and you realise that your teams cover each and every point, it is a great feeling.

The points (blurred in the picture) are:

  • Acceptance Test Driven Development process
  • Tight collaboration between business and delivery teams
  • Cross functional teams include QA and operations
  • Automated build testing, db migration and deployment
  • Incremental development on mainline with continuous integration
  • Software always production ready
  • Releases tied to business needs not operational constraints

And there is so much more we can do to improve, even more exciting! Well done PaddyPower! Well done BSD!

The 5 Stages of Expertise

Niels Bohr

Niels Bohr

It was more than 20 years ago when, in college, for the first time, I heard this

An expert is a man who has made all the mistakes which can be made, in a narrow field.
                                                                                          Niels Bohr (Physicist 1885 – 1962)

Initially I didn’t understand it, but it fascinated me, with time I learned to appreciate it.

Let me demonstrate it for you.

I smoke cigarettes that i roll up by myself and in the years I screwed up in likely every possible way while rolling one, and learned a lot about how to make a cigarette even in the most adverse weather conditions like gale force winds and pouring rain. I never rolled during an earthquake but if I can do it easily while driving a non automatic car in the city traffic, I can infer I can do it if the earth shakes a little so I can exclude this edge case. I can proudly claim to be an expert in the narrow field of “Rolling up cigarettes”

How about domains more complex than rolling up cigarettes?

When we talk about a complex domain, like software testing for example, what is an expert? If we want to go by Bohr’s definition we could assert that an expert in software testing doesn’t exist because it is physically impossible for any human being to make all the possible mistakes in such complex domain in one single life. I tend to think that Bohr’s quote is still valid for complex domains and real experts in such domains don’t exist.

These are what I imagine the 5 stages of expertise to be

The 5 stages of expertise

The 5 stages of expertise

As in stage 4, learning is an infinite activity, obviously there will be a wide range of expertise within the same stage and the closer you get to infinity the more you become an expert. Is infinity relative to time? Amount of books read? Number of experiments run? Maybe all of it.

This stupid model has been imagined by me, a person that believes that, in relation to software testing, he is is in stage 4 “Perpetual Learner”.

The reason why you don’t see the 5th stage is thatI haven’t reached it, in fact I don’t even know if such stage exists or not.

On the other hand, if the 5th stage existed, it would invalidate my own very model, in fact the model states that “Learning is an infinite activity” that contradicts the existence of a 5th stage. So should I exclude the existence of a 5th stage, so that my model works? Not really, I’d rather search for the reason that invalidates my model than defend it. Why? Because I learn more when I make mistakes than when I am right, how about you?

Constructive conversations

A constructive conversation is a conversation between 2 or more individuals on a specific subject, where any of the individuals is free to express his opinion and uses other participant’s feedback and knowledge to discover the subject to new heights.

It is a process of discovery, in which each individual participates with the goal of of higher understanding.

A constructive conversation is successful if at the end, one or more participant learned something.

A constructive conversation is even more successful if at the end of it, the higher understanding achieved also produced an agreement for action.

Constructive conversations have no scope boundaries and could be as simple as discussing what tool to use to complete a simple task, up to discussing how our own company can improve to change the world.

Constructive conversations don’t have roles, there is no master and slave, no matter what the level of seniority, each participant receives the same respect and has the same ability to pose questions and contribute their thoughts.

Constructive conversations require engaged participants with equal desire to learn and enrich knowledge for all participants.

People with shallow knowledge on a subject will mainly use the constructive conversation to learn, but will also offer perspectives and questions that might not be immediate to the people that already possess high knowledge. They have the outsider view.

People with high knowledge will help other people by sharing it and request feedback because they know that no matter how high their knowledge, they don’t own the truth.

Constructive conversations require empathy. Constructive conversations require humbleness. Constructive conversations require courage. Constructive conversations require respect. Constructive conversations require empowering leaders and empowered people.

Constructive conversations are the backbone of successful agile organisations.

Agile tester part 2, questions and answers

Warning: The opinions expressed in this post are mine only, please do not use them against any other group of people, but only against me, that is Augusto Evangelisti a.k.a. Gus.

After writing my most recent blog post “The Agile Tester, a Curious and Empathetic Animal” I received quite a lot of feedback for which I am very grateful. Feedback in the form of a conversation is the true fuel for learning and improvement.

To all of you that have mailed me, tweeted about my post, responded using the comments in my blog and talked to me face to face about it, thank you so much for helping me learn!

When i looked at the feedback I received, I saw 2 quite different trends. Looking closer I saw that the different feedback types came from different schools of thought.

Let me give you 2 examples for some context

This one from twitter

This one from one comment to my blog post

Michael Bolton: Something about this post troubles me, Gus. In order to test what was troubling me, I took the content and replaced each instance of “tester” with “programmer”. The result made perfect sense, of course, but it left me wondering: if I can replace “tester” with “programmer”, what distinguishes the tester from anyone else on the project? What is the special role, the particular set of activities, that the tester performs? Is there a difference between the programmer’s mindset and the tester’s mindset? What is the mission, the distinctive reason for having a tester on the team—whether that person has the title “tester” or something else? What is it that distinguishes testing work from all the other work? What testing-specific skills do testers bring to the table? What is testing?

I have answers of my own, of course. But I’m wondering what your answers might be.

I am using Lisa’s and Michael’s as examples of the feedback received because the former is a recognisable exponent of the agile testing community and the latter is a recognisable exponent of the context driven testing community. The other feedback that i received from people close to each of the 2 communities is extremely similar to theirs.

If a group of people finds troubling what the other group finds great, I smell something interesting and an opportunity for learning.

I’ll try answering Michael questions and look forward to his very own answers to learn something:

Question#1:  Something about this post troubles me, Gus. In order to test what was troubling me, I took the content and replaced each instance of “tester” with “programmer”. The result made perfect sense, of course, but it left me wondering: if I can replace “tester” with “programmer”, what distinguishes the tester from anyone else on the project? What is the special role, the particular set of activities, that the tester performs?

Michael, the distinction between different roles in agile teams is becoming more and more blurry. Agile teams value competencies more than roles. As an agile tester in my team I have core competencies that i use to support my team. These include but are not limited  to the ability to evaluate a product by learning about it through experimentation. I also use such competencies to coach and lead other members of my team that are not that strong in that area and help them grow towards an ideal form of generalising specialist. Finally I also perform tasks outside my main competency to support the team. In some cases I will need guidance from another member of the team whose core competency includes the ability of performing such task. I believe that this blurring of the roles increases agile team members accountability, in fact nobody in an agile team (developer, tester, business analyst, operations specialist, UX expert, et cetera) should ever say, “I’m X, doing Y is not my job” but they should instead ask their colleagues “how can I help you?”. Shared activities are key to learning and gaining competencies.

The main goal for any agile team member, regardless of his role is delivering customer value.

Question#2Is there a difference between the programmer’s mindset and the tester’s mindset?

Yes, there is a difference, I don’t think it constitutes an insurmountable obstacle. One of the teams I have worked with, knowing that I wouldn’t be available for a period of time, suggested they needed the tester’s mindset for certain activities and decided that to make sure they were focusing on the right things, they would wear a big red hat. This simple change helped them keep their focus and their mindset in the right place. It might not be prefect but it worked. It works also because I speak to them about the testers mindset when we work together, I give them examples of what I am thinking at specific times and why it is important to think about such things. Developers are very smart people, once they understand a practice has value and receive sufficient amount of coaching, they can learn to do almost anything.

Just to avoid misunderstandings, our developers wear the testers hat when performing testing activities with other developers, i.e. they don’t use the hat for their own code as maybe this could be asking too much.

 Question#3: What is the mission, the distinctive reason for having a tester on the team—whether that person has the title “tester” or something else?

The mission is to provide the team with the testing competencies it needs so that customer value can be delivered. The secondary purpose is to train and coach the team so that they can gain some of the competencies to support test activities. Coaching and training can be also formal but it is mainly delivered by working in pairs.

 Question#4: What is it that distinguishes testing work from all the other work?

Every activity the team engages in, is performed to deliver customer value, including test activities, but I am not sure I understood your question completely, could you please rephrase?

Question#5: What testing-specific skills do testers bring to the table?

See answer to question#1 re. competencies. My main competencies are exploration and learning.

Question#6: What is testing?

Testing to me is exploration and learning.

I test ideas to prevent defects, software to detect them and product owners assumptions to reduce waste.


I hope I have clarified some of your doubts and I am curious to hear your answers to your own questions.



The Agile Tester, a curious and empathetic animal

Agile testers at work

Agile testers at work

The agile tester (ˈadʒʌɪl/ ˈtɛstə/) is a mammal member of the family “Exploratoris”. He lives in the wild in small groups named cross-functional agile teams.


Besides communication and technical skills, his main traits are curiosity and empathy[1].

Curiosity helps the agile tester in finding opportunities to improve the product. The agile tester questions everything.

Empathy allows the agile tester to interact and collaborate with the other members of the agile team smoothly.


The agile tester has an overwhelming interest in delighting customers.

His customers are the product owner and the final users.

He strives in balancing his efforts between making his company successful and delighting the final users by delivering a continuous flow of value to both.


The agile tester spends most of his time having numerous conversations with other members of the team [2].

He will often speak to and question the product owner and the final user in the quest of real value. The agile tester knows that if he doesn’t understand perfectly what the value to be delivered is, he won’t be able to do his job. He builds a strong understanding of the business context he lives in, to be able to help the product owner identify more valuable solutions. This aspect is extremely important to the agile tester, he strives to contribute to building a better product.

Often he will be found having a conversation with the product owner and a developer. This group of animals also known as “The 3 Amigos” [3] feed off each other’s knowledge, different perspective and passion for value to resolve all sort of problems and design lean solutions.

Other times he will be seen pair testing while coaching his partner developer or supporting a developer writing checks, or even writing some checks himself.

Some agile testers have been seen speaking to final users to better understand their experience with the application.

He is also sometimes found alone at his desk testing, softly talking to the application under test.

During the night the agile tester studies and researches his craft, sometimes he blogs and if you watch attentively you might spot a lone agile tester engaging in passionate testing conversations on twitter or in a bar in front of a beer.

Social life

The agile tester’s’ life would not be possible without the team. He works and lives with the team and for the team, the team is an organism that functions with the agile tester[4].

The agile tester is a pragmatic animal and doesn’t like the company of moaners that do nothing to improve their condition. The moaner is the nemesis of the agile tester [13]

The agile tester believes in sustainable development and will not work overtime except for very special circumstances. He will push for process changes to remove other overtime occurrences.

The agile tester and waste

In general the agile tester refuses the concept of waste.

He will not under any circumstance do something “because that’s  how we do things here” or “because the boss said so”. He will ask “why?”[5]. If he cannot get an answer that clearly explains what the value is, he won’t do it. He’d rather be fired than spend time doing things that don’t produce value.

On this subject he is known for using lean documentation, he generally enjoys documenting the application he is helping create through executable specifications[6].

He rejects the waste of bureaucracy and signoffs [7], in fact it is common seeing agile testers signing off by high five[8] in groups of Three Amigos rather than negotiate contracts.

The agile testers understands that producing, finding and fixing bugs is a wasteful activity and he will strive to help the agile team prevent them and do the thing right the first time as much as humanly possible[9]. The agile tester, not only understands this, but he coaches the developers members of the team on this concept and trains them in learning  techniques that help them prevent bugs.

The agile tester believes that his skills are wasted performing regression checks, in fact he employs tools for this menial task[10].

The agile tester prefers cards and conversations to large documents. He plans his activity just in time and helps build the next parts of the product using discovery.

Some agile testers believe predicting the future is a waste of time and prefer building predictable process rather than estimating, they have been known for insistently using the tag #NoEstimates

Some extremist agile testers even got to the point to say that bug management is waste and have removed bug management tools from their organizations with a positive impact[11].


The agile tester is a continuous learner.

He believes in agile principles and he studies the impacts of agile software development on his industry trying to learn new approaches to improve his own company and the whole agile community.

He believes that continuous improvement (as in kaizen) means everybody in the agile team is empowered to drive it. He helps other team members bring out their solutions and support them in convincing the team to try and measure results.

He does not believe in best practices but in good practices that can be improved[12]

NEW! Continue reading with Agile Tester part 2, questions and answers !


[1] Get In Shape to become a better Agile Tester

[2] [6] [9] When Something Works Share it 

[3] George Dinwiddie on the Three Amigos

[4] Cross-dysfunctional teams

[5] Be lean ask Why?

[7] The Cover your Ass manifesto

[8] Sign off by High Five

[10] Test Automation, Help or Hindrance?

[11] How I stopped logging bugs and started living happy

[12] 5 Reasons why best practices are bad for you

[13] Stop Moaning, be the change


Get every new post delivered to your Inbox.

Join 89 other followers