Last week, we introduced our new framework, the Collaboration Hierarchy, and how trust is the fundamental layer to a collaborative culture. You can read that full post here: Starting with Trust.
Setting Clear Expectations
Once a team has a foundation of trust, the next consideration is setting clear expectations.
Do you know what is expected from you at work? What you are supposed to do most days?
Most of us understand what we are essentially supposed to do at work. We were hired to do a specific function that has a set of job descriptions to go along with it. We generally have a pretty good idea what we are there do.
Beyond that, are managers setting clear expectations for the group?
This is especially critical when your team is changing or when things are changing around your team.
One of our development teams at SmartBear recently switched to scrum. They do sprint planning and base everything on how many story points can be completed in any given sprint. So, as a team, they determine which tickets to pull into the sprint. Previously, they were assigned specific tickets, and that still happens now, but many would finish all of their assigned tickets and say, “I don’t have anything to do.”
In the case of scrum, we all need to be moving the football forward together. That means there are other tickets to work on, or developers that might need help, or testing that needs to be done so that we successfully finish the sprint.
The team is just getting used to having a new set of expectations and what it looks like to move forward together. This means that these expectations have to be reinforced constantly. At first, just about everyone was against it. Now, the majority appreciate the change. We started with one really large team by scrum standards and ended up splitting into two teams.
The first 5 sprint burndown charts looked like an EKG, but it is getting better. The team is starting to rally around their items and take ownership for completing everything. The daily standups and sprint retrospectives have been critical components to the team’s growth during the transition.
It is extremely important that individuals and the team as a whole have clear expectations. It allows for everyone to be held accountable.
Setting a Clear Definition-of-Done
In addition to setting cultural expectations within the team, they are also thinking more about behavior-driven development and agile test management. They are using Hiptest, a SmartBear tool which utilizes Gherkin Syntax to help all members of the team, including non-programmers, define the business needs as part of the Definition-of-Done. This aids the developers while they are implementing the feature and provides clearer expectations around the Definition-of-Done.
As can be seen in this simple example, you define the Feature and scenario, using Given, When, Then statements as the syntax.
So, you have an Account holder that wants to withdraw cash and has sufficient funds:
Given they have a sufficient balance and their card is valid and the machine actually has money in it, When the account holder request 20 bucks, Then the ATM should give them $20 and the balance should be decreased and the card should be returned.
By plugging our scenarios into Hiptest, we can then use that data to drive our test automation.
Building a Peer Review Process
A clear Definition-of-Done is important for development and QA teams writing code and creating tests, but it is also important for the people that are doing your peer reviews.
In peer reviews, there are a few common roles. An author will create a review and then invite reviewers. A scrum master may want to serve as a moderator so they can keep track of where a review stands. If someone is new to a team, they might be just be an observer on reviews.
By breaking reviews into roles, you can then set explicit expectations for each. For example, you could say that authors need to take the time to first annotate the review and explain why they made the changes that they did. This expectation might result in the author catching their own coding mistakes. For reviewers, you might want to set an expectation on when reviews should be completed after assignment. Consider using review checklists to ensure that each review has completed explicit steps before being marked done.
We recently ran a survey titled The 2018 State of Code Review. The respondents that stated that they knew what was expected of them when reviewing code and were more likely to be satisfied with the overall quality of their software than those that didn’t.
When the management team works with developers to set clear expectations for each role within the peer review process, teams find more defects and knowledge transfer occurs – which means you are raising up talent while improving quality.
Raising Up Talent
One of our customers decided that he was going to personally conduct every peer review for his team, over a 9-month period. His boss thought he was crazy, but agreed to let him try it. It was incredibly successful. Not because they improved quality or were able to capture metrics, but because of how much his team improved.
In every review, he gave specific examples of how to do things. Not because they were his opinions, but in reference to best practice books on coding and style. He didn’t always tell them the specifics on how to address something but instead gave them a pointer to the material and had them go read the resources on their own. His group ended up becoming the most successful group, from a financial perspective, in the entire company. It’s an amazing testament to the importance of developing people.
He set expectations for how reviews needed to be conducted and then coached the entire team on it.
Many people recognize that knowledge transfer across the team is a major benefit to peer review; however, we don’t necessarily put programs in place to support and encourage it. We just assume it will happen naturally. It does, but think how much more so if we were as intentional as the gentleman that spent 9 months doing it. He committed to raising up talent on his team.
Sharing Knowledge to Increase Your Bus Number
It is also important to remember that knowledge-transfer can occur when we review other artifacts as well. In this chart below, we can see that most teams are reviewing requirements, test cases, design documents and more. Document reviews are a key way to build cross-functional consensus on the big picture for a project.
Are you familiar with the concept of the Bus Number?
Your Bus Number is how many people on your team have to get hit by a bus before no one knows what is going on.
A more positive version of this might be someone winning the lottery and quitting. Regardless, you should always be thinking about training and coaching your replacement. Our goal should be to make it easy for someone to step in and takeover.
So, ask yourself: Who could step in if I were gone?
Take the time to coach them. Hopefully, it is only happening because you’ve decided to change jobs. The likelihood of being eaten by a shark is 1 in 3,748,067. Being struck by lightning is 1 in 79,745. Falling to your death is 1 in 4,238. What about the likelihood of leaving a job? 1 in 2 are considering it!
Marcel Schwantes wrote an article for Inc.com that delved into why employees really quit their jobs. He referenced a number of different polls and studies that contain some scary numbers:
- 51% of workers are looking to leave their jobs
- 74% of workers are satisfied where they are but 66% of them are still open to new opportunities
- 34% are planning on leaving in the next 12 months
- 44% of Millennials will leave in the next 2 years if they are given the chance
That means it is entirely likely that you will find yourself in the position of trying to piece together a project or supporting something not written by you, or that you’ll be the one leaving others to figure out what you have stored in your brain.
It is very important that you take the time to set up a culture of collaboration that sets the expectation of knowledge transfer. Believe it or not, you’ll actually retain more employees. People will begin to feel valued and start to take ownership – and that is the next part of the collaboration hierarchy.
Stayed tuned for our next post in this series, "Promoting Collective Ownership".
If you want to read the full ebook on "Building a Development Culture of Collaboration, you can download it here: