Agile Requires Change
I spend a decent amount of time pointing out that every Agile Journey will look at least a little different. I appreciate frameworks such as Scrum. Having a defined process to follow generally makes the initial start of a transition much easier.
In the last post I pointed out that change has to start somewhere. In fact, I would state there is no Agile Journey without change. Being Agile is deeply rooted in responding to change. It’s one of the main values from the value pairs. An Agile journey with no change is as useful as a cancelled cruise is fun.
Most of the time change is something that doesn’t come easy to an organization. One reason is that it often doesn’t seem as if change is really needed. Another is that true Agile often requires significant change to organizational structure or values. The interesting part here is that even when upper management pushes some kind of Agile the organization as a larger entity will often resist change.
The problem in all of this is that an Agile Journey requires change by definition. If someone is pushing for a move to Agile the assumption is that a need for some change has been identified. At the very least someone realized that there might be opportunities for improvement.
That brings us to what kind of change we should start with. If I was brought to a team and given the directive to only change one thing I would start with a Retrospective Process. There is a nuance here. I wouldn’t start with a Retrospective Meeting, that’s just one piece. I would start with the Retrospective Process as a whole.
The Retrospective starts with doing something. Next a meeting is held to see how things went while doing something. In that meeting good and bad are identified. From that meeting items to change for next time something gets done are proposed. Finally, something is done slightly different, and that is the first step of the next Retrospective.
The astute reader has already realized this, but in starting with the retrospective process I have also instituted iterations without explicitly calling them as such. This isn’t a goal of starting with retrospectives, just a cool side benefit.
The goal was to create a process that enables change. Once the team and organization have bought into the idea that process can be changed on a regular schedule the rest of the Agile Journey becomes much easier. As long as they are resisting change the Agile Journey is going to struggle to move at all.
How have you helped your organization change for the best?
