Voices on Project Management

By Soma Bhattacharya

In discussions I’ve heard within Scrum teams over the years, three common concerns often come up:
1. “We need longer sprints.”
2. “We always have spillovers and can’t seem to fix them.”
3. “Ad hoc tasks always mess up sprint planning.”

I think this often originates from general discomfort people have when problems surface; but for me,
dealing with things like this is exactly what agile is all about. So, here’s an alternative way to think
about these three problems:
1. Sprint durations: It’s common knowledge that with the change of a sprint duration, the team
capacity changes as well. So, when teams complain about needing longer sprints to finish the
work, it’s clearly due to a lack of planning (and having no time to cover up the lack of it). So
instead of bringing up what needs to be ready during planning, teams will usually take it all on
because someone has told them to. This can be easily resolved by the team simply looking at
its velocity trend and recognizing how much work can be taken and delivered.

2. Spillovers: These are not the villain here. What matters most is discovering why the
spillovers are happening. Sometimes when ad hoc works comes in, instead of going for a
tradeoff (because capacity is limited), teams just take it all on and then end up with a
spillover. Oftentimes, waiting for a dependency with other teams or external partners messes
things up. Teams refrain from speaking even if they see risks because everyone is waiting for
someone else to raise the flag. This is where team empowerment and decision making can
be improved upon.

3. Unplanned work: Sprint reviews can be a good platform to talk about unplanned work
seeping in. The best way to bring that up can be to see what the percentage of unplanned
work is within a team’s capacity. A simple way to track this is by creating a user story and
keep adding to its unplanned work, along with the time spent. So, during a sprint review, the
spillovers or tradeoffs are easy to talk about—and the “blame” (if any) doesn’t always fall on
the team. Everyone gets the needed clarity.

Being agile is very different from just being part of standups. The main issue is that leadership often
does not sponsor the agile teams—and in the process there’s more confusion. The team is forced to
attend agile ceremonies, but sees no benefits because it is still forced to work on things that weren’t in
the plan. Bringing up blockers (and how much time is spent on them) or costs will allow a simple
decision to be made: Do you want to continue being agile? And if “yes,” how much decision making is
the team empowered to make?

What common issues have you encountered on your Scrum teams, and how have you dealt with
them?

By Peter Tarhanidis, PhD

As the pandemic stretches on, work-from-home programs continue to keep teams working virtually. During this time, we have performed courageously to deliver our strategic and business outcomes. Here I will share a select review of advice from industry experts as they explore how to build a post-pandemic response strategy.

According to McKinsey (2022), organizations have pivoted to deliver sustainable and inclusive growth toward building a better world. And Harvard Business Review (2020) notes that all types of companies have navigated the pandemic by pivoting their business models in the short term to survive—becoming more resilient in the long term.

Yet not all pivots generated an improved business outcome. Three trends in particular can help ensure a successful pivot:

1. Align the pivot to a long-term trend driven by the pandemic
2. Extend the firm’s existing capabilities, further solidifying the strategic plan
3. Sustain profitability, which preserves and enhances the brand’s value to the customer

PWC’s Global Crisis Survey identified three key lessons that businesses can adopt for long-term resilience:

1. Plan and prepare for inevitable disruption by establishing a crisis team
2. Integrate teams and cross-company competencies to enable effective responses
3. Build resilience governance into the organization’s culture

An opportunity, therefore, exists to consider how to prepare your team’s competence in driving synergy and resilience in order to lead post-pandemic growth strategies—and simultaneously pivot from those same strategies.

Here is a shortlist of what leaders can do to prepare for a post-pandemic recovery and support an organization:

1. Develop mental agility to pivot among key strategies and deliver business outcomes as key shifts and business challenges arise
2. Allow the process of learning to take effect across key leadership levels
3. Integrate PMI and agile frameworks to ensure flexible planning activities
4. Employ data analytics to support key insights in customer and marketplace forecasts
5. Clarify the governance of key plans and what event would trigger a decisive strategic pivot
6. Develop talent to migrate into new areas of company strategies and projects
7. Gather teams in person in order to create synergy and move from “norm” to “perform”

In the end, the teams that are ready to execute and can pivot as necessary will be ready for the post-pandemic competitive environment.

Let me know if you have uncovered additional successful strategies—or any pitfalls to avoid—in building team synergy and resilience.

References

1. https://www.mckinsey.com/business-functions/risk-and-resilience/our-insights/covid-19-implications-for-business
2. https://hbr.org/2020/07/how-businesses-have-successfully-pivoted-during-the-pandemic
3. https://www.pwc.com/gx/en/issues/crisis-solutions/covid-19.html

By Soma Bhattacharya

Sometimes I read an article where someone mentions that “agile is dead,” or that it doesn’t work anymore. I have to pause and think where this comes from. Honestly, I don’t know. What I do know is that agile never said it would work for everyone.

Most teams and organizations working in agile either step into it by accident or want to try the “trend” to figure out it works for them, then continue working with it. I reached out to my friends who are certified trainers in agile, and they mentioned that they are busier than ever. That world has opened up because trainings are now online, which means you don’t have to travel anymore to take classes or get certified. In addition, the 15^th Annual State of Agile Report notes a growth in agile adoption from 37% in 2020 to 86% in 2021. So it looks like agile is still very much alive.

Certification or not, agile is always the most natural way of working. At least, that’s what I think. Why?

1. You work in tight-knit teams, keep distractions limited and get the work done.
2. You are transparent in your communication because the team is small and a safe place for anyone to open up.
3. You plan but always adapt and adjust the work because you are flexible.
4. You demonstrate the work, and the feedback is used to course correct

So, what’s not to like about it? Not everyone agrees; in reality, things can seem more challenging for some.

Here’s why teams don’t want to go agile:

1. Lack of empowerment and support of teams: Decisions made by teams are later turned down by managers. I have been in situations where someone from the team pulled me aside and said, “All that planning was for nothing, we were just told ‘forget the process, and this is what you have to deliver by end of the month.’”
2. Reluctance to plan for sprints and releases because everything will change later anyway: Being flexible and agile is often used as a workaround for a lack of getting your homework done before coming to the meetings.
3. Forced to deliver even when things are out of team capacity: Burnout is real, and there’s a reason capacity planning is in place. So, going out of your way to enforce more doesn’t really help in the long term (think bad quality and reworks).
4. The influencer of the team is always involved in estimations and decisions: Planning poker is barely implemented because one person makes the call. Whatever happened to coming to conclusions about the story points and the estimations? New team members are never encouraged to talk about their side of estimation…so yeah, no prizes for guessing why estimations never work.
5. Why speak up when it’s already decided? Team culture always influences team behavior. So, imagine new members when they see that everything is decided. It tells them that it’s not required to speak up to air their opinions.
6. The same old retrospectives…and no one does anything about it: A team stops doing retros because similar points keep coming up without any action items being attached to them; the solutions aren’t there, and the problems remain.
7. The stand-ups literally never end: Teams have multiple discussions where more members join than are required—and it goes on for more than an hour. (Oh, by the way: Just because you do stand-ups doesn’t mean you’re agile.)
8. I get appraised based on what I did, not how I worked as part of the team: Time is wasted. The appraisal system that rewards individuals and not teams is controversial. Imagine if team performance didn’t matter…what should you focus on?
9. We might say we’re an agile team—but in reality, we don’t follow agile principles: Everyone calls us agile, but as a team we only do what we are told—and no, we are not self-organizing because no one empowered us to do that.
10. Everyone uses agile as an excuse to not do the prep or work because everything will be done “just in time”: Instead of excuses, just make it work. Try, experiment, fail and rebuild your agile culture again.

I don’t know about your experiences, but from what I have seen, agile is usually welcomed by the teams—the problems creep in later, as it’s not something management buys into (and it’s not just me: the Annual State of Agile Report also mentions challenges in adoption like “not enough leadership participation” or “inadequate management support and sponsorship”).

I know those who are happy being agile are aligned at all levels and are working on being a better team every day. It’s all about individuals and interactions over processes and tools, right?

What have you heard from colleagues about why agile isn’t always embraced?

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?