PPL 2020 — Document Builder: Different Implementations of Agile & Scrum in The Industry
After my previous article about the Agile method, Scrum, and its implementation in our PPL team, I’d like to explore more and write about the implementation of these methods and processes in the industry. In this article, I will explore the different implementations of Scrum and Agile, which aspect of them is implemented in the company’s process and the takeaways on the results the company achieves and the culture that grows with it.
Before we get into the sample methods and implementations of Agile method and the Scrum framework, let us review some keywords of agile and scrum before we get into the companies that use them in their processes:
Agile Method and Its Manifesto
- Agile Method → Development methodology based on an iterative and incremental approach
- Agile Manifesto → Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan.
Scrum and Its Values
- Scrum → A framework that is one of the implementations of Agile process
- Scrum Values → commitment, courage, focus, openness, respect
In this article, I will talk about the Scrum implementation in two well-known tech companies which is Spotify and Microsoft.
Agile Implementation @ Spotify (Spotify Model)
When Spotify was still a small company, they implemented the Scrum framework and follow the standard Scrum practices like sprint planning, task breakdown, sprint review, and sprint retrospective. However, as the small initial team grows into multiple teams and a handful of employees become thousands, some of those processes eventually become blockers. They then decided to make these activities and standard practices optional.
Rules are a good start, then break them when needed
Engineers in Spotify think that Agile matters more than Scrum and Principles are more important than practices. They rename “Scrum masters” to be “Agile coaches” because they want servant leaders instead of process masters. They also rename the “Scrum team” to “Squads”.
Autonomy in Squads
A squad is a self-organizing, cross-functional team that typically consists of engineers, designers, and product managers that do end-to-end processes in building the product (design, commit, deploy, and maintain). Each squad is responsible for what to build, how to build, and how to work together to build the product. Each squad is also usually united with a long term mission.
Although each squad has its own mission, the missions of all squads have to be aligned to reach a goal or solve a problem. In Spotify’s explanation on their engineering culture, they explain the autonomy vs alignment graph with a very clear and interesting example:
According to them, squads and teams have to have high autonomy and high alignment to be able to work effectively. By having high autonomy, employees will feel trusted in doing things and trust is more important than control. However, to be able to work efficiently in a highly autonomous setting, the organizations also have to have a high alignment. In Spotify Autonomous Squad setting, each leader and squad has this role:
- Leader’s Role → Communicate problems and identify what problems to solve
- Squad’s Role → Collaborate with team members to solve the problems
Autonomy with alignment increases motivation, quality, and faster releases
Frequent Feature Releases
Engineers in Spotify believe that when releasing a feature is difficult, people will prevent from doing so frequently, which will make people have bigger releases, which then will make releasing feature difficult. To prevent from this hell loop, the agile culture in Spotify encourage for smaller releases
One example of this effort by the company is the Spotify’s desktop app used to be a big monolithic app. This has caused a lot of problems when several teams work together on releasing features for it. They ended up investing largely on decoupling the apps so that each squad can have independent releases and work more autonomously.
Implementation of The Agile Manifesto in Spotify Model
- Individuals and interactions over processes and tools → When the standard Scrum practices become blockers, they make it optional and rather push for better collaboration and interaction by reorganizing the teams into cross-functional squads
- Working software over comprehensive documentation → They implement small releases and feature toggles. Rather than wait for a feature/product to reach perfection, they optimize for releasing smaller working features rather than working until the comprehensive documentation is complete
Scrum Implementation @ Microsoft
When Microsoft announced their commitments to convert to Agile processes and adopting Scrum, many were skeptical. Questions like “Is the commitment only addressed to outward forms of Scrum without implementing its values?” since there were not many cases in which big corporations like Microsoft adopt the agile methodology and the Scrum framework.
However, as I myself experienced during my internship with them, the conversion to agile and the Scrum adoption has been pretty successful within a lot of teams in the company.
The Scrum Practices
In Microsoft, the Scrum project management cycle is broken down into the 3 highest priority values:
- Backlog management → collecting the list of user stories and prioritizing them
- Sprint planning → choosing a set of user stories to implement in a sprint based on their estimated cost and team’s capacity
- Daily stand-up → reviewing the newly completed work, work in progress and newly started work along with any impediments
Product Backlog
The tool that is used for backlog management aligns and is the same tool used for code collaboration and version control: Azure DevOps.
A user story is typically defined in the form of “As a <some type of user>, I can <do something> in order to <achieve some result>”. User stories can be grouped together into what is called an “Epic”, which forms a hierarchy of requirements.
The backlog then orders these user stories from most important to least important, and developers should then implement them in that order. Anytime something else comes up, it goes back into the backlog and from time to time each member of the team should review the backlog and make sure that it’s still in the correct order.
Sprint Planning
In sprint planning, the scrum team needs to choose a set of user stories and then break them down into smaller tasks. When doing this, the tasks are then reiterated between estimated costs and capacity. In this sprint planning, the set of broken-down tasks are then also assigned to specific people to work on during the sprint. A sprint typically lasts 3 weeks.
Daily Stand-Up
In the daily stand up, team members gather together for as short a time period as possible (usually 10–15 minutes). Based on my experience while interning at Microsoft, I was not put into a fixed scrum team, therefore in one sprint, I could have daily stand-ups in multiple teams, based on which team the tasks I was working on belong to. In this daily standup, everyone in the short meeting typically talks about the tasks they’ve completed, the ones they’re working on, and what they’ll be working on for the rest of the sprint. I personally think that the daily stand-up is the most important activity in the implementation of Scrum.
Key Takeaways
Based on my exploration and experience in the implementations of Agile and Scrum in the industry, these are the key takeaways that are learned:
- Discuss and define your company/team’s culture priority. Like Spotify, they decided that agile is more important than scrum, and principles are more important than processes. From then on they were able to define a set of new frameworks and processes that work best for the company.
- There are industries that implement standard Scrum practices like there are some companies that modify and define their own. Company culture and priorities play a big role in these decisions.
Feedback or second opinions are very much appreciated. I hope it was useful!
References:
