Thinking inside the Agile Box

Pretend you are taking a week long trip with a friend. You start packing and end up with a couple of large suitcases. Your friend arrives with one medium suitcase. You start thinking, "What are they thinking? They don't have enough clothes to last the week." You arrive to your destination. When you start unpacking, your friend's clothes are all nicely folded and no wrinkles. Your clothes look like a mess and will need to be ironed. Your friend is able to put things into drawers quickly as well as the bathroom items. You have to go through your bag and it takes you longer to find things and put them in their place. However, your friend has less clothes than you. As the week progresses, you begin to see that your friend has found ways to reuse what they wear - different shirts with the same pants - yet still appear like they aren't worn. You on the other hand, find that at the end of the trip you had clothes that you didn't wear, but had to carry around. Now you start thinking, "My friend has a better way. I've got to learn from them for the next trip!"

Was the friend always this organized? Probably not, they probably learned by somebody else. Experienced travelers have tricks on how to properly fold clothes and how to maximize every spaces in a suitcase. They have also learned what's "good enough" and not to take more than they need. Even if they end up needing fresh clothes, they will end up using a local cleaners or wash their own clothes instead of taking too much. They have learned how to best put clothes and other accessories together to maximize their use.

As my development staff is asked to reduce cycle times through iterative development using Agile best practices, their initial reaction is "That sounds all good, but we have found things to take weeks or months and that won't work with this approach." They are correct, it won't. But, just because you have done things a certain way doesn't mean that it is the ONLY way to do things. We have learned how to do things as individuals. We will now need to do those things together as a team. We have learned that each person plays a particular role and has their own specialization. We will now need to remove those specializations and have people wear multiple hats. We have learned to think about everything up front is much detail. We will now need to learn to do just enough for now and think about details when it is appropriate later. We have learned to break the work and requirements down just enough to make sense for a 6-8 month project, we will now need to refine that work to make sense for 2-4 week iterations. We have learned a way to deliver software after 8 months, we need a way to deliver that same software in a portion of that time and possibly in weeks instead of months. We need systems that get tested and built at least every day if not several times a day, the systems we have used cannot handle that load.

What's great about Agile is that it isn't just "theory" anymore, people have found it to work and improve the flexibility and responsiveness of the team to provide working solutions to customers. We can tap into these "experienced travelers" and figure out how they have done it a different and better way. It just seems strange to us because we have learned how to do things differently, not necessarily better. However, if you think that Agile is just about doing things faster you will miss the point. Agile is about doing things differently in order to deliver working software more effectively. That means we need to relearn how to build, maintain and support software under this new way. Relearn skills, tools, knowledge, processes and essentially how you do your jobs differently.

You might have thought you were a great traveler and packed accordingly, until you realized that there is a better way. However, you can't just copy the better way like it was out of a cookbook. You must understand why this experienced traveler didn't to make the change. Then, you must understand how he made the change work for them. Then, you must make the changes work for yourself. Same with Agile, you don't just adopt a methodology and away you go. You must understand the principles behind it, then determine what set of best practices fit your organization. When people ask us if we are using XP or Scrum, I respond with "Yes". "Which one?", they ask. "Both" I respond. There are practices within each that we have adopted to support Agile principles. There are other practices that we have come up with that perhaps nobody else is using. That's ok, as long as we are staying true to the goals of Agile development. I will say that it has required EVERY person to think about their jobs differently. In some cases, much differently. In the end, it required each person to "think inside a different box". An Agile Box!