Lately, a lot of folks have been sounding the alarm about Agile done wrong. I can’t blame them, and having talked to people eager to adopt Agile but lacking the discipline to successfully hold daily stand-ups as their chosen first step, it’s certainly a message that needs to be heard.
Let me tell you a secret. I’m not sure if the practices I use are Agile or not. I’m not particularly interested in whether retrospectives come from Scrum or XP, I just care that they are useful for my team. Do I practice Agile? I think so, but if you tell me otherwise, I’ll say, “Oh, ok,” and go back to what I’m doing. As long as what we’re doing works right now for our team, we’ll do it, whatever its name.
Let me put it plainly: Stop asking “Are we doing Agile?” and start asking “Is what we’re doing working?” and “How can we improve it?”
One of the core principles of Agile is that it is a living process, hence “Responding to change over following a plan” and “Individuals and interactions over processes and tools” from the Agile Manifesto. We keep it alive by making it sort of behavior-driven instead of practice-driven. See, Agile can do for software development what well-written user stories do for feature requests: take the emphasis off of the “things” and place them onto the desired behaviors. As with user stories, changing the focus to the behaviors gives you the freedom to find the best way to achieve what you’re really after instead of unnecessarily constraining you to one approach.
So the way I see it, the goal isn’t to do regular retrospectives, it’s to improve the way the team works, promote team bonding, or get an idea of current morale. Maybe it’s all of those, maybe it’s none. But if we don’t have a good reason to do retrospectives, we won’t do them. Or if we find a more effective way to realize the behavior we’re after, we’ll do that instead.
As another example, a lot of folks know me as a sort of Test-Driven Development zealot. But if you’re on my team and you have a better way to make sure the codebase 1.) only does what it has to and nothing else and 2.) inspires confidence to do necessary refactorings, I’ll say, “Great, let’s do that.” Please don’t do TDD for TDD’s sake —TDD done poorly can be worse than not doing it at all.
I encourage you to not become complacent with your process. Always look for ways to improve it. Identify the weaknesses and try to fix them. Learn from the strengths. The goal isn’t to come up with The Process that works for your team, the goal is to put in place the best process that works for your team right now. Change your process as project conditions change. Know what you are changing and why. A lot of smart people have come up with a lot of practices that have worked for their teams. Use them, but know why. Remove them if they aren’t working for you, but know why and know how you will alternatively achieve that project behavior. Keep your process alive!
This is what Agile means to me. What does it mean to you?