Tag: Scrum

Goals for 2022 and a Review of 2021

~ Adam ~ Leave a comment

If you’ve been following this blog for a while you’ll know by now that as well as Scrum I’m a huge fan of goals, personal development and productivity. I mentioned recently that I don’t believe in annual goals. However, I do feel that it’s important to look back on what we achieved through the last year and what’s coming up.

I did something similar last year and gave myself the following goals for the year:

  • Read 21 Books – currently sat on 103
  • Write 52 Blog Posts – So far I’ve posted every week (plus a few more for the junior developer series I wrote)
  • Pass my PSM1 – Actually I’ve passed my PSM-I, PSM-II, PSM-III, PSD-I, and SPS
  • Finish my new book – Done, published Donuts and Dragons which is for sale on LeanPub
  • Finish painting my Stark and Lannister armies! – Done, also painted my Imperial Knights and Salamanders

In addition I’ve also passed the AZ-900 exam as well as AWS Cloud Practitioner, AWS Solution Architect Associate, and AWS Security Speciality.

It’s hard to pinpoint the highlights. Most likely passing the PSM-III exam, a really tough exam and something I’m extremely proud of doing.

As for low points. I had a really tough Q4 and it would have been really easy to give up. However I used the scrum techniques of inspection and adaption to identify the issue and prioritised passing the final AWS exam to get myself over the line. We’ve also had some tough months as a family which no doubt impacted caused the wobble.

I’ve mentioned before that I’m not planning on setting goals for 2022, instead I’m going to focus on Q1. I have a few overarching themes of AWS and Scrum which I intend to follow but would also like to spend some more time writing (and a few key work projects to deliver). When you are setting your own quarterly goals I would strongly encourage you to look at your key strategic goals and look at what the next steps are towards them. In my case (as you’ve probably noticed Cloud and Scrum feature very highly).

For Q1 2022 I plan to:

  • Read 20 Books
  • Paint Word Bearers, Raven Guard, and Tully Cavalry
  • Write my new Donuts and Dragons short story
  • Pass AWS Machine Learning Exam
  • Take Scrum.org Product Owner exam
  • Take Scrum.org Kanban for Scrum exam
  • Create and Deliver specific Scrum training course for colleagues at work

A nice balance of professional development and relaxation tasks with some work goals thrown in. Some of these are very ambitious but I’d rather try and fail than assume I can’t do it!

What are your New Year’s goals? Are you working over a 3 month planning period or over the full 12 months? Drop a comment below or let me know on Twitter.

Happy New Year!

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!

Managing Dependencies Between Teams

~ Adam ~ Leave a comment

When scaling Scrum the most important aspect to manage is the dependencies. Team should be working towards a combined goal which will be produced as an integrated increment at the end of the Sprint. This is not easy, as almost any broken down work will result in dependencies between the multiple teams.

It is so important to manage this that Nexus actually creates a team (called the Nexus Integration Team) who’s primary responsibility is the managing of dependencies to create this incremented increment.

There’s nothing more frustraiting than needing to get to work but being blocked by another team. Photo by Burst on Pexels.com

When managing dependencies there is a priority of severity.

  1. Another team in the same Sprint
  2. Same team in the same Sprint
  3. Another team in an earlier Sprint
  4. Same team in an earlier Sprint

Starting from the top (anohter team in the same Sprint) and working down these are the order in which a dependency will give you a really bad day. Obviously waiting for another team to complete something in the same sprint as you has far more potential to go wrong than your own team needing to complete something in this sprint to be able to work on something in the next.

Scrum.org has a great article on this which discusses how to track and manage dependencies. My personal advice:

  • List out the dependencies for every piece of work, you can’t manage what you can’t identify
  • Eliminate where possible (ideally in advance), manage where not
  • Use a Nexus Daily Scrum (slightly different to the more commonly known Scrum of Scrums) to highlight cross team impedements and ensure they are resolved as soon as possible
  • Use a visible board to track dependencies and impediments as well as work.

Hopefully this helps. Remember, each of your scrum teams should be producting a single integrated increment at the end of each sprint and aiming towards the same Product Goal. If that’s the case then identifying and resolving problems between the team will be much easier because everyone is working towards the same vision.

What are your experiences of scaling scrum? How did you manage dependencies between teams?

Advice for Taking the PSM-I Exam

~ Adam ~ Leave a comment

One of the most common questions I see on scrum forums is people looking for advice before they take the PSM-I exam. Why not? It’s a widely respected Scrum Master exam at a very reasonable price! I’ve previously written about the format of the exam. In this post I’m going to give my advice on how to pass it.

How would I advise you practice for the PSM-I exam?

Your first resource should be The Scrum Guide 2020 (assuming you’re not reading this in the future after a new Scrum Guide has been produced, in which case use that one!

Second, consider going on a course. Personally I have not attended a PSM-I course however I have only heard excellent things about them. How better to prepare for an exam than to get formal trainer from one of their highly qualified trainers? I believe the courses also include the cost of an exam entry.

You should also take the Scrum Open Assesment. Lots! Take that practice exam over and over again until you can reliably get 90% (or ideally 100%). Seriously, these questions are some of the best resources you can get to practice real PSM-I questions. Scrum.org also provides some suggested reading and a learning path which has some great content in there if you’ve got any weaker areas you want to address.

Personally I wouldn’t purchase practice tests or courses from Udemy or other suppliers. I’ve used some of these in the past and have to admit, I don’t really believe they’re worth it as they’re not that representative and you don’t really very much about the person who created them. Also, why would you need them when scrum.org provide such good practice questions anyway?

I’d be amiss if I didn’t at least mention my book… although in more seriousness. Donuts and Dragons is designed to give a friendly introduction to scrum, and show the events and principles in actions. It is not designed as a study guide.

Preperation for the exam is key. You’ve got an hour to answer 80 questions and you need to get 85% of them right in order to pass. As with all exams try and be well rested, don’t go into it under time pressure or with something else on your mind. Take your time, read the questions carefully, and you should have plenty of time to check your answers before you submit.

I really hope this helps! Please let me know in the comments below if it does. If you’ve got any other suggestions then please feel free to add it below.

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?

How to Manage Product Goals with Multiple Teams?

~ Adam ~ Leave a comment

As I mentioned recently I’ve been studying scaled scrum and recently passed the scrum.org SPS exam. One of the key aspects to this is how to manage work between teams so it’s a topic I want to discuss in this post.

The Nexus Guide provides a really good introduction to scaling scrum (other frameworks are available). There are two aspectcs which I see as key. These are for every team to focus on a single Product Goal and to minimise dependencies between teams. I’m going to focus onthe former.

In scrum we build incrementally towards a Product Goal, we review our progress in the Sprint Review and share progress with stakeholders then discuss what we should do next. It’s this level of transparency which makes scrum so powerful, it minimises risk and ensures we’re building the right thing.

However, when you have multiple teams all working on a product things can get complicated, you often see different teams with different project delivery dates and things get very very messy.

How should a business share work between teams in a scrum environment? Photo by Startup Stock Photos on Pexels.com

Generally a product should have a single backlog and a single active product goal. This makes sense. After all a product should have one list of improvements and should be moving towards a single known state, however it’s surprising how many organisations have a backlog per team, rather than per product.

Next, all teams should work together to create an integrated increment of all their work each sprint. This may sound controversial or even impossible but let me explain.

If your two scrum teams are creating increments each sprint they can do this in isolation (in which case they’re creating to diverging versions of the product) or they can integrate into the same master version of the product as they go. The former is no better than the vast feature branches we all remember with nightmares. Instead the Definition of Done should including integrating their increments with all other teams before marking work as completed.

So why can’t two teams focus on two different Product Goals? The question is why should they? A Product Goal represents a future vision of the product which the team is working to create. Surely we can’t have two visions?

Instead we should have a roadmap of upcoming goals. What we expect the product to look like after phase 1, phase 2, phase 3 or whatever. Scrum teams don’t pursue two Product Goals at the same time in regular scrum so why would they have any more success with multiple teams? To ensure the best chance of delivering effectively all teams on the product should focus on turning the active Product Goal into reality before moving onto the next. They can do this by breaking down the work in to individual pieces of work with the fewest dependencies between them, delivering them and integrating before the end of each sprint.

Fewest dependencies… that seems like a future post!

Seriously though, Scrum.org has some great articles on this stuff. If you’ve not already I highly recommend reading The Nexus Guide if you are trying to use scrum to deliver a product with any more than one team.

The Scaled Professional Scrum Exam

~ Adam ~ 2 Comments

I recently took scrum.org’s Scaled Professional Scrum exam. Scaling scrum to work across multiple teams is a difficult and controversial topic with several different frameworks and organisations vying for dominance. Less, SAFe, and Nexus all offer courses and solutions to this difficult challenge. Personally I opted to take the Nexus exam because I’d already studied it while revising for my PSM-II (and I’d liked what I’d seen) and because I hold scrum.org’s approach to learning I’m very high regard.

There are courses out there you can attend (and I have no doubt that they’re of excellent standard) however personally I chose to self study. I read the Nexus Guide, worked my way through the resources section, and read the recommended book. I also used the Open Assessment on this website.

You should be aware that the questions on the Open Assessment are only a subset and are only a sample of what you’ll face in the real exam. The questions for real are more akin to the PSM-II test with real world scenarios and you being asked which is the best approach. As with the PSM-II it’s not a matter of all answers except one being wrong and you often have to work out which one (or multiple) answers are the best.

You should also be the exam is almost entirely Nexus focused (which I expect goes without saying)l don’t expect 80% Scrum with 20% Nexus. Every one of the 40 multiple choice questions will test your knowledge and understanding of developing a product with multiple scrum teams.

I didn’t find myself under any time pressure. You have an hour and it only took me about 40 minutes to answer and verify all the questions. Nowhere near the sort of time pressure you face with the PSM-III.

Overall a really interesting exam with interesting topics. Definitely not one for a scrum beginner. But if you’ve passed your PSM-I or PSPO-I exam and would like to look at how scrum.org recommend scaling up to multiple teams then well worth a look.

Managing Interuptions and Cancelling a Sprint

~ Adam ~ Leave a comment

One of the more frequent questions I get about Scrum is how to manage interuptions within a Sprint. Interuptions and ad-hoc requests are a fact of life. Unless you’re working on a product which hasn’t launched yet there are going to be customer queries, and if you’ve not launched yet there’s a fair chance there will be questions from the sales and marketing teams or other stakeholders. There are a few options on how to deal with these. You can refuse to answer any query or request for help, or you can be the supportive colleague we all want to be. The real trick is how to balance these queries while still delivering the work the team is being paid to do.

In the past I have offered a few suggestions on how to approach this. What always strikes me though is how many teams either accept or push back on a request without understanding the impact it will have.

Should I support the business by answering quetions or deliver on the Sprint Goal? Photo by Robert Nagy on Pexels.com

Lets consider each piece of work which comes into the team as a new Product Backlog Item. This could be a support request or a question about how a particular piece of functionality works. As with all work it is the Product Owner who is ultimately resposible for maximising the value delivered by the team.

To do this we often need to pieces of information. What is the value this PBI delivers and how much effort will it entail. Now, there is no doubt that a level of pragmatism applies here. If the PBI is a quick email and won’t make any different apply the two minute rule and just do it. However, to avoid small task whiplash I recommend turning off email and IM notifications and replying to them in bulk.

Lets assume that a request for support is going to take more than 2 minutes. Perhaps the application is running slow in production. For the PO to make an informed decision he or she needs to understand what the impact is on the end user, are we talking a mild frustration (which could be looked at in the next sprint) or the system being rendered unusable. We also need to understand how long it will take to resolve. Remember relative sizing, is this likely to be more or less complex than the issue we looked at last week?

The first question which must be asked is “Can we respond to this request without jepodising our Sprint Goal?” If the answer is yes, then more often and not that’s exactly what the team should try and do. They should also use the Daily Scrum to continually reassess that assumption as the Sprint progresses.

However, lets say the team can’t help the business and meet the Sprint Goal. What should they do? Abandon the business in their time of need or give up on the Sprint Goal?

This is where the second question comes in, the urgency of the request. Lets go back to our example of poor performance in production:

  • This is a really big deal and needs to be looked at immediately
  • It’s a moderate issue, we should finish off the current Sprint Goal and then change priorities next sprint
  • The current Product Goal is more important and we don’t intend to look at this any time soon

I will just stress this again, this is the Product Owner’s decision, no one elses.

If the PO believes that whatever this support request is would deliver more value than hitting the Sprint Goal and they have agreed that the team can’t do both then this renders the Sprint Goal obsolete and the Sprint should be cancelled. The team should resolve whatever the issue is and then return to sprinting.

If the Product Owner decides to prioritise the work in a future Sprint (or not) then the work should be shown very clearly in a backlog. This is where transparency is key. Stakeholders grow frustrated when they request work and it vanishes into a black hole. By sharing exactly what the team is working on and seeing their work in the priority list stakeholders are able to engage with the PO to challenge priorities.

However the work is prioritised team members shouldn’t feel pressured into juggling both the Sprint Goal and the requests. That’s a great way to burn our engineers and put Sprint Goals at risk by hiding work in the gaps.

When one of the biggest challenge teams face is when the number of these ad-hoc requests means team sprints become disrupted over and over again. However, unless teams have a process in place when new work comes in then they will never stand a chance of maintaining sprints to continue to develop their product. When this process becomes embed and easy to apply it creates stability and prevents teams being pulled in different directions.

How do you manage disruptions? Do you cancel your Sprints when the goal becomes obsolete? Do you keep your backlog transparent to avoid stakeholder frustration – add a comment below or drop me a message on twitter.

The Scrum Values – Commitment

~ Adam ~ Leave a comment

We’re on our last Scrum Value (and possibly the end of my Scrum walkthrough unless I think of any more topics to cover). This time it’s the turn of Commitment.

To help me describe the importance of the values and how they relate to day to day work I’ve used the questions Steve Trapp has posted in his excellent blog post. Under Commitment he asks:

  1. I always know what the sprint goal is and how my work supports it.
  2. I do everything I can to ensure we achieve the goals of the sprint.
  3. In my current team, I have never thought of taking a sick day to avoid going into work.
  4. I always arrive on time for the events, my colleagues never have to wait for me to start the event.
  5. I know what it means to say that an item is done, i.e. I know the criteria that meets our Definition of Done.

This shows very clearly how important Commitment is to Scrum Team members. We value people working to support the Sprint Goal, doing everything they can to achieve it, and not being dishonest with our team members (no matter how hungover we may be!).

It’s also about professionalism. Arriving on time to events and ensuring that work we deliver is complete and meets the Definition of Done.

The Scrum Guide itself even has the concept of Commitments. The Product Goal, The Sprint Goal, and the Definition of Done. These are promises we make that we will aim towards. Commitment as a Scrum Value reinforces that idea of deliverying what we set out to right down to the individual level.

Scrum Team members commit to a goal and do everything they can to achieve it. Photo by Nataliya Vaitkevich on Pexels.com

When I talk about commitment I think a lot about the book 5 Dysfunctions of a Team. In it Lencioni discusses the importance of creating safety in our teams (respect for others), how this makes people feel confident to engage in discussions and voice their opinions (openness and courage). If people don’t feel they have their chance to voice their points of view then they will not commit to a decision and will not hold each other accountable for the results. By valuing Courage, Openness, and Respect so highly the Scrum Framework is building an environment where team members can commit to a decision or Sprint Goal and will want to do what’s needed to achieve it. Commitment stops being about “going the extra mile” for the company and starts being about colleagues and teammates working together towards a shared goal. This is what commitment is about for me, not about “taking one for he team” and working yet another late night.

When Scrum Team members all commit to a goal they will often find a way to achieve it, even if the original plan which comes out of Sprint Planning turns out not to work. Team Members become determined to adapt and find a solution despite the inevitable challenges.

What does commitment mean to you? Do you think you need to be working in a team where you feel safe before you can commit to a goal? Let me know on Twitter or in the comments below.

Scrum Values – Courage

~ Adam ~ 1 Comment

I’m working my way through the Scrum Values and explaining why each is so important to a Scrum Team. So far we’ve covered Focus, Respect, and Openness, today it’s Courage.

I think Courage is hard to define, as engineers we’re often courageous when picking up a new piece of work. We don’t always know how we’re going to solve a particular problem but we’re using to trusting in our own abilities and our support network to accept a task even when ambiguity and risk exists. There may be easier backlog items, ones which we know we’d be able to complete but we prioritise the most valuable, not the easiest.

Courage is a key component of any Scrum Team, even if it’s hard to define why. Photo by Marcelo Moreira on Pexels.com

Courage in my opinion manifests in a couple of ways. One of the responsibilities of any Scrum Developer is to hold each other accountable as professionals. This often isn’t easy, especially when the other developer is more experienced or senior than we are. If we believe that a particular course of action is the correct one it takes real bravery to speak up and make sure our point of view is heard. To understand why this is so important read 5 Dysfunctions of a Team!

It can also take courage to share our own weaknessess or concerns. But it’s this transparency which is so important for Scrum Teams to function effectively. If team members are afraid to share risks then they will most likely go ignored and the Sprint will fail.

Throughout this series on values I have referred to a blog post by Steve Trapps. He has posted a series of questions around the Scrum Values which can help you assess how strongly you live the values of scrum. For Courage his questions are:

  • I work on the next highest priority Product Backlog Item (I do not cherry pick the work I pick up in the Sprint)
  • If I see something that is wrong with what I’m being asked to do, I will say so.
  • I will question & reproach my team members if I feel that they are doing something wrong.
  • Regardless of the person talking, I will correct them if I believe that they are incorrect.
  • I will stand firm if I believe I am right, even if I’m in the minority within the group.

Do you think these are good questions to assess a team member’s courage? Do you believe you are courageous at work? Drop a comment below or contact me on social media to continue the conversation.