Scrum is a simple framework that ties together several practices and values that, when done right, can help your organization ship higher quality products faster.
For as long as I’ve been doing Scrum (about five years now), folks have been asking me to write a definitive guide to doing Scrum. While this post doesn’t cover everything you might need for a successful implementation, it should answer the most common questions and give context for how and why we do things at Atlassian. This is mostly based on my experiences at Atlassian, but many of these ideas are also influenced by conversations with teams and leaders across different organizations – from startups like GitHub and Pinterest to large companies like Target, Microsoft, Google and Adobe.
You’ll notice that there isn’t a single mention of the word “agile” in this article. That’s intentional, because no one ever asked me what I thought about Agile methodology and Scrum framework (and I didn’t want to sound like an idiot). After thinking about it for several years and reading/watching/practicing Scrum, here is my best guess for how to do Scrum well.
##Scaling beyond a team: As your engineering organization grows larger than a handful of teams, you’ll need either management or architectural tools to help with scaling > Keep track of what work has been done – Ask your engineering manager(s) if they can provide visibility on which teams are working on which projects. This way, everyone else in the company can focus on what they’re good at without having to worry about tracking the work of every team. > Build an archive of how projects turned out – To know if you need to do something different next time, keep track of what worked and didn’t work for each project. Have several engineers or managers meet once a month over lunch (or whatever) and go over the archive together. If you did things differently this time than last time, why? What was successful? What went wrong? Why did it go wrong? Did we act appropriately when things went wrong? How could we have improved given hindsight?
##Scaling within a team: At some point in your engineering organization’s growth, you’ll start running into these issues >But ultimately scaling is about people and relationships, not about throwing more hardware at the problem.
##Scaling by adding a second team: If your organization reaches a point where one team isn’t big enough to handle all the work that needs doing, you’ll have several choices as to how to address it. One option is to split into two teams that operate independently from each other, but within a common engineering org. Each team can have their own “culture” and norms based on their specific needs. This helps ensure they don’t step on each others’ toes, but can still come together for company-wide events and so forth.
>The major drawback of this approach is that cross-team projects or special efforts can be difficult to coordinate and deliver. There may be only one or two people that can effectively serve as liaisons between the teams, which means you might not get full coverage all the time.
>Another challenge with this approach is that it’s often difficult to define “team membership” in a way that makes sense. For example, is someone who works on team A part of team B if they’re working on a joint project? If so, how do we track their participation and ensure they keep up-to-date with both team cultures and norms? And if they aren’t officially part of team B, does that mean we’ll have to hand off work items to them when we want them included in some aspect our process (e.g. attending a review)?
Meetings are evil. And not the meetings themselves which might cause some overhead, but rather the sheer number of meetings you need to have at an early stage when establishing cross-functional teams cross-site or cross-country. We all know that there are only 24 hours in a day and that common efforts are becoming more complex with each release having more features than its predecessor. Allocate resources to internal community building, appoint ambassadors if necessary, don’t waste time on discussions which should happen face-to-face or by phone instead.
Thus Scrum works as a magic wand as it allows teams to self-organize. In practice you don’t need to attend meetings if your backlog is constantly groomed and neither do you have to ask for permission from someone responsible in the hierarchy of managers. It enables a company to reduce management overhead by reducing the number of daily meetings or any other form of communication that does not add value, but only consumes resources.
In my opinion Scrum being an agile process framework is especially useful for organizations which have introduced JIRA across all teams. Once project managers have been restrained how to use Agile boards, they require minimal input from team members which would be more effective on internal community building tasks or providing help where needed.
