One Team – One Mission

“Gotta Keep ’em Separated”…. really?

So here you are, setting up your new project. And what do you need? A couple of Devs and then some people doing QA? Right?

Wrong.

 In past many software projects have separated development and QA or “testing” duties into different teams. This trend has been changing over the last few years to have only one team with devs and a couple of QA’ers.
It’s a step forward but we’re still not where we want to be:

 A single, unified team able to take on the different duties as needed.

And here’s why it matters:

1. Goal Orientation

Separating Dev and QA even if it is just by assigning these duties to specific people immediately creates differing goals for these groups. Devs will want to release software, to complete their stories and move on with the next task. Who blocks their progress? The QA’ers or “testers”. The QA’ers on the other hand have the goal of providing test coverage and preventing defective deliveries from being released. So they have to “clean up the devs’ mess” all the time.

Who of these people actually has the unified goal of both RELEASING and having GOOD QUALITY? Usually no-one.

If there is no-one specifically assigned to Dev or QA duty it no longer becomes a matter of coding something or getting it tested – it’s now a team goal to deliver results.
The difference might be subtle but it’s actually quite the game changer.

2. Flexible Assignments

Depending on how a project might progress the Devs might actually deliver new functionality faster than QA can cope with testing coverage. While unit tests should be present given a TDD environment (more on that later) the system and end-to-end tests also need to be done and they can be a huge time-sink. In other cases QA might be comfortable keeping up with the Devs but (or because) they are falling behind in their project plan.

Neither situation is ideal. And instead of having to bring in new staff it’s a lot easier to shift people into different areas as needed.

And this is A LOT easier if no-one clings to a specific position in the first place. That way workload is automatically balanced as needed by the team and project as the overall success (see #1) is a shared goal.

3. Skill Mixture Needed

When looking at test-driven-development it becomes clear that a developer can no longer concentrate on just creating code. A considerable degree of testing knowledge is also needed to provide the necessary (and effective!) test coverage.

When looking at the QA side the times of grinding through a sheet of manual tests is coming to an end. Initiatives such as CI and DevOps mandate fully automated testing from day one. However this testing automation does not magically appear, it requires a lot of coding on the QA-side of things. This requires a considerable degree of programming knowledge.

All things considered a developer can no longer work without testing knowledge and a QA’er needs programming knowledge. Mixing skills and knowledge in a team is therefore absolutely necessary.

The Bottom Line

Modern projects require a team that is aligned with a shared goal – to deliver a high-quality product on-time. Constantly changing needs and requirements make it necessary to be able to shift workloads quickly and flexible without being tied to specific people or teams. And with the TDD/CI requirements of modern DevOps-driven projects the skill separation between Dev and QA has become non-existent.

It’s okay to bring in people with different skills together – but in the end it requires a combined team effort to be successful, not the combination of a few loose parts.

Fund Teams. Not Projects.

Who hasn’t experienced the following scenario:

A project was canceled and suddenly you have a lot of people that need to be either relocated to other projects removed from the company.

The reason why this happens is that investment is attached to projects. Following the basic business logic projects are a way to convert some money into more money – or at least more money that other alternatives would generate.

As a result of the available funding teams are assembled to follow the project’s vision through and create something that will ultimately return multiple times the investment.

While I agree with the notion that businesses are there to make money I strongly believe that basing team coherence on the association with projects can be hazardous and costly for the company.

And here is why.

The Constant Reset

Based on Tuckman’s observations on team dynamics we know that teams are not simply created – they evolve over time. Going through the phases Forming, Storming, Norming, Performing (and Adjourning).

 Not surprisingly a team is most productive in it’s „Performing“ phase. Team members have gotten to know each other, working standards have been established and trust has been built. The team can focus on delivering.

Reaching the „Performing“ phase takes time – sometimes a lot more than six months. Now add to this fact projects that are the basis for the team’s existence. As soon as there is a change in the project – for example cost reductions leading to less head counts available – the team dynamic is disrupted. The team will most likely revert to an earlier stage such as Storming leading to conflict and severely reduced performance.

 Previously this was less of a problem as projects tended to run longer usually for years.

With the advent of Agile development we will (hopefully!) see smaller more nimble projects, coming to life and retiring in reaction to the business needs.

While this nimbleness will certainly bring with it a lot of benefits such as lowered monetary commitment and risk it also carries with it the cost of team coherence.

A team that is constantly being reassembled because it’s underlying project is frequently changing will rarely have the time to settle down and get to the „Performing“ stage.

The team dynamics will be constantly reset to their infancy.

The Cost of Constant Team Changes

With team members constantly having to go through the earlier stages of team development they are tied up getting their bearings and finding their spot inside the new team.

This takes away time and energy from their capability to perform the job they were hired for leading to decreased performance, lowered satisfaction with their job and in extreme cases even workplace aggression (See also: Workplace violence and workplace aggression / Baron, Neumann / 1996).

Another potential problem is the negative impact on the willingness and/or ability to form (professional) relationships with co-workers.

Just think about it: If you know already that all these other strangers on your team will be none of your concern in less than a year why bother getting to know them? Why spend the energy and time to socialize if you will have to go through the same steps again in the near future?

This problem is very similar to the one faced by children having to constantly relocate during their childhood ultimately being less capable of forming lasting relationships, having lower life satisfaction and expectancy (see also June 2010 issue of Journal of Personality and Social Psychology).

Both of these problems are amplified when the teams are not co-located.

Integrating remote workers is a challenge on it’s own.

Most literature focused on virtual teams will cover the feeling of isolation and lack of integration with the overall team. Why? Because these issues can be just as problematic as the ever-present challenge of effective communications. Many experienced leaders recommend overcoming these issues and creating a feeling of belonging by engaging the team members in conversation, getting to know them, listening and showing your appreciation for them not only as a professional worker but also as a human being.

 Now imagine having to go through this every few months – either as a leader or a professional.

 Taking into account the above effects of constant team changes can create a negative impact the on business in the form of lowered performance and employee satisfaction that quickly outweights the benefits of being able to reshape the team landscape in reaction to the market.

 Having said that – what can be done both reap all the rewards of being Agile and responsive while creating a pleasant work environment?

Fund Teams – Not Projects

Putting the money where the people are might sound obvious – but it’s quite a change from the existing funding approach.

The idea is based upon the thought that the workforce is to be considered well-trained and motivated and established teams are ready and willing to attack new projects. (If you are struggling with an unmotivated, unskilled workforce that is rejecting new projects you are having a completely different problem on your hands).

Instead of funding a project and stuffing people into it – fund a team!

The team knows it’s coherence will be respected and can spend the time and effort to get to and remain at the „Performing“ stage, creating strong bonds between each team member.

 Once you have a new project you now take a look at your available teams and assign the project to the most suitable team. That way your worry is less of getting people into funded projects but more a decision of which project to tackle first.

 Agile and Scrum support this notion with short-term commitments taken up by self-organized teams. This way you can quickly attempt a new project without having to factor in all of the team dynamics. If you are satisfied with the project – let it run. If not stop it and give the team another one of your ideas to chew on! Also with the underlying T-Shaped capability model you have (or can create) a workforce that is able to handle a variety of project types from day one instead of having to painstakingly assemble a collection of specialists by scouring other projects or waiting for resources to become available.

There are some drawbacks to this approach with the main one being that you can no longer easily tie expenses together with (future) income as the expenses are defined by the team while the income is a result of a project attempted.

Also the Product Owners / Program Managers are forced to be able to whip out a new project idea latest if an existing project does not seem to pan out. However I’d be wondering if that isn’t exactly the job these people are already doing.

The Bottom Line

Basing teams coherence on the existence and shape of their underlying projects can be hazardous for the business if projects are created/changed/retired in quick succession.

The adoption of Agile will (hopefully!) drastically increase the frequency at which projects are aligned with the market needs. This in turn increases the frequency at which projects and teams change.

This constant change prevents teams from performing optimally and can cause severe negative effects such as workplace aggressiveness, isolation and ultimately employee dissatisfaction.

To reap the rewards of Agile project management while creating a pleasant work environment the team coherence has to be decoupled from project assignments.

This is achieved by funding teams instead of projects.

The end result is a productive, satisfied workforce able to tackle new projects quickly.

This in turn gives you the freedom to start new, promising projects easily while making it less painful to retire failing ones.