It’s a situation that happens to new Scrum teams all the time…

Green agile practitioners look at a complex web of backlog items and decide most features can be completed with this simple two step process:

1. Assign each task to a team member with the appropriate skill set.
2. Prepare to start checking off user stories!

So far so good, right? But wait- they forgot a few steps…

3. Predetermine how each person will finish each task.
4. Ensure the tasks are accomplished in the proper order with a schedule.
5. Provide team members with a way to manage all this information once it’s been decided.

Though this to-do list only outlines a five-step process, it’s granular nature can drive managers to obsess over Gantt charts and begin referring to teammates as “resources”. Cue the migraine meds! But this reaction is no surprise- there are far more factors involved in development than any one person can manage effectively.

The Fix

From here there are two solutions: 1. Get management as close to the work and its complexities as possible, so they never miss a beat in this ever-changing environment; or 2. Remove the project manager altogether and allow the team to decide how work should be done.

For teams that choose the latter, this will also require one other change: They will have to stop classifying developers by specific competencies. Development is much easier when every aspect of a complex feature can be coded by one person, and more developers can be utilized for testing or pair programming when this is the case. 

Let’s be realistic though. Many teams are not composed of Jacks-of-all-trades who excel at every necessary development skill. That’s why it’s worthwhile to consider the middle ground: a self-organized, cross functional team. Here’s the breakdown.

Key Terms

“Cross-functional” means the team is composed of every role needed to implement each backlog item from beginning to end. A group following this model will most likely include UI designers, backend developers, testers and database administrators if needed.

“Self-organized” means the team decides as a group how to implement backlog items. For these teams to succeed, they must have the ability to work out important issues independently, so bottlenecks are eliminated. For example, if a user story was started by Kirk the UI developer and he needs something completed by Spock the DBA, then he can just ask Spock to work on that story whenever he gets a chance. No complex scheduling needed, just individuals interacting to get things done.

To help team members within the same discipline become more cross-functional and self-organizing, try introducing pair programming (or something like it). Once this practice is in place, the team will be exposed to more code outside their own specialty and complex projects will be easier to take on!

Potential Problems

Although this system is an improvement over rigid hierarchical structures, it doesn’t mean everything will be smooth sailing straight away. Removing management can create its own issues, and at first teams may begin to experience different productivity impediments. In particular, a lack of trust between teammates can be one of the biggest blockers.

At work, people tend to reserve trust for the team members who have “proven” they can do certain tasks. To negate this natural urge, teammates need to give each other the opportunity to earn trust by working through unfamiliar issues and by putting a system in place to provide constructive feedback. 

Other issues may arise from new features and bugs that need multiple people to complete them. It’s likely some tasks will require one person to code, one person to test, another person to modify the database, someone to design UI graphics and a writer to create a help file. With that many players it becomes essential for collaboration to remain at the forefront. Here are some ways to encourage teamwork:

• Ensure the bulk of a team’s collaborative talk is done during the daily standup as developers chat about their to-do lists and impediments. Scrum Masters should allow enough talk for team members to decide who they’ll team up with to complete key tasks, but not so much that drags out the standup past 15 minutes. The phrase, “You two should be able to work out details after the Scrum, let’s keep moving,” will become commonplace.
• Consider an office redesign that increases the team’s ability to self-organize. Many organizations remove cubicles and allow the team to work in a single room to achieve this goal. That way, if a developer needs to work with someone else on a particular user story, they can do so without leaving their desk. Workspaces should also reflect an ideal team size (about seven members) to maximize productivity.
• Promote face-to-face communication and discourage emailing back and forth, so teams spend more time actually interacting. This will diminish delays and get the creative juices flowing during team discussion!

Takeaways

• Consider modifying or eliminating managerial roles, so the individuals who implement backlog items have the independence to make decisions.
• Create cross-functional, self-organizing teams with members who have the flexibility to work on a variety of tasks.
• Keep collaboration at the forefront with a daily standup, open workspaces and face-to-face collaboration.