9 Things to Avoid When Being Agile-EN

Agile is extremely flexible and gives every organization and team a lot of leeway as to how they achieve the guiding principles and values. Trial and error is a key component of agile. It encourages taking risks, making mistakes, learning, and then adjusting quickly.

BUT now that agile is well into its teens, I can tell you there are some things that have been attempted again and again… and should be avoided if you don’t want to slip and fall down.

1. Don’t make the focus of agile all about going faster.

Understand that going faster can be a byproduct of several key agile practices, but you don’t get the full benefits of agile immediately. Many teams practice all the Scrum ceremonies and begin moving quicker than they ever did under Waterfall, but soon come to realize that they are simply building the wrong things faster. This is an example where the focus is on a high velocity and a lot of story points, not the real need… business value and value management.

2. Don’t give someone the title of an Agile Product Owner without giving them any guidance or framework.

Doing this won’t allow for full acknowledgement of the significant, hands-on role of the product owner. Even the most seasoned product owners who are familiar with defining a product vision, roadmap, and software solutions may still not fully understand context, constraints, stakeholder personas, perspective, business rules, non-function, and transitional requirements. Helping them enhance their skills and build up the right product council will save the product owner a lot of frustration.

Check out our Product Owner Fundamentals for Business Value course to help provide guidance.

3. Don’t change someone’s title to Scrum Master and expect the same status reports they provided as project managers.

Scrum Masters are shepherds of the agile values. That said, how they report status in agile should be more than just about velocity, burn down, dates, and deadlines. Scrum Masters should be held accountable for whether the team is “healthy” and they should foster the agile values of collaboration, delivering value, communication, and responding to change. The organization’s KPIs should drive the business value that the solutions are based on. There should be a system for tracking business value and providing continuous progress metrics.

4. Don’t say you’re empowering teams but expect them to not make mistakes or decisions.

If you’re a manager and your people are afraid of making mistakes, then you’re encouraging them to be order takers. They won’t be innovative, and they will stick to the status quo. The purpose of hiring ‘knowledge workers’ is so that they can be critical thinkers, decision makers, and change agents. If you want to get the best from your team, let them make some mistakes to stretch and grow their skills. Let them know that not every decision that comes from the top will be perfect. Empower them to ask the right questions and take risks.

5. Don’t pretend that unplanned work and administrative tasks won’t affect the velocity and capacity of the team.

In the ideal environment, the whole agile team is focused on the same work items identified and agreed upon by the team, and only those work items are being worked on by the team members for the current sprint. However, if for any reason team members are regularly and consistently expected to do work outside of the sprint, it cannot just be ignored. If your environment doesn’t allow for dedicated resources, those additional work items should be reflected in the velocity. The burn down chart, the missed sprint goals and the reduced capacity of the velocity should provide transparency to how the resources are allocated.

6. Don’t reward and recognize individuals or treat some as heroes, but then say the focus is on team collaboration.

You can put a group of people together, but that doesn’t make them a team. Teams should be rewarded and recognized as a group. Having a healthy team means your resources are engaged, enabled, empowered, and energized. On a team, all roles are equally important. Rewards should be focused on healthy team behaviors that result in successful outcomes. Results-driven recognition and individual rewards may encourage them to be successful for a time, but ultimately it will foster resentment, frustration, lack of respect, negative attitudes, silos, and a finger-pointing atmosphere. This will cause the team’s performance to deteriorate. A healthy team is the key to quality, sustained, and repeatable successful outcomes.

7. Don’t expect agile to provide significant change but only be willing to make minimum adjustments to your current approach.

Changing your status meetings from sitting down to standing up, putting lines and stickies on a white board, using poker cards at your planning meetings, and buying some tools that help manage stories and story points are things that give you the outward appearance of doing agile. What about your mindset, your behavior, your beliefs, and your experiences? Are they being challenged to ensure you are being agile? How are you challenging your organization’s mindset and behaviors to achieve value management over requirements management?

8. Don’t expect to make significant change without slowing down the workload to accommodate the learning curve.

So, on the one hand, your company is willing to change all the rules and fully embrace agile. They want to build healthy teams, create relationships built on trust, have bottom up communications, be innovative, take risks, fail fast, delight the customer, and embrace breakthrough organizational changes. On the other hand, leadership wants the deadlines agreed upon before the agile transformation not to be impacted. It’s like asking everyone else to embrace change but management gets to remain rigid. Just like when you’re driving and come to a sharp curve (i.e. an organizational transformation), you must slow down and then accelerate after the curve.

9. Don’t act as if the Scope – Budget – Schedule (triple constraints) rules don’t apply to agile.

“The triangle” is flipped upside down in agile. Agile is predicated on the time and cost being fixed and the scope being the only variable. Agile demands that we minimize features (minimum feature set) and minimize the solution (minimum viable product). So the next time the team addresses the objectives and delivers a solution – and there are stories that are leftover to throw away – management needs to pop the champagne and say, “Job well done! Let’s turn off our computers and go home early – for a change!”

We shared these top 9 things based on our experiences and from working with clients across many industries that are in various stages of agile transformation. By no means is this list a comprehensive one; I’m sure we’ve left some things off of it. We would love to hear your lessons learned and revelations you’ve had during your agile transformation that can help others avoid the same mistakes. Help us grow our list by adding yours in the comment section. Don’t be embarrassed to share. It’s all in the spirit of agile to reflect and adapt.

Thank you,

Jacqueline