Cross-pollination of skills happens as our team starts to hone its techniques for collaboration. Communication between team members will begin to get so tight that it will be difficult to see where the handovers between different roles are taking place.
Where before we saw clear boundaries between user experience, software engineer, test engineer, agile coach, and Product Owner, we will start to see the edges begin to blur. As collaboration improves, handovers will become redundant as the knowledge transfer between team members becomes seamless.
Unless we've worked on Agile teams before, few of us will have experienced this; a phased process such as Waterfall often keeps the roles separate. So, how does this start? For most teams, it begins as we learn more about each other's roles as we start to work together. In the team Liftoff, we explicitly discuss our roles and what each of us brings to help the team complete our mission. In Sprint Planning during estimation and task breakdown, we consider how we will each contribute to doing the work. And in the Daily Scrum, we discuss how we will coordinate with each other to get the job done.
For instance, consider the scenario shown on the Kanban board below, where work progresses so far before it gets stuck in a particular column: in the Code Review column or the Test column. These logjams where work accumulates often happen at a handover point between team members:
Work is accumulating because the team member is waiting for a tester to do some specialist testing work. Logjams in our workflow can happen temporarily because team members with specialist skills are away, or because they are just too busy, or because we don't quite have the right balance in our workflow.
When this happens, when we see a problem with our workflow, we need to debug it just like we would if it were code; our aim should be to get these valuable software features into the hands of our customer as soon as possible.
Probably the first thing to do is for the team to swarm on the logjam of work and release as much of that value as possible. Swarming is awkward at first because team members who don't usually do a code review or testing will need to learn how to do it and team members with those skills will need to coach the others.
The next thing to do, once we've unblocked the logjam, is to consider how we can prevent it from happening again; any accumulation of unfinished work in one part of our system is a potential symptom of a broader problem. For example, if work is accumulating in the Test column, what is the reason? The reasons are listed as follows:
- Is it because there are more programmers than testers and the testers can't keep up?
- Is it because testing is usually approximately 70% of the work in developing software, regardless of whether you automate your tests?
- Is it because the programmers are producing code of too low quality and much rework is required?
- Perhaps the programmers aren't automating the tests, expecting the testers to do so. This approach tends to generate a significant amount of rework, as the testers will often test the specifications, not what the programmers have written.
Whatever the problem is, if the programmers and the testers don't work together to solve the problem, it will continue.
Managing Work In Progress (WIP) limits, and actively breaking down work items into bitesize chunks of discrete value, is the most straightforward approach to increasing workflow.
However, even with this approach to increasing workflow, our team will soon notice, if they still have an element of phased delivery, that the handovers, although smaller, will still cause issues.
Handovers bleed information in the transfer process, anywhere up to 50% of the knowledge will be lost. If our team works together to solve the problems in the transfer of knowledge, we will gradually get to know more about what each other's role entails. We'll even take on some of the responsibility for different functions, and the cross-pollination of skills will begin.
Test automation is essential to any Agile team's productivity. Code review is another gate where we could benefit from automation as well. Employing tools such as SonarQube will go a long way to help our team build the code right the first time. If we are to implement either of these, our group first needs to set their standard around testing and code reviewing standards. To do this, they'll need to work with the specialists in our team who understand how to do that.
Once we've implemented automation strategies around testing and code review, it isn't to say that we should do away with an explicit testing or code review stage. There are still many benefits from an eyes and hands-on approach.
However, the more we can automate, the more quickly we'll get feedback on these hygiene factors. We don't make our jobs redundant by automating; it makes our jobs more stimulating because it allows us to move up our practice to the next level, whether it is testing, writing code, code review, or something else.
Boundaries will also start to blur as we begin to automate our process; test automation (TDD and BDD) blurs the lines between software design, programming, and testing. Continuous Integration/Deployment will blur the lines between software development and operations. In both of these scenarios, if we're lucky enough to have specialists in these fields (test automation and DevOps), they will likely act as coaches as they both help the team create our frameworks and pipelines as well as transferring their knowledge in automation practices.
Cross-pollination of skills is essential if our team is to reduce the time it takes to deliver and skill cross-pollination will give our team the confidence to act knowing that they're covering each other's backs.