Part of being a healthy engineering team is being a self-organized team! It’s a team with clear roles and responsibilities and is committed to project delivery with a well-thought-out plan.
Last year we created a new team called Micros Scale that focuses on creating Atlassian’s internal Platform as a Service (PaaS), our developer experience platform. Since our work has a fixed scope and clear timelines, we became more committed to completing incremental work, more focused, goal-oriented, and proactive.
However, previously our team received a lot of ad-hoc, operation work that prevented us from planning sprints properly. A minimum of 55 percent of the team capacity was allocated to the keep the light on (KTLO) rotations. This made kanban the most suitable methodology for us at that time.
It’s worth noting that according to the Tuckman model, the Micros Scale team was in the Forming stage, and there were a few areas of improvement including capacity planning, sprint planning, goal setting, team reflection, grooming and story elaboration, estimation, project breakdown, and so on.
Which agile methodology was right for us?
Micros Scale has two major projects that are highly complex and have a publically-announced deadline to our customers. That means shipping faster is crucial. We needed confidence in our delivery approach and wanted to work on our planning like an agile pro. We wanted our team to be self-organized, achieve common goals, and be empirical.
We revaluated our agile approach by asking the following questions:
- Is it possible to set a goal for each iteration to deliver an objective with a unique theme?
- Can we commit to the scope of deliverables for one or two weeks?
- Can we elaborate and lock in the requirements we need to work on?
- Is the frequency of ad-hoc requests to change task priority low, and are we less likely to have dramatic changes?
- Is our team new and not that mature in agile processes?
Since the answers to these questions were yes, we realized that scrum was the best agile methodology for our team. Here are additional details that we used to inform our decision:
| | | | |
|---|---|---|---|
| Agile methodology | What is it about? | Is it helping us? | Why? |
| Scrum | Scrum is about a clear roadmap and prioritized chunks of work, while kanban is about visualizing your work, which is raised against the team on an ad-hoc basis. | Yes | We have a clear predefined backlog that needs refinement and prioritization. Our work is predictable, unlike our previous team, which was full of surprises and high-priority requests. |
| Stories shouldn’t be changed in the middle of sprint. | Yes | We can take a more flexible approach; in this case, scrumban (a hybrid of scrum and kanban). | |
| Scrum is easier to adopt for agile teams who are still learning feature-leading. Scrum is more prescriptive, with rituals and timeboxes that provide guardrails. | Yes | We have a new team with new members, still in the Forming-Storming phase, so having scrum helps us become more mature. Read the Tuckman Model. | |
| Kanban | Limiting work in progress and focus on reducing the project cycle time. The use case is when your team doesn’t have a time limit for work and a committed timeline. The request comes to the team and is tackled as quickly as possible (like SLA that service desk teams have). | No | Other teams are dependent on us so we need estimated timelines to help others plan accordingly. Some of our commitments are publicly announced to Atlassian customers, so we need to be mindful and plan for them. We don’t have many short-time requests like a service desk. |
| Great for teams that have lots of incoming operational requests that vary in priority and size. | Yes | We don’t have a heavy KTLO load and the workstream is managed by one person’s role in the team on rotation. We can run that disturbed role as kanban if we want. |
We embraced scrum
I am fully aware that acting like a conductor is one of the main characteristics of engineering managers, as well as being a connector, compass, and coach. So I needed to build my conductor’s muscles all the same. Here’s how I achieved this goal:
Learn more agile practices
Atlassian’s internal learning resources helped me increase my skills in agile practices. I went through extensive agile methodology courses and consulted with an agile coach. I interviewed a few engineering managers to learn about their experience from other organizations and teams.
Use DACI
The DACI decision-making framework – which stands for “driver, approver, contributor, informed” – was used to make effective and efficient group decisions. I walked my team through the DACI change proposal to ensure I had their comments, agreement, and support.
Use a sprint template
I came up with a process for managing our sprints and built a template for each sprint to help with more reasonable planning. The sprint planning template included:
- How to review the previous sprint to ensure we are clear on what we achieved and celebrate it.
- How to retrospectively reflect on the previous sprint and apply our learning to the next one.
- What is sprint cadence, name, goals and objectives?
- How many stories do we commit to delivering? What is the sprint scope?
- How to do capacity planning based on people’s availability.
- What mid-sprint activities do we need to be fully prepared for the next sprint?
- How to write stories, elaborate the requirements, and a solution to tackle it.
- How to track the state of stories we committed to and what to do with unfinished stories.
We also have a great tutorial on how to do sprints in Jira Software.
Shifting to scrum was worthwhile
We made the following improvements by shifting to scrum:
Velocity Improvement
In agile methodology, one of the factors to measure the productivity of a team is velocity, which is the average amount of work a scrum team completes during a sprint. We use a velocity chart to understand what our team committed to and what was delivered. In the velocity chart below, the grey column reveals the number of story points the team committed to based on their capacity. We compare it to the blue column, which is how many story points they actually delivered. The team can then use this to adjust predictions for future sprints.
Identified risk early
Being able to identify risks early and come up with a proposed solution is the key to the success of projects.
Through defining the goals and sprint themes, we picked cohesive stories to achieve goals. In the mid-sprint sessions, our team groomed, refined, and elaborated stories. During elaboration, we asked:
- What needs to be done?
- Why are we doing this work?
- What business value would it add?
This helped our engineers identify dependencies and prioritize tickets with higher impacts to remove roadblocks. It also led us to change how we worked and have a better team focus per project.
Celebrate it! We shipped
Capacity planning and goal setting brought us meaningful motivation and the challenge of being transparent about our commitments. We successfully shipped one critical phase of Atlassian PaaS Account Sharding. We are also about to deliver phase one of our Data Residency project to cover more AWS regions for reliability, resiliency, and compliance purpose.
Transitioned from Forming to Norming
As I mentioned above, the Micros Scale team is relatively new and tends to be in the Forming stage according to the Tuckman model.
Defining a unified goal for the team inspired everyone to align and support each other to achieve team goals and increase team motivation. We failed, reflected, learned, and got better. After three and a half months, we hired 50 percent more for Micros Scale, and I still proudly evaluate the team as a Norming team.
Communication improved
Having a plan and being dedicated during each sprint increased the visibility of what we planned to do for the whole team and allowed us to speak the same language. It is much easier for engineering managers and stakeholders to track project impediments and progress.
How to choose your agile methodology
- Don’t hesitate to review your processes when you see a problem. Think in an agile way: people, processes, and tools.
- Evaluate your team project and responsibilities to find the best agile methods suits your team. Check out our kanban vs. scrum page to learn more about these methods.
- If you decide to shift to scrum, I suggest using a Jira scrum board or creating a template on Confluence or your favorite tool.
For each sprint, create a sprint planning page to review and reflect on the last sprint and plan for the next sprint based on the team's capacity and sprint goal. Here’s my personal Confluence template:
Here’s my capacity planning template that is included in my overall scrum template:
Also here is my sprint objectives and scope template:
For mid-sprint, it’s helpful to have another page to track how the team performed during the past week, what stories we need roll over into the next sprint by considering the current progress of the sprint (called grooming), and elaborate on the stories you groomed (story refinement). Here’s my mid-sprint backlog grooming and refinement template:
Every team is different, and what worked for us may not work for other teams. Scrum, kanban, or a combination of both, like scrumban and kanplan, might be a better methodology. It’s essential to evaluate your team’s particular needs and understand what methodology works for them.
