The Collaboration Hierarchy: Setting Clear Expectations

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.