Agile adoption isn’t an all or nothing proposition, as I have heard it described. At one point in my Agile adoption I wouldn’t have even believed it. If I went go into a new client that said they were an Agile shop and they didn’t practice all of the XP practices, I would feel they weren’t being honest. I would talk to them about doing more with their Agile and I always got the feedback, “It is better than it was before”. Having come from a strict (in the good sense) XP shop, the idea of being better but not, in my opinion complete, was appalling. It just wasn’t right, as the saying goes you need to “be all you can be. Right?
Well, as it turns out, I was wrong. Sometimes being all you can be is adopting as many good software development practices as you can and using those to get you as far as you can go with them. I have come to appreciate that a complete set of practices, whether from XP or Scrum or any software development practices just isn’t always possible and trying to force it practices that an organization isn’t ready to adopt does more harm than good. I have also learned that early in an organizations Agile adoption some practices have more bang for the buck and some are enablers for future practices.
Now when I go into a client that is struggling with Agile or wants to improve their ability to deliver I tend to focus on a few initial practices. So what do I focus on? Things that help get the house in order and setup future, smaller increment changes.
The very first think I work with clients on is planning. Almost always I start with release planning. At a thematic level, what functionality do you want to deliver to your users? And when? Order matters in release planning. Many organizations are very poor at planning. They don’t know how to make order out of the chaos of their requirements and schedules. It is often as much a communication challenge as it is a scheduling challenge. If you can’t communicate your plans to the stakeholders, including the development staff, you can’t get good plans or even buy-in from the stakeholders.
Release planning leads to iteration planning. Iteration planning starts a break downs in the work plan for the large themes of a release. Breaking this down feel right to the people evolved in planning and approving plans. It is what they want anyway. The value of iterations plans, beyond helping you decide what functionality you develop in an iteration, is it starts the practice of short feedback cycles. You plan and execute iteration 1 and have a UAT. This UAT allows you to get and give feedback. The feedback you get is how the stakeholders like the progress so far. The feedback you give, which is even more critical at this stage, is how well you did against plan. Whether your plan is accurate, inaccurate, off a little, off a lot, you know right away. You can start building the expectations about your team and it’s capability. Knowing how fast you are going and where you are going with the opportunity to course correct on the way is the first step in making your team Agile and living with the Agile values of quick feedback (both ways) and honest about your progress.
One of things you have no doubt noticed is that I haven’t said anything about coding or technical practices. Don’t worry, they are important and I will in the future. I believe that by setting the course with planning to begin with you will get a lot more value from the other Agile practices. Short, iterative, flexible, changing plans are the first step in a journey to Agile Software Development.
