Voices on Project Management

by Christian Bisson

I’ve recently been part of a discussion concerning changing the length of sprints from two weeks to three weeks, and the product increments (“PI” from SAFe) from 10 weeks to 12 weeks. Hearing the arguments throughout the meeting made me realize how the impact the sprints have on teams is greatly underestimated. Also, it’s important to note that in this case, the sprint length is aligned for all teams—meaning all teams need to change.

In the discussion I was in, the arguments for having longer sprints were that it would reduce the number of meetings (therefore deliver more value), and that we would have better sprint reviews. Let’s review those arguments, and other factors to consider

The Number of Meetings

Assuming we are only referring to “agile” meetings, it’s true that the events (ceremonies) will occur once every three weeks instead of two weeks. However, aside from the daily scrums, the length of each of those meetings is expected to be extended accordingly. 

For example, a good rule of thumb for sprint planning length is about one hour per week in the sprint, so a two-week sprint would have a two-hour sprint planning meeting, and a three-week sprint would have a three-hour meeting—making it an average of one hour per week, and thus not really saving time. The same goes for the review and the retrospective.

The daily is the exception; that would remain at a maximum of 15 minutes every day, so no gain there either.

Better Sprint Reviews

In theory, since sprints would be longer, teams should deliver more within them (more on that under “Predictability” below)—and that will allow teams to present more accomplished work.

Depending on your circumstances, one could even argue that stakeholders would need less travel time to attend the review since it’s once per three weeks instead of two (although these days, even that argument has lost its value!).

But let’s look at the other side of the medal. The review is a key event to gather feedback from stakeholders and obtain precious information to move forward. That now happens less often, and could risk gaps in communication. In some cases, releasing an increment of work is not possible without having approvals within the review, meaning that value could be delivered slower.

So for this argument, I would caution analyzing your circumstances properly before deciding it’s a good idea to change the length of the sprints.

Predictability

This argument was the “con” discussed in our meeting, which I felt was underestimated. For organizations and teams, having good predictability means delivering all (or almost all) of what we forecast to deliver within a specific timeframe. This is key for planning product roadmaps, aligning dependencies, forecasting budgets, etc.

Predictability in our world is a challenge though; as we know, things change, and what we thought would bring value is only confirmed by empirical information that allows us to adapt as needed. This means that the longer the forecast is needed, the less chance we have to be accurate.

Don’t get me wrong—teams that have gained a certain maturity are expected to get to a point where they can accurately forecast the work they’ll accomplish within their sprint, and moving to a longer sprint would be viable for them. 

But the maturity of the team may vary, and in our case, we were talking about brand new teams that had a decent amount of carry-over from sprint to sprint already, so it was a no-brainer that they would struggle with longer sprints.

Scope Stability

Another element to take into account when selecting the length of sprints: Are the circumstances related to the scope stable enough to be able to focus on a sprint that doesn't (or barely) changes? The longer the sprint, the longer a potential “change” would have to wait—and if it can’t, then the sprint’s scope risks being changed.

Estimating and Splitting Stories

In order to properly plan and deliver sprints, it’s a good practice to split stories so that they fit within a sprint. Therefore, the smaller the sprint, the more it’s important to split stories—and that’s a habit teams develop as they grow.

On the flip side, if a team has not yet developed a good habit of splitting stories, a larger sprint will give it the impression that “it can be delivered within a sprint.” This results in a higher risk of having a backlog of large items that the teams struggle to deliver.

Conclusion

The length of a sprint largely impacts the ability for teams to forecast and deliver accurately. It’s not a decision that should be taken lightly. It’s also important to involve team members in the discussions.

What factors do you consider when deciding the length of your sprint? Any lessons learned to share?

by Christian Bisson

For far too long, I've seen new teams being set up with barely any time allowed to actually enable their success. There are many aspects of creating a new team that people forget or underestimate, and it can create short-term and long-term problems.

With all of the different topics the team should cover at the beginning, an effective setup could easily take two or three full days.

Here are several aspects that should be included:

Meet & Greet

If there’s one thing I've seen being left aside because "it takes time we don't have," it is allowing the people who will work together to actually get a chance to get acquainted with each other. This is an important aspect as it helps to build trust among team members, and trust is the foundation of any efficient team. Trust will not be built overnight, but planning a team-building activity to allow people to share about themselves will at least give it an initial boost.

The team-building activity can take many forms. Regardless of what is chosen, it should be something anyone would be willing to jump into. Some people will be shy at the beginning and not everyone will feel very open, so make it something accessible. 

Identify a Framework

Another important aspect is to identify the framework the team will be using. Is it scrum, Kanban, waterfall? Typically, this is already decided. Assuming everyone is an expert in the framework, the team just "jumps" in it. It's important to plan time for training on the topic, and a decent training could easily take a full day or more.

Let's use scrum as an example. Training should include an overview of the framework and other aspects like the roles within a scrum team, backlog management (ex. writing user stories, how to properly split them, etc.), how context switching can affect productivity, etc.

Discuss Ways of Working 

Along with the framework, there are other aspects that the team members need to agree on. These will vary depending of the framework and the team's circumstances, but here are a few examples:

• Team agreements: The team should agree on day-to-day aspects of how they will work. For example: What time are the scrum ceremonies? What's the decision-making process? What tools will be used? What are the communication channels? What standards dictate how to work (ex. coding standards)? 
• Definition of ready: This is a definition agreed upon by the whole team on what is required for an item in the backlog to be considered "ready" to start working on it. For example, it would need a properly formatted summary, acceptance criteria, etc.
• Definition of done: Another important definition the team should agree on is what is considered "done" for a backlog item. For example: test coverage, approved by someone, code review was done, etc.

Agreeing on these can easily take a few hours depending on the size of the team and the maturity of good practices.

Knowledge Mapping

Clearly identifying each team member’s skills is likely the most forgotten aspect of setting up a team that I've seen so far, and yet it's crucial to:

• Identify missing competencies
• Identify the gap between team members
• Track team development
• Identify missing resources

Once this is mapped, it's easier to plan accordingly on how knowledge will be gained. For example, if a technical skill is only known by one expert among the team, it could be planned for that person to train the others. It might be knowledge about the system the team will be working on that will require ramping up. You might also notice that some expertise is completely missing from the team and needs to be acquired from a source outside the team.

Having the team discuss what skills are required, having them map out their strengths and weaknesses, and then discussing next steps is not in itself very time consuming, yet many teams skip that part and thus risk hitting roadblocks along the way.

Conclusion

I've written a few examples of what should be part of a team setup agenda. You can see that for it to be an efficient setup, the team will need time—which will pay off immediately. So "just do it!" 

How are you setting up your teams? What topics are necessary? 

By Christian Bisson

In this article, I refer to “a single point of failure” as the situation when a company utilizes someone with unique expertise/knowledge that no one else has, or is the only one who does a particular task. By having these single points of failure within a team, you risk facing problems if that person becomes unavailable—or even worse, just isn’t part of the team anymore.

Fortunately, there are various ways to mitigate this!

1. Rotate roles within the team

There are several tasks that often fall by default on the scrum master or the “nice guy’s” shoulder. A good example is sharing a screen so everyone can see the backlog for a planning or a refinement session, or sharing the board in a daily scrum (if it’s not physical).

If that person is not there, then the meeting becomes less effective because the logistics (using Jira, screen sharing, etc.) is not necessarily well known by everyone.

By having a rotation system (by random name picking, for example), these tasks are eventually done by everyone and all can be efficient doing it eventually; therefore, the team doesn’t become dependent on a single person to know simple things like updating the story points of a ticket using Jira. 

I once came across a team that couldn’t do its own planning without the scrum master sharing the screen and going step by step with them, and it had been doing it for several months!

2. Conduct knowledge transfer sessions

This can be done in many ways, but I’ve seen a lot of teams planning a weekly knowledge transfer session, where each time someone presents something to the others (a new tool, something they just coded, etc.). Another good way for developers to share knowledge is for them to code pair. That way, the code itself is known by two people instead of just one; throw in peer reviews on top of that and you will be in better shape if someone leaves or is on vacation.

The idea is to avoid having only one person knowing something; always aim for a minimum of two people. If you want to identify gaps, there is always the classic “lottery winner” scenario you can use, which is to keep in mind that it’s possible for someone to win the lottery and therefore become unavailable without notice. Although it might seem unlikely, the idea is to ask yourself: For every member of the team, what would be the impact if that happened?

3. Rotate members among teams

This practice is debated, but I feel it’s a good way to make sure the knowledge is properly spread. The idea here is to have a rotation system of team members among the teams. This practice is questioned by some, who will argue that to be effective, teams need to be stable—and changing it will make it regress to the “forming” stage.

That is indeed important to keep in mind when thinking about how/when the rotation will occur, but in the long run, people will be accustomed to working in all the various teams—and also be knowledgeable in all the different pieces each team takes care of. This gives a much higher flexibility depending on deliverables/vacations/etc., and lowers the risk of losing knowledge on something within the organization.

What tips do you recommend?

By Christian Bisson

A key artifact for any successful team is a healthy backlog: a list of what’s needed to bring value to the project—written in a way the team can understand and ordered so the team is always focused on what brings the most value.

Yet between all the user stories, enabler stories, technical stories, bugs, defects and so on, it can be quite challenging for a product owner to order all of this properly. 

Here are a few (ineffective) ways I’ve seen it done:

Pitfall 1: Prioritizing what’s understood

Product owners tend to be less technical, and not everyone can properly explain something technical in a way that conveys its value. The result is that items the product owner understands well are prioritized, leaving the other items on the side, which comes with a great long-term cost.

Pitfall 2: Going with instinct

I once heard the following about an item: Its value depends on how we feel that day. When people rely on pure gut feeling, the value of an item will vary depending on their emotions at the time. That means the decision of what will bring value to the product is more or less random, often resulting in leading the team to work on items that end up being pure waste.

Pitfall 3: Leaning into the noise

Some people even order their backlogs based on who complains the most! This merely encourages a culture in which whoever screams the loudest gets what they want.

So what works? There are many ways to take a more mathematical approach to giving value to items. What’s critical is to have an approach that allows the team to properly calculate the value of each item, regardless of what type of item it is. With clear guidelines, all three pitfalls can be avoided—and the decisions can be based on something more reliable.

How do you define the value of your backlog items?

by Christian Bisson

I’m always trying to find ways to help my project teams forge connections with one another. And one of the things I’m trying is to incorporate expressing gratitude. Along with helping teams bond, it can help improve team performance, too, especially with all the uncertainty of today’s workplace. An October 2020 poll by Monster, for example, found the overwhelming majority of workers believe that expressing gratitude at work helps ease stress and anxiety (97 percent) and receiving gratitude motivates their daily work (94 percent).

Here are a couple ways you can get your project team to practice gratitude:

Thank You Card Retrospective

First, provide blank thank you cards and pens to your entire team. Then, allow several minutes for everyone to fill out a few cards, writing who they want to thank on the team, what action they’re thanking the person for and the positive impact it had on them. A variation on this would involve asking everyone to write at least one card to someone outside the team and delivering it to them after the activity.

Note that it’s important for people to specify the exact action and impact that it had. This allows for meaningful gratitude to be shared, as opposed to generic answers like: “Thank you for your great work.” 

Kudos Retrospective

Start by writing four titles over over “boxes” where people will be able to add notes. The titles might be something like:

• Great job!
• Very happy!
• Congratulations!
• Thank you!

Then, tell everyone to think about latest sprint and write notes that align with those four boxes. Once that’s is done, have everyone take turns presenting what they wrote.

I’ve found this so effective that I now use it as part of all my retrospectives to close out on a positive note.

Simple activities like these can help people share gratitude they would most likely keep to themselves. These exercises, as well as recognizing the great work of your team, helps the team grow together and strive to continue doing outstanding work.

What activities have you used to practice gratitude among your team?