Vladislav Kochelaevs - Fotolia
It's easy to get caught up in new techniques like Scrum, Agile and Kanban by implementing the rules to the letter but missing the point. The single greatest example of this may be in software project collaboration. It's an easy thing to say, but how does one "do" collaboration?
This article explores what problems collaboration solves, what team collaboration looks like, how to get started and a few traps to avoid.
Problems that software project collaboration solves
If you look at a software project a little sideways, you can almost see it as a set of handoffs. The customer works with the project manager to set direction and intent; the project manager takes that to the analysts who define what to build; and then they pass that to the architects who create the technical architecture. The architects pass to the programmers, who then pass to the testers.
The "handoff" approach involves creating a document, email or "ticket," and passing it to the next person. Try as we might, we can't ask a document questions. We can get stuck, not having all the information we need to accomplish the task or, worse, believe we accomplished the task and fail by not delivering what the customer needs. That information might have been found at the next step, which means rework, or it might be found by the customer causing even more rework and possibly damaging our reputation.
Or we could ask a question; but in a handoff environment, getting an answer could take days. This delays the project without adding any value. To fix this, people spend a lot of time typing even longer documents which can make finding out answers even harder. The fix for all of this is collaboration.
What software project collaboration looks like
Paula, a programmer, wants to begin work on a new feature. She pulls up the story in her work-tracking tool, then walks over to the product owner and the tester (who sit together) to discuss what to build. Paula's goal is to move the idea from concept to practical, to build a shared understanding of what to build before she builds it. This prevents building the wrong thing. Tom, the tester, asks questions to make sure he understands the use cases. He explains what he would check for and is told immediately "Oh, we never thought of that." The three prevent a defect that would have caused three days delay.
The point here is not to create a new meeting or a new process; we could have done this 15 years ago in the days of the waterfall. The point is to get people to talk together, to discuss possibilities, to make sure we know what we need, instead of focusing on role, responsibility and definitions. We are also admitting that a tester might have an idea that becomes expected behavior of the product, or that a programmer might show a shortcut that has 90% of the functionality for 10% of the work.
Getting started with test collaboration
I've discussed one kind of collaboration, the story kick-off. The daily stand-up meeting can be another -- not a status meeting, but a chance for people to ask for help. It can provide a tester with the opportunity to ask for, say, a new user ID with very specific permissions, along with the opportunity for someone to sign up to help right after the meeting, not when they get around to it.
While we're at it, get someone to show the tester how it is done. Do it together, right after the meeting -- don't force the tester to fill out a ticket that will be processed when the ops team is available. All that is code for injecting wait states into the project without value.
Next, look at how ramp-up happens. At many companies, ramp-up consists of giving the tester some documentation on the work process and the first assignment. The new tester tries to login, but can't get into the requirements portal. Once they are in, they don't have a user ID to login, and need to create a test environment. The test environment creation tool requires permission, and so does the database, and so on. The result is a lot of waiting and questions.
New-hire onboarding is a chance for software project collaboration. Pair a senior tester with the new hire. Work the problem as the new hire; when they hit a permissions issue, ask for the help but move on using the senior person's permissions. That keeps the pair moving forward. The new hire comes up to speed faster and two can learn from each other.
The dev-test handoff doesn't have to be a handoff. Instead, it can be a demo and exploration at the programmer's desk, where the programmer shows the tester the intent. The programmer is spending this time trying to make sure the tester understands the user interface (to prevent confusion) and also to make sure the tester has everything needed to start -- like user IDs, passwords, URLs, configuration and setup. If the two find bugs during the demo, they've prevented an entire cycle of multitasking and waiting; even if they don't, it prevents interruptions that come from confusion, misunderstanding and the tester not having what he needs to start the task.
Bug bashes, where the entire technical staff tests the product for a limited period of time (usually with pizza involved) might be a collaborative event; the key is to get people to talk. The most common way to do this is to pair a tester with a non-tester. Another way to do it is to have the testers from product A test product B for a day, and vice-versa. Johan Atting, the chief quality officer at Sectra in Sweden, refers to this as "cross team testing," or "mixup testing."
What can go wrong in software project collaboration
Instead of defining clear roles and contracts between them, collaboration expects people to contribute in unanticipated ways, based off of ideas they get from each other. It is an entirely different way of working, and it can be easy to misunderstand. It's common for team members to miss the point and think of the effort as more meetings that distract from the work. The point is to get the work moving faster, eliminate blocks and waits, and invent new ideas together.
For software project collaboration to work, people need to reveal vulnerabilities. If they won't, or can't, reveal vulnerabilities then working together devolves into trying to look smart, and proving why one idea or another is bad. The team slows down and fails to realize the value. So watch the tone of the conversations. If possible, model good collaboration by example. Be vulnerable and reward vulnerability.
Collaboration spreads knowledge, removes blocks and wait states, and finds and fixes problems early. Get started by blurring the lines between roles, moving toward demos and conversations instead of assignments, handoffs and tickets.
New collaboration tool released
Project manager fosters collaboration