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.
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
There is one thing that bugs me about mind maps as a testing tool, it really bugs me a lot.
Don’t get me wrong, I find mind maps a great collaboration tool to get ideas out of people’s heads and put them on paper. They are great for designing a test plan, a few testers can sit down, brainstorm and create a map that can be efficiently used as a complete plan.
So what bothers me so much?
This: “Why don’t we do the same exercise together with the developers before the code is written?”
Are we so obsessed with finding bugs that we cannot share our thought process and help PREVENT (yes prevent) the defects instead of catching developers out and wasting customer’s money and time?
I really hope that somebody out there will give me a valid reason why we shouldn’t shift left the mind map creation and prevent the defects instead of detecting them.
Otherwise we should start doing it now, no excuses.
“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.
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, collaborationand deliveringbusiness 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.
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:
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.
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.
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.
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
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
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
I have been working with agile teams for a few years now and I have used a flavour or another of BDD almost since the very start of my journey. Like everybody I used it badly at the start, misunderstood it and made a mess of it for a good while. Unlike others I have no problems admitting it. Mistake after mistake, fuck up after fuck up I learned a lot of things and today I believe I have developed a decent approach that I will try to improve. Through these years of many failures and small successes one thing clearly emerged for me and it is I believe the true value of BDD.
To me BDD is about communication, collaboration and delivering business value.
The most important part of it? The discussions you have with your team just before you write the tests.
The inherited automation, the derived documentation, the shared knowledge, the reduction in gold plating are side effects and it’s nice to have them, but the real value is in the conversations. The conversations where the team explores new grounds, the conversation where if you want to add value, it doesn’t matter how senior or technical or business savvy you are, what it counts is how much you care about your customer.
You can’t avoid them; they are in every discussion: tools, tools, tools and more tools.
There is no question on bugs that doesn’t get an answer like “open a bug in Jira and bla bla bla…”, every topic on performance have a Loadrunner or Jmeter here and there, no functional testing discussion seems to be worth its while if somebody doesn’t mention Selenium or QTP.
If you suggest somebody to talk and discuss the issues they have, somebody will jump in with the tool that will solve the issue straight away.
The CVs I review are festered with tools, some people with 3 year work experience claim they can use more tools I have ever used in almost 20 years.
Reasons why some software delivery teams don’t give a damn about their customers
It feels like a century ago, but once upon a time, less than a century ago, I was leading a traditional test team in an organization where 3 separate teams of Business Analysts, Developers and Testers were delivering software in an incremental iterative death march style. Each of the 3 teams had its own leads and managers and each of the 3 teams was measured by specifically tailored metrics. My team’s efficiency was to be measured based on the mighty DDI Defect Detection Index calculated as DDI = (Number of Defects detected during testing / Total number of Defects detected including production defects)*100. The DDI had to be greater than 90% otherwise our team would have been deemed inefficient, bonuses dropped and the test team itself branded as a bunch of losers.
Yes you guessed right, the other 2 teams were measured in a similar way, their efficiency was also based on number of defects, the lowest the better.
God I am glad this is only in the past. Even remembering this makes me sick in the stomach. Sick like every time a production defect was detected, sick like every time a defect that our team detected was rejected, sick like every time I had to go to the triage meetings and inevitably have an argument either with the BA lead or the DEV one because that defect that we found was not seen as a possible improvement for the product but as a threat to some team’s metric. I’m not even going to describe to you the awful discussions that followed the acceptance of a defect as valid when a decision had to be made on whether the defect was due to bad requirements or bad code.
The funny thing was that no matter which was the efficient team and which were the inefficient ones, the software delivered was the same, no change whatsoever, the customers were constantly quite unhappy. The real value that the metrics gave to the department was the ability to point fingers based on numbers. They say numbers never lie, maybe numbers don’t lie but how many lies can we tell to fabricate numbers?
Since then many things have changed in my professional life and today I don’t have to fight stupid battles to fabricate numbers in order to define efficiency so I can, funnily enough, use my time more efficiently.
Why calculating confrontational metrics doesn’t work? The problem is in the fact that we are humans; if you attach prestige and monetary value to a metric, the metric becomes the goal of the team and the battle can begin. The test team doesn’t care how useful the product delivered is, all they care is opening as many defects as possible so that the mighty DDI doesn’t go under 90%, if this means opening defects that are absolutely no harm to the customer but only to the development team and the schedule it doesn’t matter. The same logic can be applied to development and the BA teams that will spend their time obfuscating their requirements and defending their code from the stupid defects opened by the test team. All this creates a climate of tension, distrust and hostility. Nobody really cares whether the customers are happy as long as the individual teams metrics solemnly declare their efficiency and fingers can be rightly pointed :-(.
The funny thing is that it is very easy to resolve this problem and put the focus back on the customer. Create a cross functional self organising team able to analyse, develop, test and deliver a complex software project and judge the team on how well they satisfy the customer needs. The team lives as one, produces quality as one, delivers customer value as one, succeeds as one or fails as one. The goal of the team matches the goal of the company and failure or success of the team determines failure or success of the company, it’s called agile team, try it out!