In this, the second of two articles exploring the link between quality and collaboration, I want start by saying what I think collaboration is, who we want to collaborate with, and how Agile encourages collaboration. We’ll also tie this back to the issues of value and quality discussed in part one of this article. And, finally, I want to suggest that organisations and teams, transitioning to Agile, may require some help from skilled practitioners.
Teamwork vs collaboration
In this article, I’m using the words, quality assurance (QA) and testing somewhat interchangeably. I know that “QA isn’t just testing” but QA does require testing; not just software testing, but also testing fit for purpose, testing value propositions, testing assumptions about needs/requirements and so on.
I think this is worth mentioning because, in Agile, everyone is responsible for quality assurance. Everybody tests, and that includes testing the value of what we’re building. This is more than just teamwork, because teamwork is not, in and of itself, collaboration. You can have people working in a team, but they’re not necessarily collaborating in the way that we mean it in Agile.
In teamwork, a team leader, typically, shows the way. S/he probably plans the work and allocates it to team members.
In contrast, collaboration requires the team to estimate, plan, think, analyse, understand, decide, agree and work together with each team member taking responsibility for the whole, rather than responsibility for only the task(s) allocated to them – Agile team members don’t complete their tasks and sit back with a cup of coffee to wait for everyone to complete theirs.
If a team has eight people, that doesn’t mean responsibility is divided between eight people (responsibility / 8). It means that there is eight times the responsibility being taken (responsibility x 8). All eight are committed to the outcome and not just their own part of the outcome. They are collaborating and collaborators are equal partners. There is no team leader because the collaborators lead.
It’s tricky to create an environment where everyone agrees, but Agile seeks to provide plenty of opportunities to build consensus into the process.
I’m hoping we agreed (in Part I of this article) that different people have different perspectives on quality and value. I’m also hoping we decided that each perspective has merit and should be taken seriously. You may recall that the Australian government values Austrac being informed if someone deposits large amounts of cash into a bank account. However, it seems this perspective was not of primary interest to the development team, and that lack of quality assurance gave birth to a $423 billion problem.
So, we’re likely to get better results if a group of people includes these different perspectives. This brings us to The Wisdom of Crowds (The Wisdom of Crowds - James Surowiecki, Doubleday, 2004) which promotes a view that a crowd is generally smarter than the smartest people in the crowd.
There have been a lot of experiments around group intelligence, particularly in the first half of the 20th century. One classic example is estimating the number of beans in a jar.
Although the aggregated group estimate got very close to the right number, sometimes certain individuals in the group got closer. But, when the experiment was repeated, it was never the same individuals that got closer. Thus, it was the group that was consistently accurate while individuals were not.
To display this wisdom, a group needs certain attributes which include:
- Diversity - individuals with different perspectives, personal information, and their own approach and thought processes.
- Independence - to avoid “groupthink”. Groupthink describes situations wherein influential individuals affect the way everyone thinks. It’s a herd instinct that humans have and it helps us to be safe by not to standing out from the crowd.
- Decentralisation – people are free and autonomous, each bringing their own perspective to the group and feeling that it’s as valuable as any other.
Agile and collaboration
The Agile development approach is commonly driven by a Product Backlog, which is a list of all of the features, functions, fixes and constraints identified for this product. The entire product backlog is unlikely to be delivered in the first version of the product, which means it will probably be produced over a number of releases (different versions).
The requirements in the backlog are typically written as User Stories. A user story is a way of recording that someone has expressed a need for something. The story is a simple, minimally detailed statement. It says here’s who I am, this is what I need and this is why it will be valuable.
In project (Release) planning, business stakeholders, the Product Owner (PO) and team members (coders, testers, business analysts and any other required roles) decide, as a group, what should be in this release of the product by selecting and discussing relevant user stories to create the Release Backlog.
The work is then estimated and planned (by the group) across a series of time-boxed work periods, called iterations, of (commonly) two weeks. Each iteration will produce an increment of the final release.
At the start of each iteration, the PO (who represents the business) and team members get together to plan the iteration. The PO provides details about the backlog items that should be built first. The team members ask as many questions as they need to ensure they fully understand the requirements and then estimate how much they can actually get done in this iteration. Some negotiation may be needed but, once agreed, the team has committed to delivery.
Every day of the iteration, the team meets to understand what each team member completed yesterday, what s/he expects to finish today, and anything that might impede the team’s progress. This provides fast feedback on how good their estimates were at the start of the iteration. Someone may say “this turned out to be a lot bigger than we thought it was – we need to talk to the business/ PO about how we deal with that”. On traditional projects that often doesn’t happen until months into the project, which is way too late.
Anyone can attend these daily stand-up meetings, so they should be clear about any problems encountered. This means, at the end of the iteration, when people come together to review what has been produced, there should be no (unpleasant) surprises.
The business, PO and team members collaborated at the planning stages, and they’ve been collaborating during the process, so they know what to expect from the iteration. Nevertheless, people often don’t realise what they want until they see what they don’t want. In Agile, rather than this happening in a few months’ time (traditional lifecycle), it’s happening after two weeks.
After the iteration review, the team will get (crowd) together and decide how well the last two weeks went. They reflect on the things they did well and want to perpetuate, as well as the things that were problematic and can be fixed in the next iteration.
Clearly, I’ve identified a number of built-in (formal) collaboration points in this process but, beyond that, Agile promotes ad hoc face to face discussion and collaboration in its core values and principles which means collaboration should be a part of the team’s DNA.
Understanding the requirements
Requirements are initially recorded as user stories. Before we had supporting tools, we would write them down on physical cards (both side shown in the figure below).
We recorded the requirement (as a user story) on the front of the card. The user story is in the form as “as a role, I want to do something so that I will get some benefit”.
In the example above, a customer has booked a place on a course and wants to be able to login and access their booking details. When we get to the point where someone will build this piece of functionality, we will require more detail. We learn more about the story by talking to the PO and in doing so, we can begin to document enough details to build the function.
In this example, it has been done by using a mock-up to show what will appear on screen. On the back of the card, there are some criteria which are used to judge if it works as it should. This one shows the successful outcomes and the various error messages to be displayed if login is unsuccessful.
If you take the time to think about this story, it looks as if it was written by someone who did not collaborate with the right people. It seems unlikely (to me) that a customer wants to “login”. I can believe that someone booked on a course wants to access their booking details to check how much they are paying for the course, or when it begins, or something else of value to them. But this login requirement seems more like it’s from someone involved with site security, and that person only wants valid users to gain access to the system and its data.
If we misalign the requirement to some imaginary user, who will we go back to for confirmation that it meets their needs? In this case, we’d ask someone who has booked a course – why would they care? And, how useful would their opinion be?
Requirements should be from the perspective of someone who has a good reason to want this feature, because it has value and they will be dissatisfied with the quality of the product if it doesn’t deliver that value. This is why collaboration and quality should be in focus from the very start of product development.
Testers have always promoted the use of testing much earlier (left) in the lifecycle rather than at the end (right) of the development. The V-model tied testing to the earlier project stages by including static testing (reviews, walkthroughs etc) in the analysis and design phases.
Agile shifts further left into the decision and planning stages. More people, including coders and testers, are being brought into those stages to understand the context in which they will be working, and the effect of any decisions that people make when determining what to build and how to build it. Their different perspectives, knowledge and experience will bring the benefits of group intelligence.
There’s money to be saved in these early stages because we don’t move forward with decisions that have been made without everybody’s agreement and commitment. How many times have you heard someone say something like, “well, we wouldn’t have wasted all that time and money if someone had asked me about this three months ago”. Shift Left enables us to avoid unexpected overrun and costs while, most importantly, delivering valuable, quality products.
Collaboration and coaching
Quality comes at a cost but organisations pay a much higher price for lack of quality. I’ve seen this time and time again with, for example, a huge build-up of technical debt in legacy systems because companies keep applying quick (inexpensive and low quality) fixes to keep them running.
To ensure quality, Agile requires collaborative behaviour but, collaboration is a mindset and a habit. Enterprises can implement Agile processes but they can’t mandate a collective, cooperative mindset – that is a seed that must be planted, nurtured and supported.
Which is why businesses on the Agile journey use Agile coaches to help the transition. The teams are busy working towards delivery and it’s enough to be to focussing on that, let alone being simultaneously on high alert for signs that team members with newly acquired collaborative and Agile ways of working are slipping back into old habits. That is a different, but vital, role.