Voices on Project Management

Years ago, when I first heard of agile making waves, I was curious enough to pay for a class out of my own pocket to learn more. 

By the end of the two-day session, I knew I wanted to be associated with agile. It wasn’t just its merits that convinced me—it was the basic philosophy of trusting another being, of being open to communication and most of all, respecting another’s opinion. It seemed humane.

In the mad rush of work, all of the above are often sidelined. There’s no time for niceties, no time to respect another opinion; there’s only the ambition to prove another wrong. 

It’s miserable. 

Agile teaches us to be open, trustworthy and make mistakes. Failure isn’t the end of the road; risk-taking and experimentation are supported and bonhomie is encouraged. 

My Experiments With Agile

As I started working as an agile coach, I brought in the humane side of work. I helped my teams to stop finger-pointing and instead, really talk during standups. I tried to liven up the mood by asking team members about the last book they read or movie they watched, and I learned the name of the scrum master’s kid. This helped the team get to know each other as humans. 

I planned games and drew on whiteboards so team members could match the hobby with the individual who practiced it. It was hilarious. Interest grew, not in agile but in knowing each other and building better relationships with team members. 

We celebrated birthdays, we talked about failure, trust and anything that would bring out even the introverts and encourage them to join discussions. Everyone’s opinion mattered. The right complexity point during estimations didn’t matter, as long as everyone was talking and participating. 

And our work wasn’t virtual anymore. I would move a story card to completion, draw to celebrate the completion of a goal and use the white board to keep the team motivated with quotes, scribbles and doodles. It got everyone involved. 

Managers soon joined the sessions, sometimes just listening when they were uncomfortable. It allowed team members to be vocal and to think for themselves. Everyone was involved—not because that’s how it should be done, but because it takes time to build that vibe and tribe. 

Why Agile Works

Agile isn’t for measuring KPIs or bringing in ROI. But those results happen, because the team comes together and enjoys working with each other. 

Agile has been written about over and over again, from why it works to why it’s a failing fad. People rarely see the fact that agile has made many organizations humane again. The best way to understand agile is to think about working in a secure, comfortable environment with people you trust. 

In 2013, Rosabeth Moss Kanter published an article in the Harvard Business Review about how the happiest people seek out the most complex problems. It just makes sense to keep individuals and the team happy at work. 

It can be intimidating to turn around a team struggling with bad quality, low productivity and minimum engagement. But the best fix has always been to get team members to feel engaged, and that their views are heard and their opinion respected. It’s always about people. Once you get that right, the rest is easier. 

I have always had a positive experience with agile. When everybody comes together and believes in it, I have seen change happen. However, the most rewarding experience for me has always been that associates in an organization become humane again. They care about their colleagues, they speak face to face and they handle difficult discussions better. 

What about you? If your organization has embraced agile, what results have you seen?

My interest in project management started long ago. When I was a kid my family would visit Kolkata, where my grandparents lived, on holidays. It was a busy city and a big change for someone growing up in a small town.

As much as I loved all the shops and eateries, the main attraction was the metro. Opened in 1984, it was the first of its kind in India. I had heard many stories about how you would travel underground. The thrill of my first ride as a kid was unimaginable. 

It was amazing to see how the metro touched the lives of so many. It made travel so much easier and faster. The impact that a project could have stuck with me.

After I’d grown up and was a newbie stepping into the world of project management, I wanted my own project—something where I would be in charge. 

One morning my prayers were answered, and I was offered an opportunity. That said, the work on this project was negligible, it would last just a few weeks and the money wasn’t much. 

Even so, I jumped at the chance. I worked on the project with a small team of mostly fresh grads, and we made sure every detail was covered. We checked and double-checked everything. We communicated with the stakeholder regularly and started sending her updates and snippets of the work as it was happening. This was way before agile was a norm. 

She came back with feedback and changes, and we were quick enough to get it back to her ahead of schedule. 

The work kept on coming, and this tiny project slowly became one that everyone started to notice. It was the project that established me as a project manager. 

I knew I wanted to work on something that would make everyone’s lives easier. I knew that a project could create an impact. In a lot of ways that first ride on the metro had sealed my basic philosophy in my life journey and career. 

I want to hear from you. What was the first project you remember as a kid?

For those of us in the project management community, agile is a familiar term. But despite its prominence, it’s often misunderstood. 

All too often, teams and organizations focus on the wrong things or are misinformed. And eventually, agile takes the blame. 

Here are six common misconceptions that can lead to an anti-agile mindset:

1. It is all about the tool. Any tool that’s hailed as what makes agile works is still just a tool. Yes, with distributed teams it helps to have a tool where everyone has access to project details and data. However, when introducing your team to agile, your training shouldn’t be tool-centric. I prefer teams to see and understand how agile really works—the simple use of sticky notes or a whiteboard does the trick. The move to a tool can and will happen eventually, and when it occurs, you don’t have to send multiple follow-ups to ensure the team is populating the data. 

2. Agile is changing requirements in the middle of the sprint. While agile is known for inspecting and adapting, changes can get out of control. I hear teams talking about changes happening so often that they can barely focus on the work, or they are constantly handling changes. When the pressure to change a requirement is happening too often within a sprint and ends up becoming a norm in the team, the product managers or sponsors need to jump in to determine what needs to be built. Otherwise, team members tend not to focus on the work because they know no matter what they do today, everything will change tomorrow.

3. Agile doesn’t use data. The idea that data isn’t tracked is wrong. In fact, there are many ways to look at data. However, we also have to be mindful so data isn’t just being used for the sake of data, leading teams to start bluffing around it.  

4. Agile doesn’t offer predictability. You’ll often hear that there was better predictability before—and now nothing works. Sponsors always need to know the timeline. And yes, this can be done in agile. In fact, using and tracking the right data can bring in the predictability your team needs. The velocity metric will let you know how much a team can handle in a sprint. So, whether it’s a burndown chart, sprint or release planning, there are multiple ways to get the required predictability and commit accordingly.   

5. Agile doesn’t offer time to think. I recently was in a session about thought leadership and someone mentioned agile being the greatest blocker because there was no time to think. Interpretation, I believe, is the biggest problem of all. You can still block a certain percentage of your team’s capacity or yours to try out new ideas, participate in hackathons or learn a new skill that adds advantage to your product or service. If you are not speaking up about the problems, you should. And if flexibility isn’t allowed, that’s because of the team culture, not the process. 

6. Agile is all about micromanagement. One of the funniest misconceptions I’ve heard is that an organization moved to agile because leadership wanted everything to be micromanaged. Individuals didn’t understand that team capacity and complexity (as measured in story points) aren’t ways to track team members. Instead, they are tools to help team members make the right commitments during their sprints, commitments they can actually keep and deliver. In this case, a lack of explanation about why the organization moved toward agile triggered multiple miscommunications. So, the responsibility lies with management and the agile coach to take the time to explain the move to agile. Because instead of micromanagement, agile is really about the opposite. It, in fact, allows teams to be empowered, to be able to self organize, to be vocal and to get the work done. 

These are six misconceptions I’ve seen about agile. What are the common ones you’ve encountered?