This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams.
Applying the principles of Scrum in a larger organization with multiple teams can be challenging. First, it’s simply bigger, and having more people involved makes things more complex. Second, while there is literature on the subject (like Larmann and Vodde [2016]), you can hardly call it a mature system. Third, software support is lacking. So, how do we approach it, using Jira as our preferred tool?
The central element of Scrum is the customer’s need—the customer being someone who wants to buy a product from you. The first step is to actually identify what parts of your project are shippable products. If you identify that you have several distinct products, you don’t need large-scale Scrum, you can have the teams work independently on the products. Given the easier management, you might even think of splitting existing larger products into smaller ones, but that is a decision requiring knowledge of the architectural details of your project.
Another important element of Scrum is learning. If you have set up multiple teams, they still operate within the same framework, namely the same organization, the same building, or maybe even the same room. Each Scrum Master is running an improvement project that gathers requests by the team and removes impediments (ideally proactively), but at least in my experience, they are hardly ever sharing, except maybe informally through meetings. Much better is to set up one global Scrum Master Jira board that lists the impediments of all teams and have the Scrum Masters work on these tasks as a team. Depending on the volume, you may even require an assistant to help keep that board clean and up to date. This will help the Scrum Masters to encourage each other and reduce duplicated work. Just do not make the mistake of actually physically removing the Scrum Masters from the teams and putting them in their own room: they need to be there for their respective teams, ready to solve any issues. But while they are waiting for problems to arise, they could help out the other Scrum Masters clean up the global backlog, or they could work on impediments found by other teams.
Now, one big issue is specialists, or very experienced people in general. They are a rare resource. Previously, we found that it might be a good idea to keep them on a team instead of moving them into a management position. With multiple teams, the pressure from the business side to share specialists among the teams is heavy, as it is expected that other teams will need to access a particular resource as well. What to do?
Support team
Of course it depends on the business environment, but if possible, form a “support team” ready to answer questions from any of your teams—including questions about architecture, legal issues, or technology. This support team works much like traditional customer support. It builds up a knowledge base and answers questions, ideally as quickly as possible (using management techniques other than Scrum). This will be the central “brain” of the company for really hard questions. Depending on the product and the way your company works, you could even merge the support team with your traditional customer support, as they are building up the same kind of knowledge base, although with the emphasis on the customer. Last but not least, provide them with the authority to quickly hire external freelancers in order to have access to specialist knowledge.
Communication
With multiple teams and (if applicable) the support team, you might want to reorganize your communication as well. Which tools you use for that depends on your organization and needs. The question is who is accessing the support or Scrum team. Ideally, for the initial request, you will want no direct communication between individual team members and the rest of the organization. Instead, gather the requests at a central place and have a manager or the product owner sort through the issues. I jokingly call this “removing the red telephones” from the desks of the developers.
The most flexible solution is to use a separate email address for questions and problems. This address then can be used by everyone in the company, even those usually not familiar with Jira. This ensures requests will be channeled and minimizes initial training. Then, have either your product owners or Scrum Masters manage those email accounts manually, or use Jira’s automatic task creation system. You could promote this email address within the company by arguing that this way, nobody has to figure out who to contact on the team and that there is always somebody who answers questions expediently.
While there is a relatively new functionality in Jira to handle support tickets (service desk), I suggest giving the existing functionality a try. For the internal Scrum and support team communication, you already have many registered in Jira, so little to no extra configuration is required:
- Set up a POP3 email address (e.g., Gmail)
- In Jira, go to Settings / System / Incoming Mail
- Add POP / IMAP mail server
- For Gmail: Protocol: SECURE_POP, Host name: pop.gmail.com, POP / IMAP port: 995
- Add incoming mail handler
- Handler: Create a new issue or add a comment
- Strip Quotes, Catch Email Address, Bulk: Ignore the email and do nothing, Create Users, CC Watchers
With this configuration, people can use your email address, are automatically added to your Jira user base (to receive comments and make comment themselves via email), and a task is created in the specified project. If you have set up a default assignee in your project (e.g., the product owner), that person gets notified and can then decide whether or not to move the issue to the backlog or to escalate it as a critical bug.
Project Organization
Besides communication, you might want to think about project organization. I strongly suggest keeping the organization logical and assigning a Jira project to an actual shippable product. With shippable, I mean really shippable. For example, if you have a mobile app and a connected server system, you cannot ship the mobile app on its own. Likewise, installing only the server system without an app might yield zero business value even though it is physically shippable. Think outside the box, split the “server team” and “app team” into two teams consisting of both “server people” and “app people,” holding on to the idea of creating multidisciplinary teams. Then, split the project into two features. This could be communication and design, with both teams regularly exchanging code bases or, ideally, working on the same code base. Much more could be discussed in this regard; my point is to really focus on keeping your teams Agile and not fall back into the old Waterfall thinking of compartmentalized teams working in product phases.
