Overview
The seemingly cliché saying about “doing more with less” is a fact of life in most businesses today. People have more to do and less time and budget with which to do it. In software companies, one way this manifests itself is in frequent and constant resource movement among multiple projects. When my team began using an agile development process, we searched far and wide for information about how to work using that process when working on multiple agile teams. What we found was that most of the writers out there working with agile development were dedicated to one product team. As floating writers, we have unique challenges in agile development.
At NetIQ, the members of our Information Development team, with the exception of a few lead writers assigned to specific product teams, work on at least two projects simultaneously. While maintaining the flexibility of our team members can be beneficial, it can also be challenging to plan for and execute work on multiple teams.
Capacity Planning
A simple definition of capacity planning from Wikipedia states that it is “process of determining the production capacity needed by an organization to meet changing demands for its products.” From the agile perspective, capacity planning involves determining the length of the sprint and your workload capacity for that sprint for that project. It’s especially critical when your team members work on multiple teams. Without capacity planning, your team members can easily lose track of what time is committed to each team. And, you run the risk of also over-promising to one team or the other if you don’t do a thorough plan with actual numbers. For an easy primer on capacity planning, see Capacity and Over-Committing Your Resources.
To determine your capacity, consider the following:
- Review previous sprint estimates, if available.
- Include vacation and non-sprint responsibilities, such as meetings, customer support, and so on. My team members generally estimate 2 hours of an 8-hour day to cover this, leaving 6 hours a day for sprint work.
- Do not include the first or last day of the sprint. These days usually involve planning or retrospective meetings.
- Ensure Development finishes early so Quality Engineering and Information Development have time to complete their user story tasks before the iteration ends.
An individual capacity plan for working on multiple agile teams and projects is essential.
Junior team members still learning how to organize their time find capacity planning especially useful. Something about getting the numbers down on paper where you can actually see it helps you realize you can’t stretch as far as you think you can. A number of templates, such as the spreadsheet above, are available to help you plan for each project you are on and calculate the hours available for each sprint for each project.
Start with getting individual capacity planning right—it’s a factor in team capacity planning. Using the whole team approach requires some knowledge of what the entire team can accomplish in a sprint. So you’ll need to glean information joining individuals’ capacity plans.
Handling Meetings on Multiple Teams
When you serve on multiple teams, you could spend 4-5 hours per week (or more) in scrum meetings for each assigned project. Work with your lead or manager to spread out the workload in such a way that you can delegate scrum meeting attendance to others. Some suggestions include:
- Attend only the scrum meetings that pertain to your highest priority project at the moment.
- Ask the scrum master to send scrum status reports through email to help those who are unable to attend each scrum meeting for each project.
- Ask your lead or manager to attend some crucial meetings when you can’t.
- Quit attending irrelevant meetings. Even if you’ve historically attended a certain kind of meeting, if you’re not getting enough out of it to increase your product knowledge or contribute to the content you’re working on, perhaps your time is better spent elsewhere.
- More and more distributed teams work in agile environments. Many scrum teams use online collaboration tools to hold their scrum meetings and create permanent records of the discussions. Consider online collaboration tools for one or more of your scrum teams, which allow you, if you miss a meeting, to check the record later.
While ideally you would attend each scrum meeting for each of your projects, sometimes it just isn’t possible. Finding ways to gain clout and a presence on your team is that much more important so people don’t forget you when you’re not there.
ID-Only Scrum Teams
Remember, the intent of agile is to ensure all functional areas work together as one team, doing their functional tasks in alignment in each sprint. If you’ve ever talked with me about agile, you know I’m a huge advocate for keeping Information Development tasks in the sprint with development and testing tasks.
However, sometimes circumstances or your particular organization’s setup might require a different approach. In situations like these, perhaps an ID-only scrum team would work. In essence, an ID-only scrum team has its own backlog, sprints, and tasks, and runs independently of the development teams’ sprints. This kind of environment tends to decrease writers’ product knowledge, but writers can more easily move from team to team to fill in for smaller bits and pieces of time as needed. John Collins elucidates the pros and cons of this approach in his recent excellent post on his IntersectUX blog.
Conclusion
While having information developers working on multiple scrum teams is not ideal, it can be done with some proper planning and judicious evaluation of which meetings you should attend. The more ways a writer is stretched, the more thought and analysis is required to determine what to work on when to provide the most value. And the ID-only scrum team is a viable option in certain circumstances if your team just can’t stretch far enough. That flexibility is one of the many beauties of agile.
