Voices on Project Management

By Lynda Bourne

A couple of days ago, I received a survey from PMI asking about portfolio management. There’s nothing unusual about PMI undertaking a survey, but the types of project management approaches mentioned for the projects in the portfolio gave me cause for concern. The three choices offered were Agile, Waterfall and Other.

My response was ”Other”—the  portfolios I have direct experience with involve heavy engineering. Here is my perspective on the options offered by PMI:

Agile: A well-defined flexible process, based on the Agile Manifesto, applicable to software development and a wide range of other “soft projects” such as business change.

Waterfall: A five-stage software development methodology from the 1970s focused on designing a product (based on requirements) before starting development. The waterfall methodology is still used in some software development projects, but has never been applied to other types of projects.

Other: The vast majority of projects in the construction, engineering, oil & gas, defense, and aerospace industries based on the approaches described in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Sixth Edition.

These “other” projects generally have three phases:

1. A definition phase undertaken by the client organization to define the capabilities of the product being developed
2. A procurement phase where the client selects a delivery agent for the development of the product
3. A delivery phase where the delivery agent builds and delivers the product

The design of the product (ship, building, rocket, etc.) may be undertaken in full or in part during any one of the three phases. A minimum level of design is required to initiate procurement, but for simple buildings and civil engineering projects, it is not unusual for a complete design and specification to be provided by the client.

The procurement phase may be a simple pricing exercise, or a complex and phased design process (sometimes even involving the production of working prototypes), with selection being based on the capabilities of the design produced by the successful tenderer. In many projects, a significant amount of detailed design is still required during the delivery phase, including shop drawings produced by subcontractors and suppliers.

Similarly, the procurement arrangements vary widely. The client may choose to enter into some form of alliance or partnership with the preferred delivery agent based on shared risk and profits, or the client may choose a hard-dollar contract based on a fixed price to deliver a fixed scope, or some other setup. There are multiple forms of contract arrangement.

The only certainties are that the typical project approaches used for the vast majority of “other” projects bear no resemblance to the waterfall approach, and this “other” classification includes more than two-thirds of the world’s projects by value.

So, my questions are:

1. Has “waterfall” become a shorthand term for any project that is not agile? And if this is the case, what does the new “waterfall” terminology mean?
2. Is there a better term for this very wide grouping of projects that generally follows the concepts in the PMBOK® Guide (as it was up to the Sixth Edition)?

How should different types of project management be described? Your thoughts and ideas are welcome.

By Soma Bhattacharya

The phrase “quiet quitting” is all over the internet as the trend has gained in popularity over the last few years of the pandemic. The one thing you need to confront the temptation: motivation.

Motivation for today’s generation is something that’s in sync with purpose and autonomy. In one of his Instagram posts, Adam Grant—an organizational psychologist and best-selling author—says this about quiet quitting: “Doing (the) bare minimum is a common response to bull$#!* jobs, abusive bosses and low pay.”

While it may be true for some, for others it can be lack of alignment in seeing the purpose they serve within the organization. So, we might need to fix the flawed system and also highlight what’s in place.

In any agile team, most of the ceremonies always carry an inherent meaning (at least that’s what I have always stressed). Release planning or “big room planning” is about communicating the purpose, the big picture and how each team or individual comes together to contribute.

If done correctly, teams are happy to have the knowledge and prepare for it. It also allows team members to raise concerns and flex their mastery at what they are going to work for the next three months. It’s designed for social communication, bringing in multiple teams in one room or platform.

Encouraging teams to participate and normalize conflicts is a healthy practice—as long as it’s moderated and everyone is looking at the end goal. Conflicts can foster higher creativity and better solutions within teams. That in turn that will also engage individuals and negate the “quitting mentality.”

A small team brings in autonomy to a great extent and allows everyone to feel empowered, like they’re playing their part. The whole concept of limited size in scrum teams means better communication, stronger bonds and faster decision making. The bonhomie improves team harmony and creates its own culture, one that can only come together with openness and trust.

A simple initiative like buddying up, mentoring or pair programming is a common practice. Giving everyone a way to relate and connect to the big picture and to a team can also result in better learning, and an enhanced social life at work—leading to a sense of belonging, which is essential for growth and individual engagement.

Any team or organization that practices any of the above will tell you than when team participation is higher, so is the interest in coming back to the office—and that a better quality of work is a byproduct.

Often in any agile teams, we forget why we chose agile. Building a culture of trust, openness and empowerment can benefit everyone. Choosing wisely to see what needs to be changed or adapted can allow for better vision and a stronger roadmap for the team—not just for the product, but for team building. Choosing the right team imbibes a great attitude.

We must all be aware that with every generation, social change and work environments go through major shifts. So, what worked five years ago might not be the right environment post-pandemic. So, blaming the system or organizations for certain practices might not be the right choice. Understanding a team and what it wants out of work is equally important to confronting negativity. Maybe consider that change is a refreshing thing—not just for newcomers, but for management as well.

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?