- Companies where the employees don’t think they have problems
- Companies where employees don’t feel that they are empowered to solve problems
- Companies where employees are rewarded for problem solving
Jeff basically said that you need to be in category C above to have the most chance of success with an agile transformation. It’s the organization’s job to value problem solving and make it part of the everyday culture. Scrum’s role is not to solve problems but to bring necessary issues to the forefront so they can be addressed. If you are not a problem-solving organization, you won’t know how to manage the many problems you will uncover with Scrum. Scrum is hard, it’s disruptive, and you’ll need to burn down team and organizational impediments along the way. In addition, you may need to make changes with regard to certain people and technologies that are incapable of adapting to a completely new way of thinking and working. If you don’t want to do all the work, it is probably best to look at embracing a different approach to software development and innovation.
4. Think big and go all in.
This one is also big and signals difficult and thankless days ahead. I talk to many transformation teams all over the world (I’ve traveled more than 250,000 miles during the past eighteen months or so), and it’s amazing how many times I hear myself saying, “You’re not alone; there is a community behind you.”
Randy Mott, the ex-CIO at HP who transformed that organization through efficiency and cost-cutting, said about IT transformation, “Choosing is losing.” What he means is that an incremental approach to IT transformation fails. This is a hard pill to swallow for most people, but the concept is fairly simple: Go big, or don’t do it at all.
I agree. Change everything at once and attack it from all sides (technology, process, and people) or, as Mott warns, “risk complete failure. The parts you don't do will undermine the parts you do.” The entire organization needs to change simultaneously, from sales and marketing to human resources and your project team technology stack. Also, while it’s OK to think big and have goals, remember that individuals need focus as well. They don’t need to have the end-term goal change every thirty to sixty days. So, define your big, strategic objects and let your organization know that change is coming in a big way!
5. Find a financial sponsor.
There is always an expense in new people, processes, and technology. Make sure your funding source is solid before you run all over town wanting to do this or that. Without money and a sponsor, you may be wasting your time.
6. Hire an experienced internal or external champion.
Find someone who has experience leading agile transformations and who can instill confidence throughout the organization to avoid excessive misfires. Large, global, distributed development is very complex. There are seemingly millions of documents online to help, but having someone in the room who knows what he or she is talking about provides you with a huge advantage toward success. Do some digging, research, and interviewing—being thorough will pay off.
7. Baseline, measure, and champion.
Lay out your goals ahead of time. The teleology around measuring the success of agile transformations has been debated on the Yahoo! and Google Scrum user groups for years, but in the end, you will need to decide what success means to your organization (e.g., less employee turnover, more productivity, more customers, more stable product releases).






