Tag: Agile

How Should a Scrum Team Handle Holidays?

~ Adam ~ Leave a comment

The holiday season is upon us and rather than doing another post about my goals or new years resolutions I thought it’d be interesting to look at how a Scrum Team should handle the challenges of having so many people off at once.

What should a Scrum Team do if a large proportion of the team are on holiday at once? Photo by Andrea Piacquadio on Pexels.com

There are two sensible approaches towards Scrum over holidays when a significant proportion of the team are taking holidays. The first is to stop sprinting and resume in the new year. The team won’t set any Sprint Goals and anyone who is working will “make themselves useful” through tacking tech debt, process, or L&D type work. It’s passable… but I don’t like it.

The second option is to look at what exactly Scrum provides us with. Firstly, Scrum states that the next Sprint begins as soon as the previous one expires. There is no concept of breaking sprints in the Scrum Guide and the expectation is that a team will continue to run sprints from the day they’re formed (or adopt Scrum) until they’re either dispanded (or select another framework).

Instead we should look for an achievable Sprint Goal with at least one potentially shippable Increment which meets the Defintion of Done. This should be agreed by the entire team (or at least everyone who’s available). Therefore, rather than abandoning Sprints or Scrum altogether over the holiday seasons the team should look at what is achievable in the limited amount of capacity which will be available. Even if the goal is to fix a single typo then that is acceptable. As long as there is a single team member working at all then there should be a feasible Sprint Goal, the trick becomes looking at what’s realistic and possible during that time.

Do not be tempted to compromise. Whatever the increment should be it must meet the team’s Defintion of Done. Don’t “develop but not test” or “code but not merge”. Look for a single, simple improvement to the product which can be delivered in that time. Even if it’s only a simple bug fix.

With that suggestion I’ll leave you as I’ve got family stuff to do. This post is due to go out on Monday so if you celebrate Christmas I hope you’ve enjoyed it and if it’s your New Year coming up then I wish you all the best for it.

Thanks for reading and see you in 2022!

Where’s the Transparency for a Retrospective?

~ Adam ~ Leave a comment

I was teaching a Scrum course the other day and we had a really interesting discussion around the Transparency, Inspection, Adaption pillars of empiricism and how the Scrum Events were build around them.

A Daily Scrum is an opportunity to inspect and adapt their plan to hit the Sprint Goal. The Sprint Review is the place to inspect and adapt against the Product Goal. The Retrospective is where we inspect and adapt the team’s processes and tools in order to continue to increase quality and effectiveness.

Many articles and posts have been written about ways to improve the transpancy of work. We use tools like burn ups, burn downs, values like openness, and the three question format to Daily Scrums to drive this transparency at every level but do we stop and consider how we create the transparency needed to inspect and adapt in a retrospective?

How do we create transparency for discussions in a retrospective? Photo by Daria Shevtsova on Pexels.com

Lets start with the obvious stuff. In order to improve the team’s quality and effectiveness we need the team members to be willing to share what makes their lives difficult on a day to day basis. This could be a process, tool, or maybe a knowledge gap. This often requires courage, and requires a supportive team to encourage these issues to be surfaced and worked on. The team also need to feel supported by management, after all people won’t raise issues if they don’t feel they will be looked at or addressed.

We can also use data. Value Stream maps can be extremely helpful to understand where waste exists and how processes can be tweaked to improve.

Customer and stakeholder feedback can be analysed to understand where quality issues arise and what improvements can be made to a team’s testing processes to reduce these issues in production. If there is a support team tickets can be analysed and the time spend resolving these tickets looked at. We want our applications to be as supportable as possible and we want anyone manning a client service desk on our behalf to have all the tools they need to support our customers.

Finally, I’d also recommend opening the retrospective board at the start of the sprint, rather than just before the meeting. This allows team members to add issues as the sprint goes on, maybe even in Daily Scrum. This will prevent us giving undue weighting to issues which arose towards the end of the Sprint which are fresh in everyone’s mind.

If we truly want to inspect and adapt our team’s processes in retrospective events we need to ensure we create enough transparency in our work and product to be able to properly inspect it. What techniques have you found to draw out conversations for retrospectives? How do you ensure you’ve got enough information available to inspect effectively?

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 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!

The Sprint Backlog and Sprint Goal

~ Adam ~ Leave a comment

Last week I talked about what Artefacts and Commitments are and described the Product Backlog and Product Goal. This week I’m going to continue this theme but focus instead of the Sprint Backlog and Sprint Goal.

The Product Backlog is an ordered list of all the work which would deliver value to the product, we consolodate a future vision of this around a Product Goal. Within a Sprint we look at this at a much smaller scale, breaking down a single step the team aims to achieve and then comes up with a plan to deliver it.

Many teams I’ve worked with come at this the wrong way around. They look at the next work on the Product Backlog and through estimation and historical velocities select a number of stories which will “fill the sprint” usually carrying over anything which wasn’t completed in the previous sprint. Then they declare a Sprint Goal which is usually sounds like “Complete these Backlog Items” or “Do this, this, and this.” If you haven’t already I hightly recomment Jasper Alblas’ blog post about Sprint Goals.

Instead a team should look at their Product Goal and declare a Sprint Goal which will move them towards it. They should then identify the appropriate Product Backlog Items required to deliver that Sprint Goal and use estimation to ensure that it is realistic.

The Sprint Backlog should be a plan to achieve a Sprint Goal. The Sprint Goal should not be to complete a Sprint Backlog. Photo by olia danilevich on Pexels.com

The Scrum Guide tells us that:

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The Scrum Guide 2020

In other words once we have a Sprint Goal in mind we should identify the work required to deliver it (the what) and create a plan for how to deliver it (the how). With these three components in place we are in a position to start delivering.

As the Sprint progresses we should update the Sprint Backlog to reflect the progress of the work being delivered. PBIs may be marked as done or we may encounter impedements. However, by using the Daily Scrum sessions and the Sprint Backlog we’ve created enough transparency for us to be able to inspect and ensure that we are still able to meet our commitment – the Sprint Goal.

This is why a transparent Sprint Backlog is so important, it’s also why Daily Scrums are so vital. They give a daily opportunity to see issues and resolve problems so that the Sprint Goal is met. As soon as the team identifies that their Sprint Goal is at risk, perhaps the original approach won’t work or the effort required is greater than they originally intended they can adapt their plan.

Directly from the Scrum Guide

If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

The Scrum Guide 2020

In other words the team should attempt to meet their Sprint Goal in a different way, perhaps by negotiating scope or taking a different approach. If the Product Goal is simply “do the work” then there’s no way the scope can be renegociated and the team will not make a move forward against the larger Product Goal.

Finally, if something happens which renders the Sprint Goal obsolete, perhaps a significant new piece of information, business incident, or realising that it’s impossible the Product Owner has the authority to cancel the Sprint and replan a new Sprint Goal.

I hope that this has given some insight into why the Spring Backlog and the Sprint Goal are so important. Next week I’ll progress on and we’ll look at the Increment and it’s Commitment The Defintion of Done.

Artefacts and Commitments the Product Backlog and Product Goal

~ Adam ~ Leave a comment

Scrum contains three Artefects each of which have a corresponding Commitment. It took me quite a long time to get my head around these so I will attempt to explain what both of these terms mean here.

ArtefactCommitment
Product BacklogProduct Goal
Sprint BacklogSprint Goal
IncrementDefintition of Done

But what exactly are Artefacts and Commitments? The 2020 Scrum Guide explains that

Scrum’s artifacts represent work or value

and

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured…

…These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.

To show this I’m going to describe how these apply to the Product Backlog and its corresponding Commitment the Product Goal. Then, in over the next two weeks I’ll cover the Sprint Backlog, Sprint Goal, Increment, and Defintion of Done.

The Scrum Guide tells us that the Product Backlog (the artefact) represents Work (or value), it is an ordered list of all the work the team intends to do to deliver value to it’s stakeholders. The Product Backlog Items (sometimes written in the form of User Stories) are often sized to give an indication of how much effort is required to deliver them and to help the team with forecasting.

The Commitment contains the information to create transparency to stakeholders so they understand what to expect as the work is delivered. In the case of the Product Goal this is a medium term future state which the scrum team is working to deliver. It describes a set of functionality the team can use to plan against and create a focus beyond the Sprint by Sprint goals.

The scrum team can assess what’s delivered each sprint and look at the work required to meet the Product Goal. They can then decide the next work which needs to be delivered and begin to plan it. This is commonly done in the Sprint Review and Spring Planning sessions. In fact, when a team is following Scrum diligently there is often a lot of crossover between these two sessions with one flowing seemlessly into the next.

I’m having quite a lot of fun talking about Product Backlogs and Product Goals in Donuts and Dragons, the book I’m currently writing about Agile Doftware Development. Initially the team focus on improving overall user experience, then they realise that they need to pivot and adjust their Product Goal accordingly.

It’s worth noting that

[The Scrum Team] must fulfill (or abandon) one objective before taking on the next.

The Scrum Guide 2020

This is to prevent the team splitting their focus and attempting to deliver multiple projects at once. Obviously something which wants to avoided.

Once the Product Goal is met (or abandoned in favour of a more appropriate one if required) the Product Owner will work with the team to identify the next goal. It’s not uncommon to see a high correlation between Sprint Goals and “Releases” in more traditional organisations. While planning a single deployment from release is far from recommended it often helps businesses to group work together into Releases or Projects (I know, all dirty words in Scrum) and the team can map the Product Goals onto these. After all, what is a Product Goal if not a collection of work to be done to deliver value to stakeholders and transparency to the business?

I hope this post has been helpful, next week I’ll discuss the Sprint Backlog and it’s Commitment the Sprint Goal.

PSM-III Exam and Certificate

~ Adam ~ 1 Comment

Over the last I’ve been discussing the Scrum Master exams from Scrum.org. Today I’m going to look at the PSM-III, it’s the hardest and last of the scrum master exams. In their own words

PSM III certificate holders prove that they have a deep understanding of the application of Scrum, Scrum practices, the Scrum Values, and have the ability to apply Scrum in a variety of complex team and organizational situations.   

Scrum.org
The PSM-III is the highest ScrumMaster certificate at Scrum.org

According to Scrum.org’s own statistics at the time of writing less than 1000 people have passed this exam. That’s around 7% of the people who’ve taken the PSM-II and a staggering 0.2% of the people who have taken the PSM-I. In other words, PSM-III certificate holders are few and far between.

So what does the exam entail? As with all other scrum.org exams anyone can take them at any time, there’s no requirement to go on a particular course or buy certain books. The cost for this exam is $500, it’s expensive because real scrum experts mark it. The marks for earlier exams in the series are calculated automatically but the PSM-III asks the candidate to write answers to questions which are then marked. This obviously adds cost.

The exam itself is 30 questions and you have 2 hours 30 to finish it. The questions are a split of multiple choice and essay type answers. As with the PSM-II questions are much more focused around what you would do in a particular situation rather than asking you to give answers directly from the Scrum and Nexus guides. The pass mark is 85%.

Time is your big enemy in this exam (you know, other than the difficulty of the questions). You need to work quickly and make sure you’re covering all the points in each question. Particulary in the essay questions there are multiple points to address and you have to think and write quickly to ensure that you have enough time to finish the paper.

You should work quickly, not focusing too much on spelling and grammar but making sure you’re answering the entire question and what you have written is clear. You don’t lose points for typos but you will miss them if you get to the end of the time and haven’t answered all the questions. Work your way through the question and make sure you’re answering everything which is asked. In the multiple choice questions remember that more than one of them may be correct.

Not all questions are the same length so it’s not as easy as limiting yourself to 5 minutes per question. Some of the multiple choice questions may take ten seconds and the longer essays some significant time. Having said that, keep an eye on the clock and pick up the pace if you’re running behind.

When I clicked Submit at the end of the paper (with around 2 minutes to spare) I felt absolutely exhausted. But then the next trial begins. As I mentioned above the test is marked by scrum.org’s own experts so you won’t get your answer right away. You will get an email confirming they’ve got your answers but then you will have to wait, three weeks in my case and let me tell you it’s a very very long wait. At one point I even began to wonder whether the wait was part of the test and they’d see how I’d escalate or communicate with a third party supplier!

You don’t get the same category breakdown you do with the PSM-I and PSM-II but you do get a very helpful email with feedback, some questions to think through to further your learning, and hopefully some good news.

I found the entire process and exhausting and very rewarding experience and was delighted when my certificate came though.

What are your experiences of the PSM-III exam? What advice would you give to other people looking at taking it? Please drop me a comment below and let me know!

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.