As Agile software development continues to take hold across all industries, along with DevOps practices and tooling, refining the delivery of products and services is increasingly the focus for many firms. Ensuring business goals and customer requirements are being met is key to software delivery. This requires detailed planning and organization of all teams working to meet these goals. As collaboration and cross-functional teams become the new norm, orchestration and planning must also be collaborative. 

The Scaled Agile Framework (SAFe) establishes a cadence of planning and increments, which must be orchestrated and managed at different levels. Managing this planning at the level that directly concerns development teams is part of our role as Scrum masters.

RELATED CONTENT: 
How to get started with SAFe
Scaling from the bottom up

Scrum masters act as bridges between developer teams, business objectives and what can be realistically expected and achieved. We must ensure that we have oversight of the obstacles developers are likely to face, gauge the level of understanding of business goals and manage the elements that may detract from their ability to reach them. Effective communication is key, but so too is an ability to manage the day-to-day tasks of software development.

To understand our role, and the challenges we face, here are four key areas of focus for Scrum masters: 

1. Stick to ceremonies

For us, the four Scrum ceremonies (sprint planning, daily meeting, sprint review, and sprint retrospective) are essential, and we must ensure these take place and are attended by all those responsible for meeting objectives. This means working with individual developers to help them take ownership of tasks, i.e. stories defined by the Agile methodology, and providing them with the support they need.

Making sure JIRA boards are up to date and preparing the next iterations requires us to work closely with product owners, encouraging them to address backlogs of tasks, revisiting priorities and challenging them when it comes to reassessing the product roadmap. Story pointing is an essential part of establishing the areas that require the most attention. We need to make sure that sprint goals are being achieved and that the stories being progressed are not just those that are more interesting or fun, but rather those that move us toward delivering a feature.  

2. The importance of communication 

Establishing the weight of a story is a key part of daily planning as it gets teams talking to one another and allows a more dynamic and transparent assessment of priorities. This helps developers, Scrum masters and product managers to arrive at a mutual understanding for a project, centred around the delivery of a feature.   

The Agile structure prioritizes collaboration over hierarchy. Effective communication is therefore a key skill for Scrum masters. We must fully comprehend business objectives and customer requirements and ensure developer teams are mindful of these as we progress. But there are of course challenges to be overcome.

Working in Agile means being able to adapt to change when necessary. Developers are driven by their stories, but should not be single-minded in this approach, as the endpoint is achieving our sprint objective and delivering what customers want. The main caveat to this core principle, however, is that we must not make perfect the enemy of the great, nor even great the enemy of the good. This is why transparent communication internally is essential. 

3. Pushing back to push on

If a change is requested during a sprint, we must assess the capacity of teams, as well as how essential the change is. In an ideal world, there would be no new requirements introduced during an iteration, but this is rarely ever the case. Last-minute change is more of an expectation than an inconvenience, so we have to build in the unforeseen to our planning. 

Scrum masters do not like to incorporate last-minute change on the fly, preferring instead to push new changes into the next increment. This is where we must work with product managers to decide on the “must haves” for a certain feature, which again requires an acute understanding of customer requirements, as a workable solution can often fulfil these before the ideal is possible. 

As we begin implementing features, we also learn new constraints and dependencies that slow us down, which may necessitate refocusing priorities. We may, for example, need architect validation to merge code and for pull requests that allow us to deploy it. But architects typically do not have the same time constraints that a Scrum team has, as they focus on the entire increment, rather than the sprint timelines developers work to.

Working through these challenges is a vital part of our retrospective meetings. In SAFe, we are able to do this at a team level on each iteration with Scrum retrospectives, as well as at the end of Program Increments with Inspect and Adapt (I&A) workshops. These help us to identify where issues may have caused bottlenecks and to establish better processes going forward. 

4. Understanding the developer mindset

Working in Agile means developers are responsible for how their code performs in the production environment. Reviewing code is not the sole responsibility of QAs, as a story is only “done” when the code is deployable. 

Speaking from first-hand experience, writing and verifying code is what developers want to do, as they are goal oriented and enjoy achieving milestones and progressing along product roadmaps. But as the definition of “done” relates to code that is ready for end users, there are no hand-offs to other teams, QA or otherwise. This means that developers must always work with the assumption that their code will be deployed. 

This is where a DevOps mindset is crucial, as teams share responsibility for the end-user’s experience and fully understand their own integral part in the value chain when it comes to delivery. This is empowering for developers and is also advantageous for Agile workflows. 

 As Scrum masters, reducing work in progress is a key part of our role, which is why a DevOps mindset, emphasizing collaboration and total ownership of work, informs how we interact with and organize teams and tasks. 

Another important point of attention we have, is to reduce as much as possible the number of objectives for a given sprint. Ideally, having a single objective, on which all team members can contribute, increases the delivery of value (only achieved when stories are done) and contributes to establish/(re)enforce the team spirit.