Recovering from Agile Guilt
“We didn’t estimate our points correctly, again…”
“We didn’t finish this sprint’s work…”
“We didn’t leave enough time for QA…”
“Bugs are getting in the way of our feature work…”
“That’s not a feature, it’s a chore…”
“There wasn’t enough detail in the story…”
“The scrum board isn’t up to date…”
“Is it done, or is it done done?”
“Maybe we need to define done done?”
Do any of those sound familiar? You might hear phrases like this again and again in your Agile product teams. It can quickly get demoralizing to be bomarded with these issues that can become a drain on productivity. But what to do when you face these situations?
Agile processes can often create unattainable goals and expectations, which leads to a disappointment when they aren’t met. It’s time to stop setting the expectations, but its also time to stop reacting so negatively to being effected by external factors beyond your control.
I’ve seen this process actually makes people feel bad. Morale dips when you miss another sprint. Hours are spent discussing definitions of words I could have sworn already had clear definitions for centuries. The process itself becomes the very drain it was designed to fix.
Waterfall isn’t the answer, the true spirit of agile is the answer. To change process, throw it out, rethink it when it stops working is the answer. But because it’s one more thing to manage, we often don’t take the time to fix the root of the problem causing all this angst.
Lowercase ‘a’ agile
I’m a fan of agile with a lowercase ‘a’ . Keeping yourself nimble as new details emerge (as they always do) while you work allows your team to adapt quickly, and more importantly be used to the concept of adapting quickly. You can never anticipate the nuances of every project, but you can anticipate your reaction. Being welcome to the surprises, expecting them and embracing them, helps you stay… well, you know… agile.
The important thing to note that this thinking shouldn’t just be applied to the dev work you do, but also the process as a whole. Simply changing a sprint from 1 week to 2 doesn’t solve issues.
Retrospectives are important
If you can look back at what you did, you can’t learn from it. Review your sprints, ask what went well, and what went poorly. Learn from the good, adjust, and try something new. Don’t get in a habit of treating retros as just another meeting that can be put off — stick to them and make them a critical part of your product development cycle.
Get comfortable with change
The single biggest remedy I have found for Agile guilt is getting comfortable with the inevitability of change. Rather than treating it as something that should be avoided, embrace it instead. Aren’t we in this line of work for the challenge? The problems that we need to solve? Staying agile lets us do what we do best.
There’s no easy path to change, and it can be uncomfortable but it is possible. If you’re caught in familiar loops and cycles that simply don’t feel good, see what you can change and adjust. Get to the root of the issue and start there.
