Building Team Synergy and Resilience
Human Aspects of PM,
Categories: Agile, Benefits Realization, Best Practices, Career Help, Change Management, Complexity, digital transformation, Facilitation, Human Aspects of PM, Human Resources, Innovation, Leadership, Lessons Learned, Mentoring, PMOs, Portfolio Management, Program Management, Roundtable, Stakeholder, Strategy, Talent Management, Teams
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:
PWC’s Global Crisis Survey identified three key lessons that businesses can adopt for long-term resilience:
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:
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.
Agile Adoption Is Up…So Why Do Teams Hate It?
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 15th 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?
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:
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.
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:
Agreeing on these can easily take a few hours depending on the size of the team and the maturity of good practices.
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:
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.
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?
3 Ways to Challenge the Agile Norm
By Soma Bhattacharya
Never fear challenging the norm.
A standup seems like the norm for any agile team, part of the identity associated with being agile. As many of us all now work remotely, it seems that the right way to start the day is by attending the standup and getting the status items, questioning team members—and dealing with interruptions from multiple stakeholders.
Whether you like it or not, there’s no one rule for getting the standup done. It’s about connecting with the team and being there for each other without ruthless questioning.
So, if you are not answering the standard three questions (What have you completed? What will you do next? What is getting in your way?), what else can you do? Here are what I call the three acts:
Changing the norms to ensure things are working for you—and keeping it that way—is agile. No one shoe fits all, so find what your team needs and try it out!