By Grant Beck, Agile Solutions Practice Director

Recently I was tasked with the challenge of converting two project teams to an Agile Scrum software delivery model. Our client’s management team had become more aware of the benefits of Agile and was anxious to put it into practice. I was somewhat surprised at the initial protests from a few individuals on the teams to working ‘Agile’. By definition, Agile means ‘quick and well-coordinated in movement’ or ‘marked by an ability to think quickly’. Who would be opposed to such a change?

Change is stressful and often unwelcome, especially when imposed upon longtime, established employees by an ‘outside’ consultant – we had significant potential for conflict! Success depends in part on salesmanship, part on political positioning, part on psychology, and in no small part on patience. The process we went through was both successful and rewarding, and I’d like to share a few a key points from my experience. While these points are in the context of transitioning to Agile Scrum, they can easily be generalized to organizational change overall.

Beware of “Best Practices”

One of the terms commonly used in business is ‘best practices’. Best practices are wonderful guidelines, but too often they are seen as the holy grail of the way we work. We rarely question a best practice. It is, after all, ‘best’! Therein lays the danger. Generally in business, and specifically in Agile, the desire is for continuous improvement. When we stop trying to get better we get left behind, we miss opportunity, and we stagnate. Best practices should continually evolve if they are to remain best practices.

Don’t codify the way things should always be done. Circumstances change, businesses change, and technologies change. Acknowledge the value that exists in current processes, but challenge yourself and the team to continually reassess. When you hear the term ‘best practice’, we always ask: “How can we improve our approach?” Best practices are general guidelines but they need to change based on the needs of a situation/project.

Think Big

Consider how the transition to Agile affects the whole business – not just IT. It is important to ‘socialize’ and sell this methodology to all levels of the business. A purely top-down or bottom-up approach will not be sufficient to enact a change. The functional team needs to understand their role in helping to define user stories. Management needs to understand the importance of persistently communicating down and reinforcing the expectation of the new work habits. Seek out individuals in all areas who are ‘on-board’ with the change and enlist them in perpetuating change throughout the organization. Show employees how the model works for them. Get people excited!

Be Willing to Adjust (it is Agile, after all)

Enacting change isn’t about cramming a methodology down someone’s throat. Don’t lose sight of the big picture – remember to pick your battles. It won’t do you any good to get into a heated debate about something like whether the team should use an online tool to track progress on a burn-down chart versus using a white board. Let that one go and keep the big picture in mind.

Negotiate. If someone on the team is insistent on using a certain document or form, be flexible enough to accept this if it means getting that person on board with the process.

Try enacting change in different ways. Maybe a big flashy PowerPoint demonstration about the benefits of Agile will help – maybe meeting with a team member one on one. Take some action and observe the response. Then try something different. Experiment with differing levels of pressure. Be creative and observant, adjusting your approach as necessary.

Be Respectful and Listen

I remember one meeting where we had introduced some of the Agile concepts to the delivery team and I knew there would be some very vocal protests about the changes we were hoping to implement. I also knew that this situation would likely turn to a ‘feeding frenzy’ of negativity and confrontation once the ball got rolling. I told myself before the meeting to expect this and to, under all circumstances, keep my mouth shut. It was important to ‘weather the storm’ and let the team express their frustration and ‘get it all out’ without my being defensive. It also allowed me the opportunity to assess each individual’s objections and begin thinking about how to continue the dialog once the fervor died down.

In Conclusion…

A common mistake made by consultants is to walk into a situation where they know of one way to implement a new methodology without right-sizing to a client’s needs, potentially ignoring existing processes or organizational structure. As consultants, we are guests in someone else’s house. Making an effort to listen to and empathize with the client will go a long way in establishing a productive dialog. As consultants, we may feel that our job is to come in and immediately apply our expertise to a situation when sometimes it is best to sit back and listen, discovering the best path forward.

Enacting organizational change and affecting the way a business works is difficult and challenging. I’ve learned a lot along the way and am pleased to see that change is possible with even with the most ingrained of processes and intransigent of clients. Plaster Group employees, by virtue of their caliber and experience, are well positioned to help customers adopt new and improved ways of doing things. The depth of our proficiency and breadth of our knowledge base allows us to leverage that experience to help our clients navigate to better processes and sounder solutions.