Quality is the Responsibility of the Whole Team

Originally this article was postet on trendig.com English & Deutsch

Since 2001 we have the agile manifesto in place and since then the whole industry is learning to use agile principles and values in their daily work of software development.

 

agile manifesto

The Agile Manifesto guides teams through agile transition and in their daily work of software development.

One of the problems I see, is that many who claim to be working in an agile environment have never read or really understood the agile values. While consulting teams or giving trainings, I’ve heard countless times that the Agile Manifesto says everything that is on the right side is what we should not do, e.g. in agile we have no plans, no contracts, no documentation or processes. I got to know a team who lost their software architect in agile transition because architects are not mentioned in the Agile Manifesto. Now they struggle with huge technical issues and there is no one who can help them… But it is not meant to be like this! The Agile Manifesto states that value is in items on both sides, but if we have to choose, we are choosing items on the left over the ones on the right. Logic says we have to have all items of the Agile Manifesto if we want to deliver sustainable software and improve our delivery cycle. The aspect that agile methods wants to highlight is, that documentation, plans or contracts are not the aim of the project, but are supporting tools. The aim of agile projects is always to deliver working software, have valued team members, and promote collaboration with customers and value responding to change.

 

the whole team approach

The way in which we achieve the values and the principles described in the Agile Manifesto is using the whole team approach. Since it changes fundamentally how we work together in a project, you can say it is a new style of project management in which everyone on the team is held equally responsible for the quality and success of the product.

The Whole Team Approach supports the 5th principle behind the Agile Manifesto.

Professionals in software development know that each development decision is a quality decision as well. The Agile Manifesto sets it as a top priority. Software quality does not depend on the software development model that we use, but on the method how we all together as a team structure the whole software development process. Together, we use tools and activities which support the achievement of high software quality. One of these activities is testing.

 

what does testing mean?

Everyone around the world knows or can imagine what “software development” or “project management” are, but very few can say what software testing is, how do you do it and, most importantly, why?

10 years ago when I started my career in testing, there was the statement: “everybody can test” with the meaning that you do not need special skills to test. Today I often state myself: “everyone can test software”, – meaning everyone: developers, software architects, product owners, support people and operations – everyone, who can analyse information and build a mental model of it, to discover invisible strings and deviations between software and requirements, business regulations, standards, norms and legal regulations. Testing is an intellectual sport. But we are more used to say: Testing is the process of how we collect information about our product with the aim that, based on this information, the team is able to decide what to do next.

Two types of testing are very important in an agile context: automated regression and exploratory testing. With regression tests we collect information about software features which are already in use by users, and with exploratory tests we are learning about software features that we are currently developing.

If you run tests and your team cannot make decisions based on information your tests collected, your tests are not adding value. If you write weekly reports and nobody on your team reads those, your reports are not adding value. If there are 12,000 automated tests and no one can articulate what they cover, the automated tests are not adding value.

You may still have a tester on your agile team that acts as a coach for testing techniques and does some of the testing, but on an agile team, everyone should be able to collect information about the current state of the software. Remember: quality is the team’s responsibility.

the challenge of change

The essence of the whole team approach lies in the testers, developers, and the business representatives working closely together at every step of the development process. Because the whole team is responsible for success and quality, the whole team or at a minimum, representatives from each specialty – see three amigos  – is involved in every consultation or meeting in which product features are presented, analyzed, or estimated. For many organisations and individuals, it can be a struggle.

The first attempt to switch to an agile software development, in my experience, in 90% of cases looks like a 2-week-waterfall development. It is hard to change a person’s way of thinking or collaborating, a company culture or processes already in place. People and companies have to break deep-rooted processes, e.g. working in silos or not listening to junior members. Give it time and recognize people’s fears – it is scary to change! Some fears that people have expressed to me are:

  • “How exactly should I support my team members?”,
  • “If everyone should be able to test, what should I, the tester, do?”
  • “If the whole team decides on issues, what should I, the project manager, do? Is there still a job for me?”,
  • “According to our HR guidelines and my job title, I am a senior developer, but I never really understood testing. What will happen if others find out?”

All of those are valid questions and should be addressed.

Janet Gregory and Lisa Crispin were two of the pioneers in agile testing. Many agile testers call their book “Agile Testing” the Bible, because it was the first comprehensive book about testing in an agile context. Today they have the extension “More Agile Testing” and the 3-day hands-on training “The Whole Team Approach to Agile Testing and Quality”, for whole software development teams, with games and exercises on collaboration, planning and agile testing quadrants. I train this course myself because I am convinced that I can give many team members valuable knowledge for the implementation in their daily work. But whether it’s a book or training or reading blog posts or just trying things out for yourself: I encourage everyone to take a look at the whole team approach, because it is an important step forward when the entire team feels responsible for success and quality.

More Agile Testing > Testing Business Value

This is digitalised collection of testing resources created and published by Lisa Crispin and Janet Gregory in their book More Agile Testing: Learning Journeys for the Whole Team“. For more details on their work, visit http://agiletester.ca.

Already digitalised and checked parts: Introduction, Learning For Better Testing, Planning. Comming soon: Investigative Testing, Test Automation, What Is Your Context?, Agile Testing in Practice.

Part IV: Testing Business Value

Books

Articles, Blog Posts, Slide Decks, and Websites

More Agile Testing > Planning

This is digitalised collection of testing resources created and published by Lisa Crispin and Janet Gregory in their book More Agile Testing: Learning Journeys for the Whole Team“. For more details on their work, visit http://agiletester.ca.

Already digitalised and checked parts: Introduction, Learning For Better Testing. Comming soon: Testing Business Value, Investigative Testing, Test Automation, What Is Your Context?, Agile Testing in Practice.

Part III: Planning—So You Don’t Forget the Big Picture

Books

Freeman, Steve, and Nat Pryce, Growing Object-Oriented Software, Guided by Tests, Addison-Wesley, 2009.
Galen, Robert, Software Endgames: Eliminating Defects, Controlling Change, and the Countdown to On-Time Delivery, Dorset House, 2005.
Gottesdiener, Ellen, and Mary Gorman, Discover to Deliver: Agile Product Planning and Analysis, 2012.
Hendrickson, Elisabeth, Explore It! Reduce Risk and Increase Confidence with Exploratory Testing, Pragmatic Programmer, 2013.
Hüttermann, Michael, Agile ALM: Lightweight Tools and Agile Strategies, Manning Publications, 2011.
Whittaker, James A., Jason Arbon, and Jeff Carollo, How Google Tests Software, Addison- Wesley, 2012.

Articles, Blog Posts, Slide Decks

More Agile Testing > Learning For Better Testing

This is digitalised collection of testing resources created and published by Lisa Crispin and Janet Gregory in their book More Agile Testing: Learning Journeys for the Whole Team“. For more details on their work, visit http://agiletester.ca.

Already digitalised and checked parts: Introduction. Comming soon: Planning—So You Don’t Forget the Big Picture, Testing Business Value, Investigative Testing, Test Automation, What Is Your Context?, Agile Testing in Practice.

Part II: Learning for Better Testing

Books

Blog Posts and Online Articles

Courses, Conferences, Online Communities, Podcasts

More Agile Testing > Introduction

Two weeks ago on Slack, we talked about collections of good resources and Lisa wrote that she and Janet created a good one, but it is not available online. I volunteered to digitalise it and she agreed. Since then I am checking links and reading articles. What can I say – it is an AMAZING collection! Thank you, Lisa, for your kind allowance to publish the list online.

This is the bibliography list created and published by Lisa Crispin and Janet Gregory, More Agile Testing: Learning Journeys for the Whole TeamFor more details on their work, visit http://agiletester.ca.

Part I: Introduction

Books

Websites, Blogs, Articles, Slide Decks

 

Women In Agile

atd_womenleancoffee

Agile testing days organized this year something new: “Women in Agile Summit”. Great idea, difficult subject, wrong conference day – night after the conference has been closed. Not enough public information that without men, discussions are meaningless. And in fact, the person, who closed the conference, forgot to mention the upcoming event!

I arrived late but brought seven men with me. They had a hard time between choosing to drink a beer and guiding me to something-with-women-thingy. All of them chose to be brave and face the difficult topic. Bravo! But it is getting better – as we started our lean coffee session we got another member. We collected our topics, voted and as we just started our discussions, time was suddenly up and all teams were asked to present their results. So we did not really have a chance to discuss our topics as a team, but to our surprise, we got unexpected feedback to our presentation:

  • first of all because of men: women ratio in the team
  • gender of the person, who presented the team results
  • discussion topic “beer bet”
  • usage of the word “female”

No matter that the conference was extremely friendly and Maaret as Women-In-Agile facilitator was very inviting, the atmosphere was intense and spiky. Yes, we were late and yes, we did not have a lot of time, but as I talked to Garreth afterwards, we both had a feeling that no matter what would our team present, we would do it “wrong”. Even during open discussion about women role in tech, we still try to mould participants in old stereotypes.

Before I continue to share my personal views about this difficult topic, I need to share some background facts:

  • I am a woman
  • companies where I worked and work, male are a majority. In two companies I was the only woman with ratio 1:15 and 1:50.
  • the most terrible thing what can happen to a woman in tech, that she is invited/promoted because of her gender, not because of ideas she present

For example, my personal aim for this year was to become a testing conference speaker. I accomplished it with the talks at Belgium Testing days and Agile testing days – both are women friendly conferences. I am very proud of myself, but in the same time, because I know about women-in-tech-promotions I cannot be sure that I got my chances because of my stories or because of my gender. My hope is that time will show what is what. But for now, for 2017 I set another aim – to talk in non-testing conferences. Till now – only rejections.

The thing about diversity is the same with excess weight, you close the eyes and hope that one day it will disappear just like that, without any effort. But deep inside you know that if you want a real change, you will have to work hard and disciplined. And it will take some time until first results become visible.

Conferences are mostly organized by men and mostly men are invited to present. They speak in one language and have a similar set of values. But men are not only one to blame. Women need to lean in more and not get scared by the first decline. I know what I am talking, I heard a lot of NO’s. But the only way how to keep going is to keep going.

This is my pattern how I do it:

  1. do not wait for permission
  2. do not think what others will think of you/your work
  3. do not give up

Some of the companies, where I worked, had no-feedback-is-good-feedback policy, in other rules of procedures. In both of the cases you can get old while waiting for permission to work on something. So I started the following pattern: inform the manager about solutions or ideas and if there is no immediate feedback, like “NO, DO NOT DO IT!”, then I proceed with implementation. With a time I learned that that was exactly what was expected from me after informal part. No feedback is approval!

Other two things mostly are supporting the first one. To imagine what others will think about my actions takes too much time and energy. Time and energy which I need to proceed with my aims. Reduce the waste, get rid of everything what is holding you back. And just keep doing what you love to do.

At the end, dear men, do some fact checking from your past and present and recall when did you last time thank or praise your women colleagues for a good job?

Where Are We Going?

Some use Twitter to keep up with latest news, I like to read newsletters. Already long time ago I subscribed to several local testing & co newsletters. Here are two conference posts who made me think lately. Is this where we are heading?

The first conference is/was Swiss Requirements Day.

It was huge surprise to receive the last newsletter with subject “Rest in Peace Swiss Requirements Day” with the message:

“Dear Swiss Requirements Community
In acknowledgement of the changing environment, the Swiss Requirements Day lays itself to rest.
Digitalisation marches swiftly on; delivery times are getting shorter and shorter; agile is on everyone’s mind. There is no time for a thorough analysis and documentation of requirements. Or is there? What preparatory activities are needed before coding can begin?
Design Thinking, Human-Centered Design, UX, Business Analysis, Systems Engineering and yes, also Requirements Engineering, are central elements.
Against this changing backdrop, we say goodbye to Swiss Requirements Day and proudly welcome its successor, the Upfront Thinking conference.”

OK, they are kind of closing one and opening another conference… if it would be just a change of name, than why so alarming sentence: “There is no time for a thorough analysis and documentation of requirements.”? Is this agile? Do we really want to have software which is made without thorough analysis?

The second conference is Topconf Linz 2016, will be held on February 1-3, 2016.  If you wonder what is Topconf – here is what they say about themself:

“Topconf Software Conferences are premier international software conference designed for Developers, Product owners / managers, Architects, Project Managers, Methods- and Process-Experts.
Our speakers are authors, experts and practitioners across various areas of software development.”

I find it quite interesting – various areas of software development and all kind of job titles but nothing related to testing.

Any way – my attention got something else – Talk by Louise Elliott Punishment Driven Development. She got me! I really want to go to the conference and to see how she will put that all together – punishment, guilt and agile. Interesting that this talk is on New Ways To Manage track.

What About Agile

I am big fan of Dilbert.

I like how in few pictures he captures the essence of software development, but in the same time I am ashamed, because I am part of it.

My trouble lately (several years to be specific) is agile. I have no trouble with methodology itself, but the way it is used. I struggled around till I saw this:

I did small research – talked to people and by the way asked about their info source on the subject. Some of business people really said that they have no idea what it is, but they learned that that’s the thing what sells. Agile is new sexy!

I start to think, how could I explain in small talk, how I understand agile and why it is worth to get to know more about it. Trade magazines often points out the speed as a key value, but never tells you how to get the speed. By pushing just accelerator you will not make very far on bend and bumpy road.

So let’s go back to the basics. First value on agile manifesto says:

Individuals and interactions over processes and tools

Fifth principle of agile manifesto:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Individuals, motivated individuals… and trust them! How about that?! The trust. Whom do you trust?

I did small survey (that’s the thing I always do if I am on something) and got shocking answers. My responders do not trust their colleagues and will not address the issue, no matter that they agreed that trust among the colleagues is very important.

As more as I think about the trust as much, I think that may be it is the source of my struggle. Current society are so focused on career and success that we forget about individuals and trust at a workspace. This project is just a step to next big thing.

As a tester I wonder quite a lot about things, what I thought is common sense, but turned out that it is just my sense and I have to explain it to others or write a bug report :) . I think that trust among colleagues is nothing agile-unique. And also satisfied customers and working software should not be something extraordinary – isn’t it something “by default”? Why we need manifesto for that? And if someone wrote manifesto for all that, why do we grade it by doing not properly?