Debunking Six Misconceptions About Agile

This articles was first published in ProjectManagement.com

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. 
  1. 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. 
  1. 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.  

  1. 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.   
  1. 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. 
  1. 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?


(Pic Courtesy: Google Images)

0 comments: