Voices on Project Management

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?