4 Areas to Look When Agile Isn't Working In Your Organization
You’ve implemented Agile into your organization and hired professionals with Agile experience on their résumé to back it up. Yet, something is still not right. The gains that Agile promised don’t seem to be coming to fruition. Delivery times aren’t faster than they were before. There is no significant increase in quality. Your customers don’t seem any more satisfied than they were before. People don’t seem energized about it. Projects are turning red, and emergencies keep you up late at night. What gives?
Agile is no longer the new kid on the block. It’s been around for some time, and almost every organization has at least experimented with it in some form. The truth is, becoming a more Agile organization is not something that happens overnight. It takes hard work and fortitude at all levels to be successful.
I’ve talked to many executives that sense a lull and just don’t know what to do about it. Team members feel it but can’t put their fingers on what exactly is going wrong. There is mounting strife in the organization, and you are falling back on your old ways. It’s comfortable, but how do you bust through and keep moving forward toward achievement? Here are a few things for you to consider:
Pay Attention to What Is Slowing Your Teams Down
Being an Agile manager is a philosophical shift from command and control to enablement. As a coach, a conversation I like to facilitate when talking with managers is to uncover what impediments might be slowing the organization collectively. From this discussion, there is a call to arms to actionably drive removing the impediments and to listen carefully as new obstacles emerge.
Some examples of impediments you may have:
- Teams have trouble getting software into production because of down or upstream dependencies.
- The tools being used are inadequate.
- There is a lot of technical debt but no time allotted to fix it.
- There are unnecessary pressures from management on teams.
- Certain team members are not fulfilling their role.
Impediment removal is the bread and butter of a Scrum Master, and they should be empowered to remove them. However, management is often enlisted to help resolve tough impediments. Managers typically have more political capital and can use that political capital as an impediment breaking weapon.
Be careful; you cannot resolve impediments unless you know they exist. It is vital that you create an environment where impediments can be exposed, discussed, and collaboratively resolved. Transparency across an organization is key, and it should be expected at every level. An organization is halting agility when they accept the norm and work around issues because that’s the way it’s always been.
Concentrate On Metrics That Really Matter
Your organization is filled with knowledge workers trying to solve complex problems. A big mistake I often see is the implementation of metrics that attempt to measure their productivity. It is impossible to measure the productivity of a knowledge worker or team of knowledge workers without sacrificing transparency and creativity in your organization.
What’s a knowledge worker? https://hbr.org/2010/04/are-all-employees-knowledge-wo.html
Agile metrics are divided into two categories with two very different purposes. Be sure that you are using them as they were intended:
- Delivery Metrics – Metrics such as unit test code coverage, velocity, burn down charts, and defect count are very important. Their purpose is to drive empiricism in self-organizing teams, so they can have a measure for how they might improve. If used as carrot and stick metrics (a means of rewarding or punishing), teams will game them to avoid the stick. You will be operating by the false pretense that things are going the way you want. What you sacrifice is a reduction in the willingness of an individual or team in being transparent about what is truly happening on the ground. Afford the teams the ability to own these metrics and not live in fear of the stick if something goes awry; something will always go awry when working in a complex work domain.
- Value Metrics – Metrics such as user adoption, lead time, and customer satisfaction are how we understand the value of what we have delivered. These are the responsibility of a Product Owner to capture and share with stakeholders. Often, I don’t see any value-based metrics implemented. How can a Product Owner accurately assess value if they can’t measure what is happening in production? Many symptoms might be causing this such as an unempowered Product Owner, a lack of tools, or the failure to incrementally release software into production. Whatever the reason, act fast and start understanding what your value actually is.
As a reference to Agile metrics please check into Scrum.org’s Evidence-Based Management Framework.
Relentlessly Drive People to Learn
Have you budgeted annual training for all individuals? If yes, are people taking advantage of it? I one time heard an executive say: “but if we give them training than they’ll just leave.” Yikes!
You want people that are lifetime learners (and human nature tells me that everybody is innately wired this way, or we’d never have gotten out of the stone ages). Individual knowledge growth is pivotal to the success of you becoming a more Agile organization. Sending people to Scrum training to kick things off is a start, but that is the tip of the iceberg in a learning journey. Buy them books, let them attend conferences, go to new courses, and build in time for them to experiment. It’s important, and people need a platform for that to happen.
Implement An Organizational Change Framework
There are many organizational change frameworks to discuss and debate. I am partial to Evidence-Based Change because it uses Scrum to deliver increments of change and has metrics associated with it. Frameworks aside, it is essential to have a guiding coalition (or several of them).
The construct of your change team(s) must consider all levels of an organization. If it is solely executives, you will miss out on the perspective of what’s happening on the ground. If you have delegated this to mid-level managers or team members, then the team(s) won’t have the authority necessary to bring the change to life. Ensure you have a cross-functional team(s) capable of devising and delivering change into the organization.
The change team(s) should be afforded the opportunity to holistically view an organization and work to solve tough problems. One could debate that change teams should never cease to exist to ensure an organization is constantly striving to change as the world changes around them.
By implementing an organizational change framework, driving your teams to learn and grow, focusing on the metrics that matter and openly assessing the problems that slow your team down, you will be on your way to turning around your Agile experience and delivering value to your customers. Being successful in these areas requires adoption at all levels of your organization. True agility is only achieved when an organization has embraced uncertainty and built a collection of teams that can respond.