If you’re a Scrum Master or a member of a Scrum team, I’m sure there were times when you wondered if the Daily Scrum is really necessary or felt that it has lost its purpose or it just became boring. I can understand that. Since it’s a daily event and you’ve been through some sprints, the Daily Scrum surely seems it has lost its magic.
But not all is lost. You can recover that excitement you had when Scrum first started and you had the firsts Daily Scrum. In this article we’re going to remind you why the Daily Scrum is important, how to make the most out of it and even some tips and tricks to keep it alive.  

First things first. Why hold a daily event where team members answer the same questions every day? Perhaps no significant progress it’s made from one day to another, so what’s the point? From these questions we can easily understand that the person asking them (it might be even you) no longer sees the value in this event. So allow me to remind you. 
The scope of Daily Scrum it’s to sync-up the team, to openly express any concerns team members might have and identify the blockers. Yes, the team members already talk to each other on a daily basis, but at the Daily Scrum they have the chance to speak together. The knowledge one team member has can be shared with all the team. Alternative, more optimal solutions can come up collectively as the team discusses its progress. As a team they can see how far or close they are to the Sprint Goal. This particular event contains all three Scrum empiricism pillars – Transparency as every team member knows the team’s progress, Sprint goal, Inspection as the Development Team inspects how the Sprint Goal is impacted and Adaptation, as based on the progress towards the Sprint Goal the team plans for the next 24h.

To make the most out of it, the Scrum Master or facilitator if there is one on your team, should guide the team to ensure that the discussion is meaningful. This means that if the discussion strays away, he or she should bring the discussion back on track with the adequate questions. When issues are identified, the team should not try to solve them during the Daily Scrum. It will surely make the event longer than 15 minutes. There are solid reasons for which the 15 minute time-box is strictly applied for the Daily Scrum. If it takes longer than this it becomes tiresome, the scope is somewhere lost, team members stop paying attention and it’s genuinely just wasted time. If it takes less than 15 minutes that’s just fine as long as the team is synchronized, there is transparency regarding each member’s work and mistakes or impediments are identified. 

To make it less boring, you could try different techniques for conducting the Daily Scrum. For example you could toss a stress ball at the team and whoever catches it starts first. And then throw the ball at a random member to continue, not necessarily the one beside him/her. You could also use the technique “Walk the board” where team members talk according to each story. Start the day with a joke or a story to start the Daily Scrum in a more entertaining manner. Start a parking lot for issues that are not discussed. What you need to do is to have a whiteboard or just a simple board where they list down the issues which are to be dealt with later. After the meeting gets over, schedule another meeting with only those members who are directly related with that particular issue and solve them.

Hope you enjoyed this article and that it will help you on your future Daily Scrum meetings. Feel free to comment and contact us and share your ideas on how to improve the Daily Scrum!

Nexus (n): a relationship or connection between people or things

No, it’s neither the famous Google phone, nor Nokia “Connecting people” but rather a relationship between people or things. But what does that exactly mean? It feels like a general concept, doesn’t it? Today, my friend, we will take that general idea you have about Nexus and magically transform it into valuable knowledge that you can use and/or promote in your company. If you’re interested, keep reading. If not, think of a little baby Panda crying. Alone. In the rain. Looking at you.

What is it?

Nexus is a lightweight framework developed by Ken Schwaber, co-author of Scrum Guide. Thus, its baseline is Scrum. It does not provide all the answers, but instead provides the fundamental guidance to support sustainable, complex software product development at scale. If your company has one product and many Scrum teams working on it, you know how dependencies between teams become hard to handle. Thus, the delivery of the magnificent increment your team works so hard on, will be delayed. How do you overcome these delays? How can you prevent dependencies or how can you solve them within a day? Nexus might be the answer. Best applied to multiple Scrum teams, 3 – 9 teams, working on the same product.

Considering that your company already has applied Scrum framework, you won’t have problems with Nexus roles, ceremonies and artifacts as they are quite similar and complementary. We will now proceed to describe the basics of Nexus.

Nexus additional role

In addition to your existing Scrum teams, Nexus includes a new role, Nexus Integration Team (NIT). This new role has its own Product Owner, Scrum Master and one or more Nexus Integration Team Members(often also members of the individual Scrum Teams). The NIT is accountable to make sure that there is always a “Done”, Integrated Increment and that the dependencies are visible and dealt with as needed.

Nexus Ceremonies

In Nexus, a Sprint starts with Nexus Sprint Planning, where the activities of all Scrum Teams in a Nexus for a single Sprint are coordinated. Frequently a big room planning is used for this ceremony, in order to make interaction between teams nice and easy, and help dependencies be dealt with as promptly as possible. The result is a Nexus Sprint Goal, a shared Definition of Done and a refined Nexus Backlog.

The Nexus Sprint continues with Nexus Daily Scrum held everyday before the Daily Scrum. During this event the team starts focusing on the Nexus’ Sprint Goal by inspecting the progress towards it and asks these three questions: 

• Was the previous day’s work successfully integrated? If not, why not? 
• What new dependencies or impacts have been identified?
• What information needs to be shared across teams in the Nexus?

Throughout the Sprint, a Nexus Refinement could happen as often as necessary to identify dependencies across teams, to slice the Product Backlog Items until they are independent enough to be worked on by every Scrum Team. The result is a refined Nexus Backlog and items ready for selection during the next Nexus Sprint Planning event.

The Nexus Sprint Review is held at the end of each Sprint to gather feedback on the Integrated Increment. Since all Scrum Teams worked for the Increment, the individual Scrum Teams do not hold their Review. The result is a revised Product Backlog and valuable feedback.

Lastly, the Nexus Sprint Retrospective is the opportunity for the Nexus to inspect and adapt itself. It occurs after the Nexus Sprint Review and before the next Nexus Sprint Planning. Representatives of all Scrum Teams gather to share insights affecting multiple teams. The issues discussed are then brought back into the teams’ regular retrospectives.

Nexus Artifacts

There is a single Nexus Product Backlog from which the teams pick their items. The Product Owner is responsible for its content, prioritization and transparency. The items can be considered “Ready” when teams can select them with minimal or no dependencies at all. 

The Nexus Sprint Backlog is a piece of the Product Backlog of the individual Scrum Teams. It is updated daily as part of the Nexus Daily Scrum.

Last but not least, the Integrated Increment that sums up all the integrated work performed by individual Scrum Teams.  Must be a piece of working software and potentially releasable, thus meeting the Definition of Done. 

Hope you enjoyed reading this article and that you learned the Nexus basics from it. The little baby Panda bear is now smiling. Eating bamboo. Looking at you.

Inspired by Nexus Guide and Fredrik Wendt’s article on Nexus Framework.

We all know that teams sometimes or oftentimes (hopefully sometimes only!)  get bored eventually. They get bored of the Scrum events and it’s something we have to admit it happens. When it does happen, how can we improve it? Can we prevent it? Can we do anything about it at all or do we just wait for a miracle to happen?

As a Scrum Master I’ve been through this phase and I’ll be honest, it’s not something I enjoy seeing. But we do have to accept the fact that as human beings, we can’t be hyped all the time or overly active, it’s practically impossible (unless there are some dubious, fishy stimulants you’re taking). In these cases, how can we make a team eager to participate in our retrospective games?

Today I am going to share some tips and tricks on how to overcome these boring retrospective meetings and hopefully they’ll work on your team too.

Remind the team the value of the retrospective

It’s easy to forget the reason we’re doing certain things, especially when we’re so drowned into them. Same thing happens to your team. After some iterations they might have forgotten why they’re doing retrospectives at all. 

At times, try to remind the team the value of the retro event. That is the time to truly reflect on what could have been done better. That is the time to celebrate once more what went well. Admitting mistakes they might have made will help them improve even more. It’s their chance to speak out if there is a problem in the team and express their concerns and thoughts regarding the process, team, etc. 

Play with the games

Some teams might see the retrospective as Play Time. It’s not necessarily bad as long as they enjoy the game and get to be more relaxed. 

However, in order to keep the retros fun and nice you shouldn’t repeat the same game for two retrospectives in a row. And if you’re doing the same game every time, then surely your team will get bored. Let it be more than “what went well”, “what didn’t go well”.  There are plenty of sites with retrospective games to choose from. Check out these sites Tasty Cupcakes, Retromat, Fun Retrospectives.

You just need to pick a couple or even combine the games. You can also choose games that will involve the team to actually build something or move around the room. You’ll be amazed to see how the team will impatiently wait for the next retrospective to start.

So, all in all, spice things up a bit and you should be fine!

Change the place 

Before you start shooting, I know, I know that Scrum says to keep the same place and time for the events in order to be consistent. However, in my humble opinion, a change of place will do nicely for the team retrospective. I’m not implying that every retro should be in a different place, that would be a little chaotic and unstable. But once every 10-15 sprints could be a beneficial change. This will get the team to be more relaxed, tension will be released and they might even share more information, more details. Just make sure to keep the action points! 

Keep the timebox and discussion on topic 

Sometimes during retrospectives the discussion will go off topic and to unnecessary lengths. Why does it happen and how can you prevent it? Perhaps you have in your team that one guy that’s really talkative and gets the discussion to destination unknown. Or the grumpy guy that won’t stop complaining even though the issue is resolved. When it happens you might have noticed that the other members will be left with little time to discuss their concerns. This leads to an unhappy retro where only half the issues were discussed. Fortunately there are some solutions for these cases. You might have a timer watch, visible to all so that the team can see how much time is left for them to speak. When discussion goes off topic interrupt the person speaking reminding him/her the real topic. Or you could have a buzzer that will be hit by the other members of the team when one goes off topic. Apply the solutions a few times and the team will learn how to keep the timebox and the discussion on topic. 

Hope you enjoyed this article and learned something new. If you have any more ideas on how to overcome boring restrospectives, please comment below. Sharing is caring after all!

Individuals and interactions over processes and tools.

— Agile Manifesto.

Welcome to the Agile Dojo, the place of the Agile! Our goal here at AD is to express our ideas and experiences in our attempt to discover new ways of delivering the highest value, faster to our customers. Whether it is Agile, Product Design or Team Coaching, we will try to cover as many topics as we can. Feel free to contact us, we are always open to suggestions.