Tag: Nexus

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?

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.