Since 2003, I’ve been involved with Scrum in some shape or form. In the beginning, it was something Victor, my brother, and Michael James, a self-proclaimed recovering software architect, were kicking around as a better way to manage customer requirements and team morale. Victor and Michael were looking at how physical spaces should be designed for optimum developer productivity, so we tried the Scrum framework on one project, then two, then three, and we were all hooked on it. We ran around telling people about Scrum, and during down cycles (i.e., when we didn’t have enough work to do), we started building our flagship project management tool, ScrumWorks.

Throughout my career, I have had the great opportunity to work with software development organizations of all types and sizes. It is with their help and inspiration that I have outlined seven practical tips to begin the journey of the agile transformation.

As I write this article, I am at the Tokyo Scrum Gathering. I’ve visited Asia five or six times in 2011. It’s clear that some organizations based in this region are in need of change and transformation in the form of more aggressive innovation. Take, for example, the mobile phone industry. As leaders like Apple and Google emerge, many Southeast Asia companies (e.g., Sony, LG, Samsung, Sharp, and Fujitsu) must figure out how they fit into a new puzzle. Will they try to partner, be competitors, or sack entire divisions? Adding to those competitive issues are the realities of global currency fluctuations, emerging Federal Transit Administration export regulations, financial debt crisis in Europe, and a sluggish consumer economy. It’s enough to keep a CEO up all night slugging bottles of antacid!

The solution may be in the next great product launch. Innovation should drive consumer demand up, which is a good thing for companies that rely heavily on American and European consumers to purchase what they’ve built. So, where does innovation come from and how do we get there? Well, that’s not an easy question to answer, but building the next great product may require organizations to embrace agility as they implement techniques from Scrum and extreme programming as a means to become more innovative in the following ways: increasing the rate of feedback loops, separating command and control, empowering teams to make decisions, assigning a product owner, and improving consistency by putting quality into each sprint.

To spur innovation through software agility, I have outlined seven strategies for you to consider as your organization moves to harness the full benefits of agile software development.

1. Knowing where you want to be (your end-goal) should be the starting point for your agile transformation.
As Steven Covey points out, “Begin with the end in mind.” In other words, Scrum is a means to an end; the end may be innovation or increasing employee morale. Start with a strategic goal that may be tied to an organizational initiative.

2. Know what you’re getting yourself into.
Scrum is hard and disruptive on purpose. A team-empowered environment requires a huge paradigm shift. Scrum is a light framework and process that is not to be taken lightly. A high degree of motivation is required to track, record, and update other team members on accomplishments every day during stand-up meetings. Want more inspiration? Read what Ken Schwaber, one of the pioneers of Scrum, has to say on this topic.

3. Become a learning organization.
This is big. Most Scrum trainers agree that “learning organizations” excel at Scrum. Why? Because learning organizations believe process, people, and technology improvements are a means to innovation, increased employee morale, etc. A learning organization is one that continuously focuses on self-improvement and relentlessly seeks out opportunities to improve. Learning organizations value improvement as a means to self-reflection in order to create and promote productivity and profitability. At Scrum Days Munich 2010, Jeff Sutherland, one of the inventors of Scrum, said there are three types of companies in this world (paraphrased here):

1. Companies where the employees don’t think they have problems
2. Companies where employees don’t feel that they are empowered to solve problems
3. 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).

During our early days at Danube, we had the good fortune to catch the attention of executives within the Washington State government IT community, and before we knew it, we were consulting on “best practices” for agile and Scrum processes. I really wish I knew then what I know now! Since that time, we have all grown and learned so much through trial and error and industry collaboration. Michael is now a very well-known figure, speaker, and Scrum trainer in the agile community, and Victor and I have since sold our company to CollabNet, which is where we both work today. We’ve seen many attempts at agile transformations and have been involved in advising many companies down the path toward agile success. While I could write an entire book on the seven steps listed above, I hope this article gets you thinking about the up-front steps you can take to harness the value and benefits of agile-based methods.