Month: November 2021

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 Chimp Paradox Book Review

~ Adam ~ Leave a comment

I’ve done a LOT of scrum and agile posts recently. Time for something a little different.

I recently read The Chimp Paradox by Dr Steve Peters.

The Chimp Paradox

It’s an interesting book, especially if like me you like a little simplified physcology. Simply put Dr Peters has a model for explaining human brain functions which breaks us down to three constituent parts, the human, the chimp, and the computer.

The human represents the rational part of our mind. The computer our pre-programmed responses and habits. The chimp our fight or flight mechanism. He explains that when we feel threatened our chimp often wrestles control from our human. Much like you hear described in 5 Dysfunctions of a Team, Crucial Conversations, and other similar books which discuss safety. What I quite like about the chimp analogy is the recognition that our chimp has moods and a personality of its own. Personally I know I have a sulky and grumpy chimp!

It’s worth mentioning that Dr Peters had also written a related book called The Silent Guides which extends this model to children.

Definitely an interesting amateur physcology and personal development book. Nice and accessible if you’re trying to make your first steps into understanding the weirdness of other people’s (and your own) minds.

Have you read The Chimp Paradox? What did you think of it?

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.