Communication Links

AgileCommunic

Few years ago Gojko Adzic tweeted following:

https://twitter.com/gojkoadzic/status/482506004102672384

 

Even today, several year after the tweet, people do not understand why agile team has to be small. The answer is communication links! Take a look on picture above. The dots are symbol of person in the team, and lines shows communication links in team. Example on the left is for team of five (10 communication links), example on the right for team of nine (36 links). Formula is very simple:

Connection Links=n (n-1) /2n , where n=Number of Team Members

In a team of 15 you will have 105 communication links(15*14/2=105).

Agile is about team, not about isolated knowledge of some individuals.

In trainings I still hear team members complaining about management, who placed timers on each desc, that people time their conversations and do not talk too much. But that is not about communication anymore. It is about company culture. There is a reason why they talk too much, find out what it is, instead of to forbid to talk.

Quality is the Responsibility of the Whole Team

Originally this article was posted 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.

Words Has Meanings – QA

Words matter. Words are the way we transfer ideas from person to person. Shared words do not guarantee shared understanding. I understand 4 languages and I try to understand 4+ cultures. Time to time I experience situations where I cannot express myself in none of the languages and my motives are misunderstood in all the cultures. At the moment I try to help my son with his Latin studies, it means I am kind of studying it as well. And it is quite fun because grammar is very similar to Latvian, but words to English and/or Italian.

You may wonder why I am writing about languages and what it has to do with quality assurance (QA)? You see, I really like quality assurance in software. I am very into processes, responsibility about the software and improving quality of an end product. If I would need to name one thing what I am good at, it would be seeing links/ matches/ connections. When I see a bug in the software, I see that it comes from a bug in the process. You can fix the bug in the software, then write and maintain 10 regression checks to get information when it happens again, but for me, more sense is to fix the bug in the process which caused the bug in the software.

One illustrative example. Imagine bakery. Good recipe does not guarantee tasty cake. Bad recipe does not mean that a cake will not taste. Testing in all this is trying the cake – quality should be baked in, if it is not in there, for this particular cake you can not change (improve) the quality. QA in bakery would be observing processes, identifying bottlenecks, questioning actions in place, analysing end products, which does not meet quality standards, with an aim to find a source, talking to customers and then decide what to do – to improve a recipe, approach, method, marketing or selling strategy. Another thing, I hope you all agree with me on this: if we call a bread as a cake, it is still a bread.

I really like to work efficiently and remove a cause instead of effects, so I applied for jobs with title “QA Manager”, “Head of QA” etc, but always at the end, thing, I was asked to do, was software testing. Don’t understand me wrong, I have nothing against software testing, I think it is great method to collect information about a software. But I kept wondered why companies and clients use “quality assurance” incorrectly. I broke it down and asked people what “quality” means to them and how they measure it; mostly got no answers and puzzled looks. How you can assure something you cannot describe and do not know how to measure? So I came up with this idea:
a) that they do not know about QA as a discipline;
b) it is some kind of strategic game played by companies: let’s put “QA” in our job openings and use the word “quality” few times on our website, then our customers will think that we care about it!

Let me tell you this – you can add sugar coating and glitters to your pastries, but everyone, who will eat it, will see that it is bread and not a cake.  If you call a bread as a cake, it is still a bread, right?

What Is Quality Assurance?

Note: This article originally was published by trendig in English and Deutsch.

Are you in charge of software projects at your company and facing problems with your software? Do you want to improve the quality and have no idea where to start? Then this article will help you to start implementing QA processes!

qa

QA stands for Quality Assurance and is a very important subject in the complex world of software development. We observe our software and find that it has discrepancies with customer expectations. A discrepancy in software is called a bug. If we remove the bug from the software, it does not automatically mean that it now works flawlessly. A requirement is the term for customer expectations for a system and it could be that the bug hides there as well. Sounds difficult, right? That is why we need dedicated QA engineers!

Assurance

Let’s start with the assurance part in QA. Spoiler: Nobody in the industry can assure that your software is flawless. Every software application has at least one bug, the question is: Do we know what it is, where it is and do we want that others (end-users, competitors, hackers) find it? Now that we accept that, we can move on. How can we ensure that we know about all the relevant bugs in our software? We test the software! We can also test all kinds of documents, design and code. Testers have a comprehensive toolbox on how to collect information about the system in test.

After some time of testing you will notice that there is a pattern of some kind (testers are really good in discovering hidden patterns) on how bugs appear or reappear. When you discover that pattern, one thing you might want to do is to reduce the number of known bugs or bug types from your product in the future. We can divide this process into two steps:

The first step is to analyze bugs in a software with the aim of finding the source. Why and how did a defect find a way into the software? Possible questions to ask: Is our system architecture too complex? Bad (or no) technical documentation? Vague or contradictory requirements? Do our people have the necessary skills to design/implement/test the software?

Second step: To define a set of actions and procedures to avoid appearance of the same bugs in the future. A typical approach might be: define a set of guidelines and standards to prevent this type of failure in the future, improve the quality of requirements by creating a checklist of what good requirements should cover, or use a specific tool to help us.

To summarize, with the help of analytical techniques we collect information about the software, with the help of constructive software quality assurance methods we prevent reappearance of bugs from a known source.

Quality Assurance requires processes and structure in order to analyze and improve software quality.

quality

Now we need to talk about the quality part of QA. To better understand the topic let’s use the analogy of a chair. If we need new chairs for our dining room, we go to the store, see 20-30 different types of chairs and feel lost. How to find the right model? Which chair can we describe as having good quality? Different people mention different things. For me, it is important that the chairs fit with the rest of the interior decor, and that they are stable and easy to clean (because of my kids). For my son, it is important that he can swing on it without the fear of falling backwards. The best way to address these needs, is to create a list of requirements. Do we need armrests? Should they be stackable? What kind of material/style/colour?

We do the same with software. We create a list of requirements and measure the degree of compliance. The biggest problem is that software development is a very complex process and many customers lack an understanding of it. Customer requirements influence up to 50 % of project success. That is why we talk about quality attributes. One way to classify quality attributes and metrics is the standard ISO/IEC 25010:2011.

Like testing, quality aspects can be applied to all kind of sources: software, subsystems, documents, single requirements, design and code. When starting a project, consider which quality aspects you will cover and what you will use as measurement. Choose it wisely, because what you measure, you will improve.

To illustrate the idea of quality, I used an example of finding a set of chairs, but software is a very complex system, more like a house. Quite often in development teams we hear customers saying: “We do not have the final set of requirements, but you can start and implement what we have so far.” This is wrong for many reasons, but I will mention just two of them. Firstly, a requirement baseline is part of the contract between customer and service provider and should be synchronised with a SLA (service level agreement). Secondly, imagine building a house and, when your constructors are halfway done, you have the idea to put a swimming pool in the basement. Will it work? No. It is the same with software. If you cannot read the source code and see software architecture yourself, it does not mean that it does not exist. Your software has a structure and developing it requires you to follow certain rules.

Conclusion

Software development is a complex process which involves specialists from different domains. Quality Assurance is a discipline which shadows SD starting with the gathering of requirements and ending with testing rollback scenarios, with the aim of finding errors as soon as possible, analyze them and improve the process to reduce or eliminate those types of bugs.

Find and fix errors as soon as possible to keep costs as low as possible.

Why do we do all this? Because prevention and reduction of errors as early as possible cost less than the rework involved in fixing the bug. In this case we can talk about build-in quality. It is a smart business decision to invest in effective software quality assurance.

If you want to read more about QA processes, we suggest you blogs from Janet Gregory and Anne-Marie Charrett.