Saturday, September 22, 2018

The sprint planning meeting that goes on forever | SupremeAgile

The sprint planning meeting is the longest meeting in the scrum framework and based on my experience it also the most exhausting meeting for most teams. The most difficult thing about this meeting is that team members often come to this meeting with the mindset that it will take the exact time written in the book…but it doesn’t!

In scrum we have a very important term called timeboxing. A time box is an agreed upon and limited box of time that is used by a person or team to perform a dedicated activity (see here for more information about timeboxing). Everything in scrum is time-boxed, including the scrum planning meeting, so what happens when the meeting time is near the end, and the team hasn’t determined the goal or sprint backlog? Do we end the meeting and continue it next week? Should we extend it? Do we just end it?

This scenario happens over and over, especially for new scrum teams that have neither the maturity nor the experience to conduct an effective sprint-planning meeting. So, what should one do in this scenario? To be honest, it really depends on what you want to achieve, but some common solutions that I love to use are:

Let the team learn the hard way

Let’s say that you have a team that is not willing to change their habits and continuously ignores the meeting’s timeframe. In this case, you can cut the meeting at the end of the time box, which will make the team suffer throughout the entire sprint. The ritual is that once you recognize that the team will not finish in time, you can address the team and let them know that the meeting ends in 10-15 minutes and let them choose whether to start the sprint with what they have or start all over again the next day (what do you think they will choose...?).

Extend the meeting and ignore the time-box

Another option is to ignore the fundamental foundations of agile and just extend the meeting while ignoring the meeting timebox. Based on my experience, if you do it once, it may help the team finish the meeting with a good feeling, but once the team makes it a habit it's a red flag for a much deeper problem.

During my many years as an agile consultant, I worked with hundreds of agile teams, and one thing that I know for sure is that you cannot let the team drag on the meeting. It usually doesn't help accomplish anything. People are tired and lose their ability to focus. If they failed to do an effective planning during the meeting, which can go from two to eight hours (depending on the length of the sprint), the chances are that the team won't manage it given the extension.

Another day, another chance

Another commonly used option is to re-schedule the meeting for the next day. In my opinion, it's the last option that I will use but still an option. If you decide to re-schedule the meeting, you must ensure that it does not become a regular solution for the team. You must perform a deep root-cause analysis (RCA) to understand why the team fails to deliver within the meeting time frame.


Each one of the solutions above is valid for specific cases, but to cut it short, no matter what option you use, the team must learn to conduct the sprint-planning meeting effectively as we expect to see in scrum. Make sure the team understands the importance of timeboxing so they can respect and follow it during the day to day activities. 

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

Sunday, September 16, 2018

An open letter to all product owners | SupremeAgile

Dear Product Owner,

Your job is to ensure that the product backlog is always in great shape. This is your responsibility to your team. Throughout the years I’ve seen you take your role and abuse it by not focusing on what is important for the success of your team. If you want to succeed in your role, please focus on the things that really matter to the team. By this I mean:

Clear requirements

Each story that you add to the product backlog should reflect a customer requirement, and it’s your job to ensure that the story reflects this. I expect to see from you a clear definition of what the team should develop to meet your request. Dear PO, sometimes you fail to do your job and share PBIs that are incomplete because you were too busy with other, less important things. Remember that this is what is expected of you as the focal point between the team and the customer. Dear PO, please do your work and ensure that the team gets solid and clear requirements, so they do not need to guess what you wish for.

Definition of done (DoD)

Definition of done is not optional for you to decide on; the team needs it to understand what they have to do to fulfill your vision. How can you expect the team to succeed if you cannot provide a mandatory thing that will reduce errors and miscommunication?

Your responsibility as the team’s PO is to work with the team to create and approve both the feature and the stories’ DoD. This is just the way it is: you just don’t have the privilege to say that it’s less important or obvious and have the team figure it out.

One thing that I want to say regarding this issue is that I trust you not to use a generic DoD that you created two years ago and apply it to a new project without reviewing it first. I know that you are a hard worker; please respect yourself and your team by doing the simple things that they expect from you.

Technical stories

Dear product owner, I know that you want to succeed, and there is no real reason for you to add technical stories that you absolutely have neither the knowledge nor the experience to write. But it’s not a shame for you to learn your product, and by that, I mean the technical aspects of the product. I don’t demand you be on the same level as your development team, but at the very least you should be able to review the story and make sure it makes sense for the team. Learning will allow you to create a better story that the team can actually accomplish because you understand what you’re asking for and whether it is possible for the team to deliver it.

Now, I know that for some POs this is a hard thing to ask. So the only thing I can say is that at the end, it’s up to you to decide whether to take real ownership on your deliverables or whether you’re just acting as a basic proxy between the team and the customer.

Live and let live

Dear product owner, I know that there are a lot of expectations from you to deliver. After all, you are the one who interacts with the customer, who sometimes puts great pressure on you. I understand it, I truly do. But this does not give you the right to interrupt the team during the sprint with "small" urgent items that the team must deliver just because there is some pressure on you. I don’t have any complaints about changes that you want to make once the team is already committed to the work (this is agile after all), but there is a difference between working with us to understand how your requests will impact our commitments and just adding PBIs to the sprint without considering how it may cause us to fail. 

There is nothing wrong with collaboration

If I were in your shoes, I would use the vast knowledge of my team in all aspects related to my role. How can they contribute, you ask? Well, they can help in the creation of the technical stories or help with the DoD or just become more motivated to help you accomplish your vision because you collaborated with them.

Another aspect related to collaboration is your participation in the sprint meetings. Now, I know that sometimes it may seem less important to you, but know that your team needs you. I expect to see you at the daily scrum meetings to see team progress and the problems encountered on the way to accomplish what they promised you. Refinement meetings should be with the team; this will help the team understand and determine rough estimations that can change your prioritization. Believe me that the team will greatly appreciate the chance to reduce the time of the planning meeting.

You are the master of the review meeting, but it’s also your chance to build a strong committed team by sharing productive feedback. You will not achieve anything with negative feedback. Retrospectives? I know that in some cases you are not invited because it’s a "team" event. But I believe that you are part of the team and therefore must take part. I know that you feel that it’s not related to you, but I promise that you will see that you can become a highly effective contributor.

Planning meeting? Yes, you usually take ownership on the first part (story review and setting the iteration goal) and fade out while the team starts to estimate and add their tasks. This is your chance to collaborate with the team and answer all open questions, change the original prioritization, and break down stories that the team cannot accomplish in the upcoming sprint.

Why don't you focus on our team?

Dear product owner, I know that you want to show that you have the skills to handle more than just one scrum team, but to be honest you don’t. I expect from you to be 100% focused on our team. We trust you to lead us to a better future while we trust your judgment and decision making. 

You are not a child; you cannot get it all

Dear product owner, part of your job is to prioritize the backlog to allow the team to deliver the most important stories first. But you are not a child, and you know that there is a reason why the prioritization starts with the top items first, and there is a reason why these stories are ordered (if not, we have a bigger problem than I thought).

The prioritization process is used to avoid a negative approach of "must" have. Remember that it’s the team’s responsibility to decide how many stories they can deliver during a sprint. Yes, their efforts are based on your prioritization. But once they decide that they can commit to only ten stories based on that prioritization, you cannot use the word "must" for stories exceeding this number. This will result in over-commitment and less focus that will most likely lead to poor deliverables. 

Know your boundaries and do not cross them

As the product owner of the team, you must ensure that the team has a clear definition of what they need to do to deliver the best product for the customer. Sometimes you forget the clear boundaries between you and the team, which will most likely influence team effectiveness, morale, and motivation. Now, what do I mean by this? Let's start with the basics: you are not supposed to interfere with the daily work of the team. I know that you probably think that you know better than the team just because 10 or 20 years ago you were a developer or a project manager chasing people to deliver what you asked of them.

It is NOT your job to interfere with team decisions on how to deliver what you asked. Your job is to prioritize the backlog to allow the team a clear definition of what you really want. While I expect you to be at the team’s daily scrum meetings, this meeting is for the team and not for you to control and interrupt. And above all, you are NOT the team manager who tracks their progress and asks them what they are doing in their day-to-day activities. You can gain this information by coming to the team’s daily meetings, reviewing the burndown chart, or just seeing the PBI state in the sprint backlog. In addition, while your participation in the team planning meeting is highly requested and most appreciated, you are NOT allowed to push the team to over-commit on work that they will most likely fail to deliver.

What is your vision?

Dear product owner, as a team member in your team I have enough going on without having a clue about why we are building the product the way you decided. I know you always say that the product backlog is enough to us to acquire this information, but there are 100 other teams that are working on the same projects, so I ask how we can understand the company vision without your help. Dear product owner, I expect to see a clear vision of the product. This will help us see the big picture and gain a sense of ownership over the product.

Knowing the importance of quality

Dear product owner, I know that you have a lot of pressure to deliver features to our customers. And yes, I also understand that this is how you can show how good you are by pushing the team to deliver faster while focusing only on getting more and more new features that will add value to the customer. But now you can see that quick deliverables that do not give real attention to quality are starting to affect our ability to deliver at the same pace we used to.

Dear product owner, can't you see that we invest a huge amount of time per sprint to fix quality issues that come from the field just because you thought that there is no room for investing in quality aspects such as test automation, unit tests or performance aspects of the application? These now come back to haunt us in the form of technical debt and bugs that consume most of our time. Dear product owner, I hope that you now become smart enough to understand that quality is a crucial part of what we are doing. I know that from now on you will allow us to create PBIs to will help us to create a better product that will allow us to increase quality and reduce future technical debt. 

With love,
Your team

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

Thursday, September 13, 2018

Regain team motivation by using slack time | Supreme Agile

Similar to real life, you can’t always sprint. If you're not a robot you need to rest in between sprints. What’s relevant to the best athletes is relevant to scrum software development as well. In scrum, the team works in short intensive iterations of 1-4 weeks, which is quite different from what we used to see in traditional software methodologies that are more similar to running a marathon.

Scrum sprints are very intensive because their main purpose is to provide value to the customer who is waiting at the end. At the start of the sprint, the team creates the sprint backlog that reflects their commitments (here is some pressure…) and needs to work in a very fast and changing environment. A team member who needs to work in such an intensive environment usually does not have time to relax and put off their tasks (the customer is waiting). So in the end, there is really no time for resting, which is highly important.

“Slack time” provides the rest time the team needs in order to regain their strength. But that's not all: it also helps increase team motivation and morale (important factors for creating self-organized teams). At the end of each sprint, the team conducts a review meeting, where the team presents the sprint deliverables, and a retrospective to discuss what the team wants to improve/keep in the next sprint. After these meetings both the team and the product owner will be full of information, tasks, and ideas that they need to implement in the upcoming sprints.

The common practice in the industry is that the scrum team starts the planning meeting right after the retrospective is over, so they can start the next sprint on the first day of the following week. And now for a simple question: do you think the team can effectively prepare for the next sprint with all the data they generated during those meetings (which is still related to the previous sprint)?

The answer is very simple: if the team immediately starts planning the next sprint, I can assure you that the chances are that the majority will not be focused enough to conduct the meeting as they could have had they had the time to stop and think about all information and lessons learned. The PO will not have time to prepare the backlog (based on the feedback received during the retro/review meetings), and so on.

Let’s give the team some slack

The solution to the problem I just described is to introduce some kind of slack before the team starts the new sprint. We would like to make sure the team has time to rest and think in the period after the sprint retrospective and before the next sprint planning meeting.  

One thing that I learned over the years is that you cannot always succeed with this approach, but at the very least, you need to try to give the team some slack prior to jumping into the planning meeting. To do so, sometimes I change the meetings’ timeframes by sending home all team members once they complete the retrospective of the current sprint and schedule the planning meeting for the next day or the beginning of next week.

Without using slack time:
Friday 10:00-11:00: Sprint review (Sprint 1)
Friday 11:00-12:00: Sprint retro (Sprint 1)
Friday 13:00-17:00: Sprint planning (Sprint 2)

With slack time (option 1):
Friday 10:00-11:00: Sprint review (Sprint 1)
Friday 11:00-12:00: Sprint retro (Sprint 1)
Friday 12:00: slack time.
Monday 09:00-13:00: Sprint planning (Sprint 2)

With slack time (option 2):
Thursday 08:00-09:00: Sprint review (Sprint 1)
Thursday 10:00-11:00: Sprint retro (Sprint 1)
Thursday 11:00: slack time.
Friday: Learning time
Monday 08:00-12:00: Sprint Review (Sprint2)

Note that in option 2 I added another day (Friday) that the team can use for learning or in some other cases to do whatever they think is best for them (in most cases they will invest the time to create a better working environment that will be worth the effort in the long term).

If you decide to use learning days there are some tips that can help:

  1. Learning days should be added per month and not after each sprint, so in the case of two-week sprints, we will add one learning day at the end of the second sprint.
  2. Although this time is dedicated for the team, you still need to see whether it adds real value. There is no reason to use these days without adding real value to the team, process or the business.
  3. Try to make this day global for the whole organization; it becomes less effective when some teams are working and some are resting.

Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile

My Presentations