Have you ever been on a project and heard someone say, “I’ve finished what was assigned to me and there is nothing else assigned in the sprint, so I’ll need something else assigned to me….”
Unfortunately, it’s heard on projects more often than one would like. Many people stay strictly inside the lines of don’t look outward. It’s comfortable and easy to just use familiar colors and only paint the drawings you have done before.
In many cases, team members are brought in specifically to a team for a specific purpose or skill set – their ability to color a certain way. While this may be important for the project to move ahead, it is equally important that a member of an Agile project be comfortable with learning about and sharing new ideas and skills to improve the overall strength of the team.
Luckily there are Agile, and in particular, Scrum approaches, that can help team members better position themselves to avoid this situation of working in a silo. One of the things I love about Scrum is the concept of the entire Scrum team being responsible for the Sprint goal and working together to see it through. Ken Schwaber and Jeff Sutherland tell us in the Scrum Guide that “Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.” Everyone is in the boat working together to move it toward the destination.
On many teams there is a habit of making someone “an owner’ of an area or a process. They end up being the go-to person to handle all work in that area and over time may be identified as the “expert” in that part of the product. This is often seen in the case of consultants who are brought into a project or product team to fill a specific gap – they have particular expertise in something and are being brought in to shore up a certain area.
It is important in Scrum to have people with areas of expertise, but to maintain an agile mindset – it brings great value to a team when people lead from their strengths, but have the willingness to learn and try new things, even if they may not be an expert initially. It is good to richly color within the lines of your drawing, but it can also be helpful to be able to color the area around it as well.
But won’t this slow the team down? Won’t this distract team members from their work if they have to cross train other people on the team?
While the team may initially have to slow down to bring other team members up to speed in areas of unfamiliarity, the idea is that the whole team will speed up later. The overall team becomes stronger and the risks of having a single point of failure are mitigated or removed. A team can still have people who specialize or have focused skills in specific areas, but the sharing of the knowledge on a team where anyone can step in to help with the work.
Lets examine a scenario where the Scrum team doesn’t work together or step into areas where they aren’t “the expert.”
The team may continue working at their current pace while work is available for all areas. Should there be no identified work for a specific area of focus, the team member may find themselves idle or with little ability to participate.
Team members eventually may have to resort to cherry picking work in the Product Backlog that aligns with their skills set.
If a team member is sick or on vacation and they are the only expert in their area, work may be blocked until they return. In extreme situations a team member may not be able to take personal time off for sickness or vacation because they are the only ones who know how something works.
If a team member moves to another team or leaves the company, rapid knowledge transfer must take place. This is usually done very quickly and much is missed, or isn’t remembered when the knowledge is actually needed. Inevitably some knowledge is lost or walks out the door.
Now let’s look at the same team where they commit to cross training and learning about areas the areas with which they may not be familiar.
The team may experience a dip in the near term as far as the pace at which they work
The team gains knowledge in multiple areas, so that the team can work the product backlog items in order of importance to the project.
If a team member gets sick, or is unable to work for some reason the team has multiple people who can take up the work and cover for other team members.
If a team member leaves the team, multiple other team members can share the workload, and the collective knowledge of the project remains shared across the team.
While an environment that embraces sharing and mentoring each other is encouraged, the team probably shouldn’t drop everything and have everyone cross-train each other at the same time. Focus needs to be maintained on moving the product ahead and the work in the product backlog. Cross-education amongst the team is best done in small bits – If one team member is lighter on work within a sprint, let them pair up with someone who can help them learn. If too many people are doing this at the same time, the team will lose their momentum and the product may suffer.
There is a sweet spot for working together that the team will need to find – only so many people can hammer in a nail at the same time. That’s part of letting a team self-organize and find the best way to work. It delivers more value for the product or project to have a team working on fewer users stories at the same time that are carried all the way to completion, rather than having everyone working on separate items and nothing being done. Fewer user stories completely done are better than a lot of user stories only half done.
Slowing down occasionally to share experience with others and help people learn about new things is important. The entire team eventually will speed up and be much stronger for their efforts.
Happy coloring!