I’ve worked with a number of organizations lately who are either in the process of moving to an agile framework, or are thinking about doing so. These organizations face similar problems that they are attempting to solve, including late projects, large demand with limited capacity, lack of transparency to the business partners, just to name a few.

The transformation to agile is so much more than just training everyone in Scrum and hoping for the best. Scrum will start to identify many impediments that will need to be overcome in order for the organization to be truly successful. Scrum will help IT get better organized, plan better, improve their estimating and provide transparency into progress. But very quickly, these impediments will start to impede the team’s progress.

Let me take one common example: unless the organization already has robust automation testing in place, the Scrum team will very quickly become burdened with a large manual testing effort with each sprint. For the first few sprints, this may not be much of an issue, as the amount of stories completed will be relatively small. However, as Scrum is designed to do, the number of stories that have been completed grow, the amount of regression testing increases in parallel. If the product being worked on is already fairly mature, the regression testing effort may already be a significant one, especially without test automation. While there are various techniques that can be employed to help off-set the testing effort (think hardening sprints), the fact remains that the progress and success of the organization is hindered by the lack of automated testing. This is just one example, there are many others.

So what is to be done? As anyone who has attempted to implement things like automated testing, it’s not done overnight, and is actually a project unto itself.

I recently read a white paper that was first published in 2005 by the Scrum Alliance with Rally Software. In A CIO’s Playbook for Adopting the Scrum Method of Achieving Software Agility, the authors advocate that the CIO or another senior executive must operate as the “Organizational Scrummaster for continuous improvement”.   In the role as Organizational Scrummaster, the executive should work to identify and eliminate those organization impediments that will prevent the organization from succeeding with their transformation. The advice given is to name a product owner, create and prioritize the product backlog, and work through the backlog with a dedicated team following Scrum practices, just like any other Scrum team. The team works to remove the impediments, with the deliverables being the removal of the impediment. This continues as long as impediments exist.

As I read this, it struck me on just how much this made sense. In the spirit of transparency and honesty, an organization should take stock of how ready they are, and be honest with the work that needs to be done in order to be truly successful. And these are not small issues to work through, they require a commitment from the organization in resources (time, money and people) and the prioritization amongst all of the other competing demands for the same resources.

Please note I am definitely not saying is that IT is the only group that has to be ready for an agile transformation. They aren’t. Groups like PMOs and the business partners have their own challenges and transformations to make. And I hope to explore the readiness of those groups in future blog posts.