For better or worse, the life of a consultant is filled with challenge, politics and a lot of learning. Working with a client that has difficulties solving a problem or has key “processes problems” that will always hinder success is part of the challenge. In recent years, I’ve seen a new trend in companies and government agencies: the “Agile, but…”.
What is the “Agile, but…”, exactly?
- We already tried agile, but [insert why you’re too complex, too special, or too unique]
- We want to do agile, but [insert one of many things you don’t want to change because it would require effort]
- We want to adopt agile (everywhere), but [insert management, production owners, other teams working with the development teams, or any other key stakeholders]
- We are agile, but we don’t do [insert any basic agile best practice or principle of the agile manifesto]
It seems more and more companies want to adopt agile, whether that’s a honest effort to work smarter or what I think is far more prevalent: wanting to be able to use a nice buzzword on proposals or talking to your clients/customers. It turns out when we look at those “Agile, but…” organizations, what we are really looking at is organizations that look to validate poor decisions or codify their adhoc (or lack of) process and slap some agile terms instead of actually dealing with changes their organization needs to make.
Planning Is Your Problem
Most companies have a few parallel projects running, a few more in the planning stage and a whole slew of adhoc tasks. Planning project tasks is easy – you maintain an up-to-date backlog, slowly working the list down in order of priority and conducting regular standup meetings with all the involved parties. Planning adhoc work, at first seems a little bit of an oxymoron. It’s not called adhoc for nothing. At my projects, it’s most commonly associated with “this is super-urgent and needs to be done now or the sky will fall.” Also known as “fire fighting”, “velocity killer” and even “soul-sucking utter chaos”. When adhoc work comes in, I often see teams disregard any planning they might have done, start carrying over stories sprint to sprint, work unsustainably week after week or stop planning all together because “what’s the purpose.”
The key problem here is a lack of the product owner to prioritize and stick to commitments, a lack of properly scoping your work, a lack of holding the product owner accountable (I’m looking at you Scrum Master), or sticking to a process that doesn’t work for your organization.
Here’s the dirty little secret: it’s all your fault. Yes, I’m speaking to you, [insert job]. Whether your a developer, scrum master or product owner the first three root causes has enough blame to go around. Accept you are part of the problem, do what you need to do to address those problems, and hold everyone else accountable. Developers are committing to doing work, but product owners are also committing to sticking to that scope and scrum masters are committing to protecting the team from scope changes.
As for improving your process, there are many ways to implement Agile successfully: change your process by trying kanban over sprints, reducing the duration of your sprint or committing to less work each sprint to anticipate issues.
You can’t do agile, but not plan accordingly.
Embracing Change Is Your Problem
Put your money where your mouth is. Most organizations that fail at agile or don’t see any changes are more often than not, not changing a thing. Take your long status meetings and call them “standups.” Call you project managers “Scrum Masters.” We don’t ever look at improving or talking about our problems, so why do we need a retrospective?! Can’t make your mind on requirements” Let’s call it “agile” so you don’t have to commit to anything. Lazy and don’t want to write documentation? Blame agile!
Change is hard, especially when it’s fundamentally how you do work; however, agile is all about embracing and adapting to change. Adopting change isn’t just about accepting that requirements will change, but embracing we may have to change to continually prove and reach technical excellence.
Honesty with each other and yourself is key to truly knowing if you and your organization are really capable of embracing any change. If you don’t want to spend the time, money, resources or effort to change: Do everyone else the favor, don’t call yourself agile. It’s not fair to those of us practicing it, or customers and clients who have the expectations of agility when you call yourself “agile.”
Embracing change is also about expanding our horizons, educating ourselves and growing. Many failing organizations send one person to agile training and expect them to be able to change the entire organization after an 8 hour training session. Don’t fall for that trap. Not investing enough in cultivating an enterprise understanding of how agile works or asking someone who’s never actually implemented agile to be able to do it for you will not be a path to success. If your organization won’t invest the time in you and others, maybe it’s not the organization for you.
Doing the same thing and expecting different results is the definition of crazy (or it will just drive you crazy).
You can’t do agile, but not embrace change.
Team Dynamics Are Your Problem
Ask any social scientist and they will tell you teams are strange, complex organisms. Agile teams are no exception. There are many dynamics that effect how teams act and interact. So what does all this have to do with agile? Simply stated, many “Agile, but…” organizations don’t do anything to foster a healthy team and often end up finding every possible way of creating and sustaining unhealthy teams.
The key to having a healthy motivated team is letting them be mostly autonomous. Regardless of your political party, you would probably find it hard to disagree that when a country invades another and sets up an unelected government to oversee the people, there are going to be problems. The same things happen for agile teams.
A key principle of agile is to allow teams to self-organize and self-manage. Micromanaging your team (and not allowing them to make mistakes and learn from them) is not helping you succeed. When big brother is always watching, interfering and telling you how to do everything teams will not be motivated, will never find their own cadence and won’t establish any team norms. Often, when someone forces the team to do things they find unnatural and feel they can not decide their own fate, team members will stop acting like a team and start looking out for themselves. As much as it may hurt in the short term, some time we have to let our teams make mistakes so they can learn from them. Failure is okay, not learning from a failure is not.
Going agile often involves giving up some of your control to your agile teams and trusting your people to deliver what they were hired for. Organizations should expect to change how they lead, manage and trust their teams. Project managers are not product owners or scrum masters, and many will never truly make the transition to leading by serving and dropping all the old project management tropes. Stop expecting them to.
