Just to give you guys a little context, I’ve been working with Dennis to untangle this story we’re trying to tell for over a year. The words we use are so overloaded, the concepts we use get interpreted so many different ways, and our individual perspectives… the lenses through which we interpret the world around us… are so diverse. Telling the story is tough.
Day in and day out I see, hear, and read about so many people trying to make sense of agile. They are deeply interested and trying to apply these ideas in their particular context, but struggling. We are trying to get this untangled in hopes that we can isolate the variables, and start taking a hard look at the pieces and parts that really make this all work.
My post this morning about adoption and transformation was significant for me. The first slice I want to take is along this boundary. Fortunately, as I’ve reread over my past 5 posts, they are largely focused on the adoption side of the story. Some of the risks and assumptions we talked about have to do transformation, but it’s largely about selecting practices that are in alignment with your interest in making fundamental organizational changes to your company.
If you think about these 5 posts in sequence… what we are really talking about is 5 step plan for agile adoption: understanding your vision, identifying hidden assumptions, assessing your known risks, setting ground rules around how to choose the practices you want to apply, and then the palette of tools as your disposal for adopting agile and introducing change into your organization.
Understanding Your Vision – This post addressed 12 of the attributes of a well functioning agile teams. The point was made (via Twitter I think) that these are common attributes of all team based delivery. I think I agree. I just want to know what success looks like independent of the practices that I choose. At some point in time, I am going to have to make trade-offs to deal with some unknown… I’ve got to know what I’m aiming toward, independent of specific practice guidance.
Identifying Hidden Assumption – Peter Senge might call these mental models. What are the underlying assumptions we make about the world around us? What are we bringing to the table that are going to have an impact on our success or failure? In the case of agile, and agile practices, what is the fundamental world-view these approaches were drawn against, what are the fundamental truths, and what can be modified for our particular context.
Assessing Your Known Risks – We’ve got our known unknowns and our unknown unknowns. We’ll have to deal with both, but we need start with our likely impediments. We want to compare our vision for the future, coupled with our underlying assumptions, and our understanding of the world around us, to begin crafting strategies that are most likely to lead to success. Agile makes everything about building software visible and explicit, we want everything to be visible and explicit with our agile adoption program.
Determining Your Decision Criteria – I’m not sure we’ve got the right language here. What I’m trying to describe are almost design constraints for your agile adoption program. This might be one place where we’ve got adoption and transformation too tangled up in the language. I used the word thinking tools in the post because I want these 12 items to be the lens through which you choose what practices to adopt, and also for how you adopt them.
Tools You’ll Need To Be Successful – Finally, we have the palette of tools we think will be valuable to apply, again… not only to your end state agile adoption, but also to how you go about executing the adoption program. These include our standard base of accepted agile practices, but also heavier more traditional approaches. We’l pull from other disciplines like manufacturing, management, personal development, and change management
Defining Your Agile Adoption Strategy – The next step would be defining your agile adoption strategy… but, there are still some things missing, still some unanswered questions. Are you just going to adopt agile practices, or are you going to try to transform your organization in the process? It will make a difference in the practices you’ll adopt and how much you have to adapt the practices to work in your environment. Are you going to align your organization to make using agile easy, or are you going to leave things the way they are and make changes to mitigate the risk of standing still.
The next steps for us here are to refactor some of these sections, to make sure they are telling only the agile adoption side of the story right now. I think there will be another side to the story that has to do exclusively with transformation. This side will have to do more with business capabilities and organizational design. It will be about making decisions about how your organization is structured when we are done. After we know our top-down intent, we can begin to merge our understanding of the adoption approach to craft our holy grail… the enterprise agile adoption AND transformation strategy.
It’s going to require both sides of the equation working together to do this incrementally, safely, and pragmatically. Stay tuned.