As agility becomes more widely practiced, more people and organizations are giving it a serious look and we are seeing more of what Geoffrey Moore (Crossing the Chasm) would call the Early Majority starting down the agile adoption path. It is important that this new group of adopters has the right aim in mind.
Agility in of itself is not the goal. I may want to be more physically fit, but setting that as a goal is not likely to make it so. Setting a goal to ride 50 or 100 miles in the upcoming charity bike ride event is more likely to be achieved. An agile adoption needs to start with some set of improvement goals. Want to improve the alignment between your business and technology groups? How about getting your products to market faster? Perhaps being more predictable in delivering your projects? Getting a better return for your projects? Maybe improving the morale of your teams and retaining your current employees longer? Launching an agile adoption to "become agile" is not likely to produce much in the way of desirable results. First we should set expectations. What are we trying to improve? What will we achieve by that improvement? How will we know we are making progress?
Similarly, the agile innocent tend to think agility only in terms of practices. They shouldn't. Agile adoption is not about swapping out practice set X for practice set Y. Agility is first about culture. It is a way of thinking; a mindset. I like to think of agility as a set principles and values coupled with any number of practice sets. An agile adoption is an organizational level change; we expect to change how people work and interact. It is traumatic and we need to be certain that the improvement gains we anticipate are worth the trauma.
These then are the first two steps on our stairway to agility; identifying organizational improvement goals and recognizing that we are changing more about behavior than we are about practices.
Where to next? Agile Principles. Agile teams may choose to work in different ways using different practices, but they share and respect a common set of principles, as such these:
Engage the business directly. We need to clearly understand the business objectives and priorities that we expect to be addressed by the project work we take on. Projects should result in making the business bigger, better or more efficient. Which is this project doing? How is it doing that? Why is that important? The delivery team needs a business stakeholder directly involved to shepherd that knowledge and keep the team focused on achieving the business goal.
Embrace changing priorities. The business is not static. It will respond to changing market conditions, initiatives of its competitors, changing needs of key customers and a multitude of other things. This is part of succeeding in business and delivery teams need to embrace and respond to these changing priorities. To not do so is to invite the debacle of delivering outcomes of little or no value.
Create self-organizing teams that are jointly accountable for solving business problems. Too frequently we engage teams to complete a predefined set of work by an arbitrary date. When that work fails to address the business issue as expected, it is viewed as a team failure but it is not. It is a failure of how the team was engaged. An agile team is a cross functional team armed with the knowledge needed to understand the business problem and empowered to self-organize and self-manage to complete the work needed to solve it.
Deliver incrementally to validate the progress toward actually solving the business problem. When a project gets off track and fails to address the business need, it does not get off track all at once or at the end of the project. Those signs were there all along and either were not recognized or were simply not addressed. Decompose the larger problem into smaller problems. Solve the smaller problem and allow the business to validate the solution moves us closer to the broader goal. If it does not, then we are in a good position to do something about it quickly, while it is still relatively inexpensive to do so.
Shorten the feedback loop to incorporate learning when we learn it. Traditionally lessons learned are not designed to help the current project, but a future project. The problem with that is the future project is doing different work, with a different goal, with a different team. Lessons learned from a past project are simply deemed as not applicable, whether or not they really are. Let's get feedback frequently, learn from it today and help today's project.
The next step in the stairway is an agile adoption plan. Just what will we do to meet the improvement objectives we defined. I like new agile teams to set goals in three areas.
First, which agile practices will we adopt? Scrum? Kanban? eXtreme Programming? How fully we will initially adopt those practices?
Second, let's look at the current technical and delivery practices. Do any of these need to change in order to support the improvement goals that we set?
Third and finally, what organizational support does this effort need? A new agile team is likely going to operate outside of at least some of the normal processes and constraints. Organizationally, it needs to be free to do that.
Now we learn by doing. We start using the agile practices we agreed to. We make the changes in technical practices that we thought were needed. We ensure that the organization adequately supports the team. We experiment to see what works and what feels right. Along the way we stop for a moment to reflect on what we are doing and the results we are producing. We look for ways to get better and adapt our processes and practices accordingly.
Finally the last step is to realize that there is no last step in an agile adoption. Agile organizations continually evolve. They are on a journey that never ends. Experiment, reflect, adapt. It is how we become agile today, and stay agile tomorrow.
