Month: July 2021

The Role of the Scrum Master in a Development Team

~ Adam ~ Leave a comment

The Scrum Master is the role most often associated with Scrum and a lot is written about the roles, responsibilities, and accountabilities of anyone fulfilling the role.

The Scrum Guide explains

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organisation

The Scrum Guide 2020

In other words its a Scrum Master’s job to coach and support the adoption of Scrum. Generally the commitment of a Scrum Master is to three main parties, these are:

  • The team
  • The Product Owner
  • The business
A Scrum Master has responsibilities to the Team, The Product Owner, and the Business.

Lets start with the Scrum Team itself.

The Scrum Master should coach the team in their adoption of scrum. This includes building and supporting self-managing and cross-functional teams and making sure they hold productive and valuable Scrum Events. They should stress the importance in the Scrum Artefacts and Commitments including creating a transparent Product Backlog and clear Definition of Done.

They should also act as a facilitator, helping the team make good decisions and removing impedements when they arise.

In their role to support the Product Owner the Scrum Master should help find effective methods of creating clear Sprint Goals and managing the Product Backlog. They should also help create a culture of transparency, openness, and empirism which will lead to better product decisions being made. They should encourage stakeholder engagement and offer to facilitate where needed.

A Scrum Master is the appointed people within the business to ensure that the Scrum process is a success. This involves supporting the business with the scrum adoption, advising on the implementation and helping engagement between teams and stakeholders. A good Scrum Master will look for barriers and issues arising between the business and the Scrum Teams and work to ensure that both management and Developers get what they need from the other.

Being a Scrum Master often means you have to be the champion of the process.

Being a Scrum Master is not an easy role. You have to be able to resolve impedements effectively, to engage with a wide variety of people and to champion the Scrum process to both the business and the teams. Be nice to your Scrum Master, they’re always working for you!

The Role of the Product Owner in a Scrum Team

~ Adam ~ Leave a comment

Last week I wrote about the roles and responsibilities of a Developer on the Scrum team. This week is about the Product Owner (often simply referred to as the PO). It’s worth noting that the PO can also be a Developer. However, in my experience the Product Owner is more commonly a non-technical ally for the team, a specialist in the product or the industry.

The PO should not be confused with a Project Manager, that is not their role! A scrum team should be self managing.

The Scrum Guide’s first few words about the PO define their role the most succinctly.

The Product Owner is accountable for maximizing the value

The Scrum Guide 2020

In other words it is the role of the Product Owner to ensure that the Scrum Team are always working on whatever will deliver the most value to the customers and the business. Whether that’s a bug fix, a new feature, or an investigation into upcoming work.

They use Product Goals to avoid this vision becoming too short sighted and reactive, sharing a future state of the product they are working on and working with the Scrum Master and the rest of the team to make that goal a reality.

It is the responsibility of the Product Owner to ensure that the Scrum Team are focused on the most valuable work at any given team.

There are also a few key points around the PO’s role:

  • Should the Sprint Goal become obsolete the PO is the only person with authority to cancel a sprint
  • The PO is a single empowered individual, it is not a committee. Two (or more) POs cannot share a product however the PO can delegate work to other people within the team they remain accountable
  • The business must respect the decisions made by the PO

It is also the Product Owner’s resposibility to understand and articulate the work and make sure that the Acceptance Criteria is well defined and the Product Backlog properly ordered.

It is the Product Owner’s responsibility to communicate the work to the developers so it is clearly understood and can be delivered.

Finally, the Product Owner should always engage with stakeholders to properly understand priorities and requirements. In order to maximise value they must speak with the business and the customers to understand the biggest issues. They must then work with the team to deliver it.

There are a couple of great resources out there for POs if you’re interested. The first is a video by Henrik Knibergwhich gives a great overview of Agile Product Ownership. The second is an article on Scrum.org which discusses the PO’s role in managing and understanding technical debt.

However you cut it the PO’s role is very challenging and includes lots of difficult decisions. Be nice to your PO – create transparency and openness with your point of view and then respect their decisions.

The Role of the Developer in a Scrum Team

~ Adam ~ 1 Comment

Having covered the Scrum Events in recent blog posts I’m going to move onto the three Roles in any Scrum Team. These are Developers, Product Owner, and Scrum Master. This post will be about the Developers, I’ll cover the other two in subsequent posts.

Developer here is a rather broad term. Scrum is most commonly used in the software industry but not exclusively, and as we all know there are many other skills required to build and deliver software than crunching code. For the sake of simplicity The Scrum Guide has termed anyone working to create the product a Developer.

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The Scrum Guide 2020

It goes on to explain that the skillsets that the developers will need are wide and varied depending on the domain and nature of the product. For all intents and purposes the “Developer” is anyone who does the work. This could include (but is not limited to) Programmers, Testers, Automation Engineers, Infrastructure Engineers, and UX Experts. From the point of view of Scrum there is no distinction between these roles.

Interestingly the Scrum Master and Product Owner can also be Developers, it’s just that they take on more responsibilities with the additional role.

In Scrum a Developer is anyone who is involved in creating the increment each sprint.

Where the Scrum Guide goes into in more detail is what the developers are accountable for.

Creating a plan for the Sprint, the Sprint Backlog in other words the Developers, as the people doing the work are the ones accountable for creating the plan and Sprint Backlog. This is in stark contrast to more traditional management models where “the boss” creates the plan and assigns work.

Instilling quality by adhering to a Definition of Done the Developers are experts in their domain and professionals. They will create the Defintion of Done with the Product Owner and Stakeholders and hold themselves accountable to adhering to it.

Adapting their plan each day toward the Sprint Goal usually during the Daily Scrum. The Developers will inspect the current progress and adapt if required. They may seek out the Scrum Master or Product Owner if the impediments need to be adapted or if the approach to the Sprint Goal needs to change.

Holding each other accountable as professionals the best teams hold themselves accountable because the end results are important to them. All Scrum Team members should hold each other accountable for their actions and behaviour in a open and respectful manner.

Developers should hold each other accountable as professionals

It’s not easy being a Scrum Developer, a lot is expected of you. However, the experience of working in a team where people respect each other and have the courage to speak up and respectfully challenge ideas and designs is hugely rewarding.

This is why Scrum makes the accountabilities and values of each developer so transparent in it’s guides and resources.

The Retrospective

~ Adam ~ Leave a comment

The Sprint Retro is a key part of any scrum team which is looking to improve its process and adapt its ways of working to continuously improve. As with any adaption the key is transparency, the the more information the team can gather throughout the sprint around impediments or challenges they’ve faced the better. Personally I like to create a retrospective board at the start of a Sprint so team members can add their thoughts to the board as the sprint evolves rather than looking back (which always favours things which happen in the last few days).

The main challenge with the Retrospective is to avoid it turning into a moaning or helpless session. From The Scrum Guide:

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Guide 2020

Scrum Masters use a wide variety of techniques to support gathering information about the sprint including anyonmous submissions, “What Went Well vs What Didn’t Go Well”, and often scenarios involving rockets or icebergs. However, it’s important to remember that the Retrospective is a working session to give the team some concrete actions on what they can do to increase either Quality or Effectiveness (or, ideally both). While having a good rant about something which went wrong or something which impeded them can be therapeutic unless an action is taken to lean from that then neither objective should be met.

Teams must look at how to improve and adapt to challenges, not just moan about what got in their way.

This kind of adaption is not easy. It requires teams to look honestly at what’s happened and see what they could have done different, this kind of self assessment takes real courage and for the team to have a real growth mindset. It’s the delicate role of a Scrum Master to balance between criticising what the team should have done and coaching them to look for alternative strategies of what could be done in the future.

Its easy to say that a Sprint Goal failed because X in the infrastructure team. It’s much harder to reflect on what the team could have done to prevent that issue arising. It requires taking acountability and to avoid casting other people as villains.

In earlier versions of The Scrum Guide the team were required to add at least one action to the next Sprint Backlog, however it is now recommended to be properly alongside other work.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

The Scrum Guide 2020

The Sprint Retrospective requires the three pillars of empirism to be effective however this time they must be focused inward, at what the team could change or could have done differently. It also requires the Scrum Values to be first and foremost in everyone’s mind. Impediments can come from within the team as often as outside it and we rely on our courage and respect to get us through those tough conversations.

Please feel free to post in the comments below of any retropectives which have worked really wel for you in the past, it would be great to read about them.