Promise: I will never ask you for a CV

Over the years i have applied for many jobs, sent many CVs. I have also read many CVs and hired hundreds of people. That’s it I’m done with it.

Working with somebody is a very important human relationship, I am not going to ask you to describe yourself on a piece of paper because i am too lazy to take my time to know you.

Not only i am too lazy to get to meet you all, I also am so arrogant that i expect you will want to work for me. This is ridiculous. Why would i assume that you want to work with me without meeting me first?

Is it because i offer you a salary?

Well if that’s the only reason you want to work with me, then i might not want to work with you in the first place.

I’m done with CV’s. Keep an eye for job postings where i invite you ALL to meet me for a stroll on the beach, for a drink in a pub, for a meal in a restaurant, for a walk in the park.

If you think you want to, come over, let’s meet and see what we can do for each other.

Collaboration and roles, learning from Rugby union

rugby

I keep on hearing team mates say things like

“it’s not my job to test, I am a <insert_role>” or “It’s not my job to design the product, I am a <insert_role>”

and I am quite tired of the behaviours caused by the message when left unchecked.

A team is more than the sum of its parts, a team has the power of collaboration.

When I was young I used to play Rugby (union).

Rugby union is a highly specialised sport, in fact the 15 players on the pitch are divided in 2 main silos, “forwards” and “backs” and within the silos there are these following roles:

Forwards: 1. Loose-head prop, 2. Hooker, 3. Tight-head prop, 4 and 5. Lock, 6. Flanker, 7. Wing Forward, 8. Number eight, 9. Scrum half

Backs: 10. Fly half, 11 and 14. Wing, 12. First centre, 13. Second centre, 15. Fullback

WOW 13 different roles for 15 people in the same team, more than the usual PO/BA/DEV/TEST/UX etc. we find in modern agile teams. How come they are able to collaborate so effectively?

The difference is that nobody in a rugby team will ever use a sentence of this type:

“I am not doing X because my role is Y”

In fact the very best rugby players are not the super specialists but the ones that are good at every different skill and activity required to play rugby. (Research the case of Brian O’Driscoll to me the synthesis of excellence in collaboration skills)

When there is a ruck 2 meters from a goal line you will see the ten stone (63Kg) Scrum Half stick his head in and push the 15+ stone (95Kg+) players away from his goal line.

He won’t say, I’m a scrum half I don’t do rucks, I guarantee 100% he won’t, because if he does he will lose the respect of his teammates, his coach and his fans and never play the game again.

Why do rugby players collaborate so well even though they are such a specialistic group? Because they have one clear goal, the clear goal is to score more points than the opponents. They all get that and do their utmost to help their teammates achieve it.

Why are agile teams not collaborating like rugby players?

One of the reasons is that they don’t see a common goal in the customer value to be delivered but see the beauty of the “elegant code”, “smart test strategy”, “beautiful solution”, outstanding “user experience” and so on.

So if you want to get your team to collaborate better together you got to give them a common cause to fight for. And just to save you time, it is not lines of code, story points, tests passed, number of bugs or lack there of, it is something bigger and more important.

Discover what it is together with your team.

 

Test coach versus test specialist, impact on queues

I recently had a very interesting conversation with a group of skilled testers on whether or not there should always be a test specialist in a cross-functional team.

A lot of people say yes, my personal experience says not.

My personal experience tells me that the most effective and efficient approach uses a test coach that slowly makes himself scarce. My experience focuses on creating competencies for completing an activity (testing) in a collaborative context.

One aspect I am finding difficult to explain is the impact on queues of a test coach approach, I will use a series of Scenarios and pictures to facilitate my reasoning.

If you feel like substituting activity A = development and activity B = testing feel free, but this approach is activity agnostic in my experience as I have applied it to analysis, and development obtaining similar results.

Scenario 1 – Test specialist

In the presence of one specialist on Activity B and many specialists on activity A.
Problem: Long q
ueues form in Ready for Activity B (Case1) or worse specialist multitasks on many activities at the same time slowing down flow of work as per Little’s law (Case2)

Screen Shot 2017-05-29 at 10.40.47

Scenario 2 – Test coach

Stage 1: In the presence of one coach on Activity B and many specialists on activity A
Initially coach pairs on Activity B with people that do activity A. This way we obtain 2 benefits:

  1. Queue in “Waiting for Activity B” is reduced as one person normally performing activity A is busy pairing with coach on one activity B task
  2. By pairing on activity B feedback loops are shortened
  3. Person with activity A acquires new skills to perform activity B from pairing with coach
  4. Quality of activity B increases as it is a paired activity
  5. Flow improves because of 1 and 2

Screen Shot 2017-05-29 at 11.22.49

Stage 2: When cross-pollination of skills required for activity B starts to pay off, we have 2 benefits

  1. Normally some activity A person will show particular abilities with activity B, in this case this person can pair with another less skilled activity A person to perform activity B
  2. Queue in “Waiting for Activity B” is reduced as more people with activity A skills are performing activity B
  3. Flow of value improves lead time decreases
  4. More activity A people get skills on activity B

Screen Shot 2017-05-29 at 10.56.00

Stage 3: All activity A people are able to perform activity B
Activity B Coach can abandon the team to return only occasionally to check on progress. Benefits:

  1. Activity A and activity B can be performed by every member of the team
  2. the WIP limit can be changed to obtain maximum flow and eliminate the queue in Ready for Activity B.
  3. The flow of value is maximised
  4. The lead time is minimised

Screen Shot 2017-05-29 at 10.58.05

WARNING: I have applied this approach to help teams with testing for many years. It has worked in my context giving me massive improvements in throughput and reduction of lead time. This is not a recipe for every context, it might not work in your context, but before you say it won’t work, please run an experiment and see if it is possible.

This is not the only activity that a good test coach can help a team on, there are many shift left and shift right activities that will also reduce the dependency on activity B.

I have been told a million times “it will never work”, I never believed the people who told me and tried anyway, that’s why it worked.

Try for yourself, if it doesn’t work, you will have learned something anyway.

How a little man from Japan helped Team X focus on their customers

screen-shot-2016-10-28-at-08-26-32

Previously on “A knowledge worker’s tale“: Team X discovered that lack of clarity on what to build, was creating a backlog in their exploratory testing work queue. They realised that adding new testers would have only fixed the symptom of the problem but not addressed its root cause.

Team X met to talk about a possible solution to the fact that too many misunderstandings in the user stories were slowing down the work dramatically and driving the testers crazy.

When Gus walked in, they were all there, nobody was late, the team really wanted to resolve this problem.

Mike took charge and said “We need to ensure that the user stories contain all the details, we can’t be blamed for problems in the requirements”. All the others nodded in unison, the bloody user stories were the problem…

Peter added “Absolutely Mike, we need Fritz to sign off the user stories so that when we start, if there is a problem, we know who’s fault it is and we don’t get the blame every time, I am tired of this!” he added “we need to make sure we know who’s fault it is”.

Before Fritz could answer, Gus interjected “OK, let’s see. Am I right in saying that our goal is to deliver value to our customers? Right. How is identifying who to blame going to help our customers? How is blaming somebody going to help our customers at all?”

He continued “Customers will still get the product late because of the misunderstandings, I bet if you asked them, they will tell you that they don’t give a rats arse who’s fault it is. What they care about is to get a solution to their problems, through our software”

Then he went “Once there was a little man in Japan, many years ago. He said that every activity that does not benefit the final customer is waste and needs to be removed from the process. He went to define 7 categories of waste that can be found in manufacturing. This guy’s name was Taiichi Ohno, he revolutionised the motor industry and his learnings have been used to improve manufacturing all over the world, he worked at Toyota. I strongly believe his lessons can be used very much in every context, including software development, let’s not introduce waste, let’s focus on value add activities”

“It seems reasonable” said Mike “but how do we make sure the defects in our stories don’t get caught only at exploratory testing, we have seen that when that happens our flow gets to a standstill, we can’t allow that”

“Taiichi would be proud of you Mike” said Gus. “One of his 7 categories of waste was exactly what you described, ‘defects’.” he continued “Quality was fundamental in the Toyota production line, one tenth of a millimetre difference in a bolt could bring the line to standstill, Taiichi knew it and made sure the workers knew it too so that they could find new ways of avoiding it”

Gus stood up and went to the whiteboard, he wrote “Prevention over Detection”. Then he drew a circle that had 3 stages “1. Write a failing test” – “2. Write enough code for the test to pass” – “3. Refactor”.

He went “Ladies and gentlemen, this is TDD, the one most effective ways of preventing defects in your code I have found in my 20 years as an engineer. In one of it’s more modern evolutions it is called BDD. Through high collaboration and conversations it allows teams to deliver code that has a fraction of the defects of code written without it. If you like to know more, I can organise a one day workshop to talk about BDD and how it can help us prevent defects”

Peter said “I am a bit confused about all this stuff, little Japanese people building cars and tests that are written before code, it doesn’t make sense. But in all fairness Gus has been right before with even more nonsensical stuff like ‘do less to do more’, I think we could take a leap of faith and trust something good will come out of this, what do you think guys?”

The team nodded in silence, they were puzzled. Accepting something brand new and counterintuitive can be scary, but true agile teams are courageous in their decisions.

Gus smiled and left the room so that the guys could make a decision freely.

Will Gus’s nonsense help team X? Stay tuned and discover what happens next

 

 

 

 

How Team X got to the root of the problem by asking why

screen-shot-2016-10-28-at-08-26-32

Previously on A Knowledge Worker’s Tale: A large bottleneck appeared in the exploratory test column of team X’s kanban board, but only Rick and Jane, the testers, seemed to give a damn about it working hard to unblock it. Gus saw the problem asked the team to take off their headphones, go to a room and get instructions from the testers on how to unblock the flow of work.

And the story continues…

Team Xers reappeared in their open space with renewed energy. Rick and Jane had explained what they needed to get their work unblocked and soon people started working in pairs. Rick and Peter were debugging together an issue that seemed difficult to track with the assistance of Fritz the business analyst that seemed positive he remembered something important that could help them. Jane was showing to Mike and Jimmy how, what she thought was the correct customer journey, was not what Zach the customer thought it was.

It was great to watch, a group of skilled professionals working in groups, using all their skills and knowledge to troubleshoot a complex problem.

As expected, the pairing and collaboration gave its fruits, defects were getting fixed and retested and the bottleneck was reducing fast. Flow was being reestablished thanks to the team swarming and focusing on the biggest problem in the system, it was great to observe.

Once things got back to normal Mike called the team to the board and said “Folks, it has taken only 3 hours to fix that bottleneck that had basically stopped our flow for two days, I think we have learned a very big lesson today and the lesson is that when we see a bottleneck, we all have to chip in and help unblock it!”. The other guys nodded with satisfied faces finally seeing their work getting to completion again. “Well done all!” Rick the tester added “without your help, we would still be where we were 3 hours ago, collaborating has been fantastic” and the lads gave themselves a small round of applause.

“Let’s go back to work!” said Mike.

“Hang on, hang on” intervened Gus, that had been lurking from distance. “It is great that you guys found a way to reestablish flow, I was delighted to see how you collaborated and forgot about your roles for the good of the customer, I say well done for that”. He continued “The fact is, if we go back to work without addressing the problem that created the bottleneck in the first place, it will be only a matter of time before it happens again, don’t you agree? Now that we have it fresh in mind, I suggest we try to understand the real problem that created the bottleneck, let’s do a quick retro, who’s with me?” The team nodded and followed Gus in the retrospective room.

“So WHY do you guys think the bottleneck formed at exploratory testing?” asked Gus.  Immediately Peter jumped in “Because we need more testers!” to which some of the other team members nodded in unison. He added, “Rick and Jane are always super busy, they never have a minute free and at the same time they are always behind with work, the guys need help, we need more testers!”

“Adding more testers is a potential solution, but we haven’t identified the problem yet” said Gus. “I am going to ask a tester now, Jane, WHY do you think the bottleneck formed at exploratory testing?” Jane, slightly caught by surprise turns to Rick, mutters something, then says “Because exploratory testing was taking too long”. “Ok this sounds like a reasonable problem, and WHY was it taking too long?” added Gus. “Well, running tests would have been fast, but we found a lot of defects that needed fixing and that created a never ending back and forth with the developers and Zach” added Jane.

“Very good Jane, thank you, we are getting somewhere now” said Gus, and continued “so it appears we had too many defects in the stories you were testing, so WHY were we having so many defects?”. A long silence ensued.

Peter broke the silence and said “For my user story, it turns out I didn’t understand clearly what Zach (the customer) wanted, so I had to change it four times”. Jimmy added “Yes, the same for me, this feature is complex and the work me and Mike were doing had to be changed many times, every time Jane or Rick would find something wrong because they’d ask Zach and he changed his mind, yet again”

Gus smiled and went “Oh Oh Oh, I think we might be getting somewhere here folks, what do you think Mike?” Mike was deep in thought, head down. He stood up and said loudly “I get it! It looks like a communication problem early in the process presented itself as a visible problem in exploratory testing. It’s got nothing to do with testing!” He was truly excited by the revelation, then he added “The root cause of the problem is the bad communication between the team and the customer and the symptom shows up in exploratory testing.”

Gus said “That’s an excellent observation Mike, do you guys think that if you clarified your doubts with the customer before you started working you would have saved the time you have spent reworking?” Everybody in unison went “Yeah!”. Well, now we know what the real problem is, I’ll chat to you tomorrow morning at the stand-up and we’ll find a solution together, it’s getting late now. Great work everybody and well done for getting to the root of the problem with only four why’s, I normally need five…”

Gus stood up to leave but stopped mid-track and asked “Guys, so do we still think we need more testers?” Peter was first to answer “No Gus, you’re right that was a knee-jerk reaction, thinking about it ,we need more clarity, not testers”

Asking why enough times to get to the root cause of a problem is a great technique, thought Gus while leaving the office and heading to the pub.

Stay tuned and find out what happens next!

The next episode is out, find out how they will resolve the problem!

 

 

 

3 Simple Steps to Help Overloaded Teams

dublin-rain-491-390x285It was a wet and dark morning in Dublin when I sat with team X for the first time.

I had been told: “Gus, these guys are struggling, they really need your help. They are always late, and everybody complains about the quality of their work, it’s bad, very bad”.

I expected a demotivated team of technically poor developers with its members playing video games or youtube videos instead of doing their job, but I was wrong.

No developer was slacking or pretending to work, on the other hand, I saw people with worried faces shuffling around, some listening to angry customers, some head down into code, some testing and quietly cursing.

To a newcomer, they looked super busy and doing their thing.

I perceived the first hint of trouble later in the day. I went to talk to some of them, just introducing myself and telling them that I was going to work with them to try to make their life easier. Each and every one of them was too busy to talk. All of them had something urgent, being a production issue, being a customer waiting behind their backs, or a release they had to finish by 5pm. Sorry, sorry Gus, I really can’t now, I have this blah blah…

I took it in and let them alone for the day. The day after, I kept on observing without saying a word. The amount of pressure that I saw applied on to these poor kids was frightening. In the same day I saw 8 different people go to the same developer and demand he finished something he was meant to have finished already. The requesters were different people and asked for 8 different things, all quite angrily.

The subsequent days, my observations stressed more and more this situation, the people were pushed over the limits and by trying to finish things quickly and relief some of the pressure were skipping steps and introducing new problems, new issues to work on, and so on.

I kept on observing and asking questions here and there, but the people saw me as somebody that couldn’t help them with the code, hence quite useless. I had to do something different.

On the 4th day, in the morning, after their standup, I told them to stop doing what they were doing and come and have a chat with me.

Believe it or not, It was almost impossible to get them off their seats.

no-thanks-were-too-busyThey felt they could not leave the sinking ship, they needed to continue trying to flush the water out with their hands. Did I have a powerful drain pump and could save the boat easily? They didn’t have time to learn how to use it, they needed to keep on shovelling with their bare hands.

I eventually got them into a room. We had a retrospective. I disguised the retro to be something else, because I had heard from one of the developers: “we don’t do retrospectives anymore, what’s the point if we don’t have the time to change anything?”

That’s a very valid question. Very.

The team was obviously overloaded and didn’t have the maturity and the necessary negotiation skills to express that to their customers and stakeholders. They had reacted to the overload with what I call the “headless chicken approach”. It works like this: “Just do all you can, forget about quality, process, product, customers, just run for your life and even if your work product is terrible, people won’t be able to blame you, as you work like a donkey every day.”

fuck-it-let-s-just-panic-and-run-around-like-headless-chickensDo you think this is uncommon? Well think again.

The first step we took was to visualise the work in progress. The guys were using Jira with no physical board and didn’t realise how much work they were really taking on. The board was scary, full scary I mean.

As the work came from many different products, another thing that we did was separating the products into different classes of service.

By doing this we immediately saw that one product had most of the tickets, why? We don’t know yet, but at least we are aware of it now.
After this very simple step  the team members started having conversations that were beyond the need to finish MyNewFeature, they started looking at current priorities and talking about the whys of the bad situation they where in.

Then they started talking about experiments to fix it.

They were improving the system.

I looked outside the window, the sun had come out.

p9220189_dublin_hapenny
What were the 3 steps we made that enabled the behavioural change?

  1. Acknowledge we were in an unsustainable situation that needed changing
  2. Agree the team had the responsibility and the authority to improve it with my support and management agreement
  3. Visualise the work they were already doing

 

Just this small change had transformed a group of intelligent people acting like headless chickens into people that were trying to improve a complex system, not bad for a weeks work I’d say!

If you are curious stay tuned and I will tell you what happened next, no more chickens, I swear.

The new episode of the story of Team X is out

On empowerment and the 2 types of downtime

Downtime
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.

 

 

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.

Cross-dysfunctional teams

Every agile enthusiast will tell you how powerful an empowered, self-managing, cross-functional team can be. Once you have one, it brings complete team accountability from product idea to customer support, it naturally grows with continuous improvement, and finds self motivation in innovation and delivery of customer value.

It’s a beautiful and powerful concept; the practical implementation sometimes is not so beautiful and more often than not what you get, is a cross-dysfunctional team.

Let’s have a look at the cross-dysfunctional examples I have experienced.

Pseudo specialist cross-dysfunctional teamfarm-silo

Developer: “I am a developer I am not meant to test, the testers test!”

Tester: “I don’t need to know anything about how the product is designed, I only care about how the customers use it!”

Business Analyst: “I am not technical, I can’t help you guys!”


devops“As Long As It Works for us” cross-dysfunctional team

Developer: “It works in our environments, it’s operations responsibility to make it work in production”

Tester: ”Listen, it worked in UAT, it must be a configuration issue, or a missing firewall hole and nothing I could have spotted during testing…”

Customer: “Hello! Nothing works here…”

Abdicating cross-dysfunctional teamheadinsand

Developer: “The architect told me to do it like this”

Tester: “Feck it, let the Test manager deal with it”

Business Analyst: “I don’t think there is any value in this story, but the Product Owner wants it, so get on with it and develop it!”


no-thanks-were-too-busyContinuous Decline cross-dysfunctional team

Developer: “No point in doing retrospectives, things are always the same”

Tester: “We DON’T HAVE TIME to try new things!”

Business Analyst: “We do it like this, because that’s how we do things here, and that’s it!”

Disintegrated cross-dysfunctional teamWorked-Fine-In-Dev-Ops-Problem-Now

Developer: “My code works perfectly, it’s their system that doesn’t work, who cares”

Tester: “We have 100% coverage, all our tests pass and we have no bugs, if the developers of system X are idiots, there is nothing we can do about it”

Customer: “And still, nothing works here…”


ihazsuperiorityNazi cross dysfunctional team

Developer: “Testers are failed programmers, they shouldn’t be called engineers”

Tester: “Developers are only able to produce bugs, the world would be better with more testers and less developers”

Business Analysts: “I don‘t know why I bother talking to testers and developers, they are total idiots”

Do you recognise your team in one of the categories above? What have you done until now to help your team change? Little? Nothing? But you are still bitching about it, aren’t you?

Remember, you are very powerful and can become the change that you want to see.

When something works, share it!

When I joined PaddyPower in October 2012 I was asked to improve quality without affecting throughput.  I studied the teams for a couple of months and I came up with this model based on Gojko Adzic’s Specification By Example and a white paper on ATDD from Elisabeth Hendrickson.

One year after, the bugs are a distant memory and cycle time has been almost halved, so I thought sharing the approach might be useful to somebody out there.

Here we go!

Acceptance Test Driven Development

Acceptance Test Driven Development is about people, communication, collaboration and delivering business value.

ATDD is a software development methodology based on enhanced communication among its actors.

ATDD uses high communications processes and tools to help developers write tests in a business language understandable by all actors. Such tests help developers focus on what to code. The tests can be automated and represent the blueprint of the application being developed. The tests live with the code never getting out of date. Any deviation between tests and application is communicated to the team in the form of a failing test. ATDD sits very well with many agile software development approaches including Scrum and Kanban and with XP engineering practices.

The Actors

ATDD Actors
ATDD Actors

Activities Artifacts and Goal

Acceptance Test Driven Development can be described using 4 activities (Discuss, Distill, Develop, Demo) 4 artifacts (User Story, Examples, Tests, Working Software) and 1 goal (Business Value). Each activity takes as input an existing artifact and produces as output an evolved version of such artifact until the goal is reached as explained in the Business Value Evolution train picture below:

Business value Evolution Train
Business value Evolution Train

The starting artifact is a User story, during the Discuss activity such artifact is transformed in Examples, in the Distill activity we transform the Examples into Tests, Tests are transformed in to Working Software during the Develop activity and Working software demonstrates Business Value at the Demo activity.

For this process to be successful it is fundamental that none of the activities is performed in isolation (by a single actor) . As many actors as possible should participate to any of the activities, specific actors’ requirement for specific activities are described later in this document.

One Source Of Truth

The first 3 artifacts describe requirements, the fourth is the representation in software of such requirements and the last is the final business goal. The Tests will represent the one point of truth about what it is turned into software and business value. Once the Demo is completed the User story and the Examples can be disposed and the only source of truth will be in the Tests. This is due to the fact that in the transformation the team will have learned a lot more about the deliverable than what it is described in the user story or the Examples. The tests will be updated during all activities to quickly adapt to changes and new discoveries, it is not necessary to retrofit such changes into User Stories or Examples. Tests stay forever and describe the application.

It is imperative that the Tests are at all time visible to all the actors. This means for example that having them buried into source control is not an option because business people don’t use source control.

Actors on the Train

The picture below expands on the Business Value Evolution Train by showing which Actors participate in which activities.

How it Works
How it Works

Discuss

Required Artifact: User Story – We need a business requirement to start from. This doesn’t necessarily need to be in the format of a user story, and it can be expressed in any format. What is needed is a business value to be delivered.

Required Actors: At least 3 members of the Development team should participate, ideally a  mix of testers developers and business analysts. Either one between Product Owner or Business Analyst need to participate to this activity.

Format: Meeting with access to a whiteboard

How it works: The Business Analyst has previously developed the user story through his conversations with the Product Owner, he will be able to explain to the other actors the user story’s business value. He will also be able to explain the conditions of satisfaction. Shared understanding of goals will guarantee the real goal is attained and not a consequence of somebody’s assumption

The conditions of satisfactions will be translated into examples, for example if the user story is about giving free delivery for customers that buy 5 books or more the initial examples might be:

5 books free delivery
4 books paid delivery

Questions will be asked and other examples might come out, for example

5 books outside Ireland paid delivery (if the product owner decides to give free delivery only for home users)
4 books and 2 CDs paid delivery
5 books and 1 washing machine free book delivery and paid w/m delivery

and so on…

By the end of the meeting the examples very likely will describe more scenarios than we thought when reading the user story for the first time and by trying to create concrete examples, few questions over the applicability of rules will be raised. If all questions have not been answered and the help of the Product Owner is required, the Business Analyst will get the answers from the Product Owner and have a quick catch up with the other actors to define the last examples. Having the product owner at the Discuss activity can make it more effective as most of the questions will be answered during the activity.

If the questions have unlocked some large uncovered areas and cannot be addressed by the Product Owner, more analysis will be required before we can proceed with the next activity.

Outcome1: Examples – Notice as the examples cover all the aspects of the user story plus those aspects that were not covered in the user story. If we add a 2 liner with the business value to the examples we have an improved version of the user story. The original user story is now out of date and can be expended.

Outcome2: The team have a common understanding of the business value of the user story

Outcome3: The discuss activity might highlight that the user story is too big to be delivered, in this case the activity will produce a list of user stories and the examples for the first one that is taken into development.

Distill

Required Artifact: Examples

Required Actors: Two members of the development team need to participate. At least one Developer needs to participate, ideally the developer that will be designing the code for this item. The second member should possibly be a tester or a Business Analyst, if they are not available, a second developer would do.

Format: Pair programming

How it works: Now that we have the examples written down, we can transform them into tests in a format that works with our test automation framework. There are a variety of test automation frameworks that support defining the tests in advance of the implementation including Jbehave and Cucumber. Tests will be written using the Given When Then format. Tests will cover all the examples that were identified as result of the Discuss activity. Extra tests could be added based on the improved understanding of the business goal.

Outcome1: Tests – The Tests cover all the aspects of the examples plus those aspects that were not covered in examples that were uncovered while writing the tests. The tests will also contain the 2 liner with the business value contained in the examples. Again we have an improved version of the examples.

Outcome2: The tests will be written in English so that every actor is able to understand and give feedback. The examples are now out of date and can be expended. The Tests represent the blueprint (documentation) for what we will eventually deliver. The tests will be highly visible and easily accessible at any time.

Develop

Required Artifact: Tests

Required Actors: Two Developers need to participate.

Format: Pair programming or Single developer writing code + Code Review

How it works: When implementing the code, the developers are following a test-first approach, they execute the tests and watch them fail. They will write the minimum amount of code required to get the acceptance tests Green. Once the acceptance tests are green he will manually verify that everything hangs together and will call another Developer or a Tester to perform Exploratory Testing. Once exploratory testing is completed and any defects fixed the user story is done and working software is ready to be delivered. While coding the developer might identify scenarios that were not identified earlier and add tests for them. Such tests need to be added to the previous set and shared with the rest of the actors. If the new scenarios identified represent a large amount of work a decision might be made that pushes the new uncovered scenarios to a subsequent user story or we could decide to deliver them.

Outcome: Working software + more comprehensive tests

Demo

Required Artifact: Working Software

Required Actors: The Product Owner and 2 members of the development team. Possibly the developer that wrote the software and the other actor that performed the exploratory testing.

Format: Meeting with large monitor

How it works: Before organising a Demo the development team needs to be sure the user story adheres to the definition of done. One very good practice is to create a demo script in which the demo facilitator writes down the steps to follow in order to demonstrate the user story business value to the product owner.
The demo should be an occasion for the development team to be proud of what was delivered.

The product owner will be able to use the Tests to validate all the required functionality has been delivered. At the end of a successful Demo, the product owner will accept the original User Story through the business value demonstrated by running the tests.

Outcome1: Business value

Benefits:

1) Shared understanding
2) Front load issue resolution => reducing defects detected at exploratory testing
3) Tests, for their nature, are specific and unambiguous. Using tests as requirements, developers will create their code based on specific and unambiguous requirements.
4) Developers can avail of the specificity of the requirements and avoid over-engineering
5) The tests are not written in a technical language and can be reviewed/discussed/improved by anybody with some business domain knowledge. Everybody can participate in designing the application by collaborating in defining the tests.
6) The tests are the one source of truth for the application’s behaviours. The acceptance tests live with the code and are executed in CI, they will always be up to date unless the application diverges. The tests are the application documentation. With new functionality come new tests or old tests get adapted to fit the new behaviours.
7) Increased communication builds trust and alliances between the actors
8) Increases transparency; the tests content and results are shared, easily accessible and have high visibility among all actors.

Pleasant Side Effects:

1) Acceptance tests are automated and as such they grow into a comprehensive regression suite
2) Can help Impact analysis. If we want to assess the impact of a change on our application we can simulate that change and verify what pre-existing behaviours it affects by reading the acceptance test results.
3) In the not so uncommon scenario of a re-write, if the original application was written using ATDD it is now possible to recreate the old functionality that needs to be transferred by reusing the Acceptance Tests

Acceptance Tests add no value and can be counter productive when…

1) When we write Acceptance Tests for anything but new deliverables
2) When we write Acceptance Tests to create a regression suite of an existing application
3) When we confuse Acceptance Tests with the tool for writing Acceptance Tests
4) When we write Acceptance Tests that do not give fast feedback
5) When we write Acceptance Tests that are brittle and difficult to maintain
6) When we write Acceptance Tests  that contain variables and parameters
7) When we write Acceptance Tests  that contain unnecessary detail
8) When we write Acceptance Tests  that do not focus on what the change is but on how to exercise such change
9) When we write Acceptance Tests  that test the application using the UI when the change is not in the UI
10) When we write Acceptance Tests in isolation and we hide them in source control
11) When we write Acceptance Tests as workflows/scripts

Finally, if you want to learn how to write better acceptance tests have a look at https://mysoftwarequality.wordpress.com/2012/12/14/how-to-transform-bad-acceptance-tests-into-awesome-ones/