Month: September 2021

Scrum Values – Openness

~ Adam ~ 2 Comments

I am writing about the Scrum Values and this week it’s the turn of Openness. Being open with each other and our stakeholders is key for the success of a Scrum Team. Scrum is built on Empirism which in turn has pillars of Transparency, Inspection, and Adaption. Without Openness there is no Transparency and the whole framework comes crashing down. Lets dive into this a little deeper to explain what I mean.

In Scrum we constantly inspect our progress, we do this at least once per day using our Daily Scrum within the Sprint and then again at each Sprint Review as we examine our progress against the Product Goal. The purpose of this is to detect any issues early and adapt our plan to ensure we can meet our goal despite the problems which arise. Transparency is vital to this inspection, if we do not make efforts to make our work and current challenges transparent then we will not be able to inspect or adapt. This puts the entire team’s long term goals at huge risk.

If we do not create transparency through openness then we will be unable to inspect and adapt.

As Scrum Team Members we must value Openness and Transparency. This allows our colleagues to support us, it also allows Stakeholders to engage and steer the team to providing true value for the customer. If we are not open with our work or our concerns then we will blunder into making mistakes which could have been avoided.

In previous posts I’ve referred to Steve Trapps’ excellent blog post about Scrum Values. In it he asks key questions which lets Scrum Team members assess their own levels of Openness, these are:

  • I do not shy away from telling difficult news to team members and stakeholders
  • I do not hide away difficult issues in the hope that they will sort themselves out.
  • If something / someone is annoying me I will address it / tell them.
  • My colleagues can judge what state of mind I’m in, I can share my feelings with my them.
  • I always say the true state of an item, and do not over/under play it.

How many of these questions can you truthfully answer yes? Are you building a safe environment so your colleagues can be open with you?

Look for Openness on your teams and evangalise it yourself, the results speak for themselves.

The Scrum Values – Respect

~ Adam ~ 2 Comments

We’re working our way through the Scrum Values, the second value I want to talk about is Respect.

Last week I shared Steve Trapp’s blog post. In it he asked Scrum Team Members

  • I listen with equal intensity regardless of who is talking.
  • When listening to people I never talk over them.
  • I value everyone’s opinion equally.
  • I am never concerned who works on what item in the backlog.
  • I feel that my opinion is respected and that I have an equal say in the team.

Respect is key in a Scrum Team. A good team is diverse and brings together different people with a wide variety of backgrounds and experiences. People can only work effectively if they feel safe to share their own points of view. If you haven’t already I strongly recommend reading 5 Dysfunctions of a Team as a great fable about why this is so important.

If we want to work well as a team it’s important we can engage in constructive conflict without making people feel vulnerable and worried that their ideas will be ridiculed. We all need to take responsibility for creating a team where respect for each other is paramount.

Of all the Scrum Values this is the one I believe is the most important. Great teams can adapt and rise to meet challenges, however a great team cannot exist without mutual respect between the team members and between the team and it’s stakeholders. Reinforce respect and you’ll build a strong team who can achieve great things.

How do you nurture respect in your team? What do you feel when working in a respectful environment? Let me know in the comments below.

The Scrum Values – Focus

~ Adam ~ 2 Comments

The next topics I want to discuss are the Scrum Values, these are Commitment, Focus, Openness, Respect and Courage. Or as I remember them Focus, Respect, Openness, Courage, and Commitment. I find the values some of the hardest parts of scrum. Not because I disagree with any of the values – I find them all admirable and praiseworthy but because I find them harder to measure. Its easy to see whether a team is running Daily Scrums, its less clear whether they’re displaying courage!

In his blog post on the Scrum.org website Steve Trapps talked did a fantastic job of articulating what these values look like when a team share them. For focus he said:

  1. Whilst working on a story I do not get distracted.
  2. If I am not enjoying the work in a story I still give it the attention it needs.
  3. When enjoying working on a story I will not over work a story just to prolong it.
  4. I do not procrastinate when working on a story.
  5. As soon as the story is ready to move into a new state, I will tell my colleagues and either hand it over or ensure that they know it is ready to pick up.

I think these are very valuable questions to ask yourself and your team to assess whether you are living the values which help support Scrum.

When Scrum Team Members focus on their work it helps the entire team achieve it’s Sprint Goal. This in turn moves progress towards the Product Goal and helps the Product Owner deliver real value to the customers. However, if team members are not focused, if they are distracted by endless emails or shiny opportunities then they often fail to deliver and the Scrum Team has to replan frequently.

Scrum Team members should value focus and avoid distractions.

It is everyone’s job as Scrum Team members to help reinforce focus wherever we can. To avoid distracting each other and to collaborate in a non-intrusive and distracting way. We should empower our developers to work autonomously and focus in a way which works best for them. For some people that means at home, for others that means in an office surrounded by people to collaborate with.

Keep focus in mind and always look for ways to encourage it both within yourself and within the team.

The Increment and Definition of Done

~ Adam ~ Leave a comment

The last couple of posts I’ve written have been about the Product Backlog and Product Goal then the Sprint Backlog and Sprint Goal. Today I’m going to focus on the Increment and it’s Commitment the Definition of done. These are slightly different to the previous two Artefacts and Commitments, the Backlogs and Commitments described above show the current progress of work and the vision of what that work will look like when it’s delivered.

The Increment is the piece of work which is being delivered to the customer at the end of the Sprint. These should be as small as possible, however it’s possible that it may be the entire Sprint’s worth of development. The Increment is the next piece of the product which has been added to create more value. Scrum.org has a nice defintion of an increment.

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

The Scrum Guide 2020

This is different to the previous to artefacts because it doesn’t describe the current state of what’s being worked on for the purposes of inspection, is is what’s being worked on.

Increments are added iterativly with each one meeting the Defintion of Done, this ensures that quality does not decrease during the Sprint. Photo by Startup Stock Photos on Pexels.com

However, as with previous artefacts it does come with a commitment. Where the Sprint Goal and Product Goal descibed the objectives we were working against the Definition of Done is a commitment to create transparency over what has been delivered.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The Scrum Guide 2020

One of the biggest frustrations in modern software development is when something is “done” but exactly what that entails is a little hazy. One team may mean code complete, another may mean tested, another may mean deployed to a customer. The Definition of Done creates a shared agreement of what the team understands “Done” to mean. This prevents the awkward scenario where a stakeholder is expecting tested functionality but gets only code complete stories.

It also makes estimation easier because everyone has a clear understanding of what is expected.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment.

The Scrum Guide

If a team is working as part of a Nexus of Scrum Teams developing a single product, or if they’re part of an organisation providing components to another team then the Definition of Done should be shared to ensure that all teams share the same understanding of when something can be said to be Done.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum

The Scrum Guide 2020

Teams which do not have a clear defintion of done experience friction when engaging with stakeholders, uncertainty when it comes to estimates, and ambiguity when planning out work.

A good Definition of Done should include items like:

  • Acceptance Tests Pass
  • Non Functional Tests Passed
  • Documentation Created
  • Deployment Pipelines Created

It may also include “deployed to customer” if a team is following Continuous Deployment practices. However, for the purposes of Scrum we commit that our increments will only be “Potentially Shippable”.

One final point, the Definition of Done ensures that quality does not drop as functionality is added. The Scrum Guide states that quality does not decrease during the Sprint. The Definition of Done helps us verify that each and every increment is complete and quality is maintained before it is declared complete.

Hopefully this has been helpful, I think it may be time to look at the Scrum Values!