Agile is about surfacing pain. It’s not about roses, perfume, and happy candlelight dinners together. Traditional project management methodologies made it easy to sweep the pain under the carpet, lying about how you were doing up until the end of the project, when you hoped everything would just go away emerged to haunt or kill you. Traditional project management methodologies are all about denial. Why do predictive methodology plans fail so often? The release plan correctly goes out of alignment with the reality. A task overruns, a task underruns, a dependency holds up delivery. Sometimes people re-plan, but the effort mean most just ignore it, burying technical debt to stay on track, ignoring opportunities to take on more work, lying to their stakeholders about where they really are. Agile uses an adaptive approach, because that allows you to surface the truth about when and where things are failing, or where there are opportunites that could be exploited.
Being agile hurts. It exposes you before your peers with all your insecurities, wounds, failures and weaknesses. But accepting those problems lets you take steps to fix them.
So if you think you are an agile project and you are not constantly surfacing nasty, miserable pain, then you might not be doing it right.
What are generally called agile development processes are best practices for fixing the pain that agile can surface, without creating more pain in turn. Now Scrum gets a lot of ragging for not including engineering processes. But I think that the point here though is that heart of Agile is about the surfacing of those problems, not the fixing of them. We want to fix them, and you may want to go to your XP, Crystal or Scrum library and pull out remedies for your pain from those cupboards. You might even want to vaccinate your project from them. These engineering processes are in important part of your methodology, but they are a response to the pain that agile surfaces. You do continuous integration because you don’t want the pain of integrating code streams after days of effort, or taking several days to do the build.
The key to agile is that you are bringing down the pain. Because then you can deal with it.
I suspect that the reason a lot of Scrum implementations seem to be failing is because the attitude of those using them is to hide the pain, not to surface it. That is self-defeating, but emerges because the stakeholders of the organization become scared when they see so much pain early in a project’s lifecycle. They are not used to that level of honesty. So they think something must be wrong. In fact something is terribly right. However, you have to set expectations to understand that you intend to bring down the pain so that you won’t be finding it all when its too late or too expensive to do anything about it.
Everything always done , every sprint always 100%, no defects? These are often lies we tell ourselves to defer the day of reckoning. Maybe you’re getting it right, but don’t lie to make it look like success, because it isn’t.
