Changing with Agility

For all that Agile methodologies have been around for years--the Agile Manifesto itself dates from 2001--their adoption have been sporadic in reality. Many companies and their employees say that they are agile, or have the "Agile mindset." Saying it does not make it so. The hype is massive, but the results are mixed.

The endless discussions and seminars online about best practices in Agile, and the pitfalls in transitioning from the waterfall life cycle to scrum or another Agile methodology, are proof that changing how people work is not easy. We all find change challenging. 

Perhaps in a startup environment where most people are young with little experience of the waterfall life cycle, adopting agile is straightforward. However, in large companies, with employees who have 10-20 years' experience, changing to an agile mindset is painfully slow.

So what is the best way to transition from waterfall to agile in a software development team? I have been thinking about this topic lately. In my experience, every agile coach, scrum master, and development manager had their own definitions of what agile is. With hindsight there are things as an Agile coach that I would do differently given the chance. 

Change is slow

I was impatient at the slowness of change. For example, it was a no-brainer to me that the standup meetings could be short and focus on problems rather than regurgitating an unchanging status day after day. After all, everyone hates useless meetings. I backed off and left teams to it. Nonetheless, it took over 2 years before some teams moved away from the old waterfall status meeting to a more focused, short meeting: problems got addressed and fixed that day. Most importantly, it came as each team's own initiative: the change did not occur because agile coaches encouraged it.

Like most global companies, our development teams were distributed worldwide. In some cases, teams were too big (resulting in painfully long standup calls). Other teams were small, and had most of their team members in one location. Smaller teams still had problems of their own. Some scrum masters, who came from the traditional project management role, found it difficult to adapt to using new tools or short sprint intervals. 

Recommendation

Perhaps the best way to transition to agile is to pick one thing to change at a time. Think of it like a controlled experiment where effects can be determined because there is only one cause. Each team has to pick its own item to focus on. If the change doesn't work, try another solution to the same problem. Don't move on yet to the next problem. Their time will come.

What do you think?