Voices on Project Management

By Soma Bhattacharya

When it comes to working on larger projects that combine multiple teams spread across locations with a tight timeline, formalizing a triad is one of the easiest ways to streamline the process. While working with everyone is required in all projects, a triad can help you and your team irrespective of the role you play in the project.

The simplest things create the most impact. A triad involves bringing together the product, UX and development teams. You can change the composition of your triad based on your project and invite various functions to the core team.

Once that’s finalized, the triad is responsible for the project moving forward in a timely manner. It adds accountability at all levels and requires unanimous decision making, thus removing uncertainty and the multiple approvals that often lead to a back-and-forth dialogue.

When done at all levels, decision making in a triad takes care of strategic, tactical and operational issues for the project. To ensure that the triad is efficient at all levels (from planning to implementation), it can be created at multiple levels (from governance bodies to scrum teams). This ensures the right group is involved with making decisions.

Here are few ways to involve the triad throughout the release:

1. Release/Big Room planning: The goal is to ensure that the triad is available at all levels for planning. This ensures that all requirements and risks are covered and ready while we initiate the project and continue with planning. For quarterly planning, triad leadership is involved to ensure requirements for the upcoming quarter are discussed beforehand—and everyone comes ready with the work done for the teams to start pulling in features and stories for the quarter.
2. Discovery calls: These calls can help the triad come together to plan for the upcoming quarter. They can be attended by the leadership triad as well because it involves decision making on prioritizing and reviewing features like design and architecture.
3. Team meetings: Ensuring the triad is available at the team level keeps everyone onboard and prevents unwelcome surprises. This involves the scrum team-level triad and leads to better acceptance and demos because the triad is constantly working and reviewing things together—and not waiting on last-second feedback or blockers that need discussion or escalation. These include anything from design reviews to regular standups.
4. Retrospectives: These provide a good way to understand the pain points from everyone—and start working on them through the sprints, especially when you are constantly learning and innovating as a team (whether it’s the process or technology).

Of course, there are problems that can happen throughout, but the triad allows everyone not to just function as a team, but also feel like a team. And as we all know, happier teams can better resolve complex problems.

Do you think a triad can help your teams?

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 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 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:

1. Socialization: Working alone from home for more than a year under pressure and deadlines hasn’t been all cozy, so take the time to just catch up with each other. Listen and get to know each other. Simple games like this one can help you still feel like part of a team and that you aren’t working in silos: The scrum master as the facilitator can ask the team to write down “one act that makes you feel proud,” written anonymously on (virtual) sticky notes and tacked to the team board. During the standup, ask team members to identify who wrote which sticky note. It’s fun, and you get to know each other—especially any members that have joined most recently and never met the team face to face. It gives them a better idea of who everyone is, and knowing something personal will always make you work better around them. No one forgets a good story.
2. Intrigue: Look at the burndown chart, as this will allow conversations to start naturally on how things are working out for the team. This ensures there is no finger pointing and brings the group together. Decisions are made by the team based on the data and the general team trend. I find it far more effective than just the three questions. Another tip that always helps: Look at the buffer usage as a health check for the teams. Start with a 10% buffer in sprint estimation. Look at the burndown, and if you see the buffer is being completely utilized, find ways to uncover why and where the estimation went wrong, or if more tasks are being added later. Increase the buffer and continue to keep on checking on the team trend; you will either fix the leak or find the root cause.
3. The wrap: Support and positivity should always be the closing thoughts. Even if the team is behind schedule, team members should find ways to work together and use the learnings for better estimations and strategies next time. This is a marathon, not a sprint. Your behavior, bonding and team experiences matter in keeping the team together during these trying times.

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!