I really don't care about Scrum. I really don't care about XP. I don't care about Agile RUP, or any other Agile process. But I do care about the agile practices embedded within these processes. I find little value in debating the advantages of XP over RUP. Of course, I've had the debate before, but mostly just to argue that it's not about the process, it's about the practice, the team and the culture. I don't care if you do Use Case Realizations. I care more about why you do them and what value they bring to your team. Agility is not a process, it is an ability. The ability to remain nimble and accommodate change. Why would we want to be anything but agile? Slow, brittle, and inept are certainly not defining characteristics of success. As in life, remaining agile requires care, attention, and nurturing.
Recently, there have been quite a few dialogs criticizing Agility. Here's one and here's another. In many respects, the criticism is deserved. The software industry takes the cool new buzzword and turns it into marketing propaganda. Now, people, teams, and organizations want the rest of the world to know they're the Next Big Thing. The original inspiration is lost, and eventually the idea is diluted to a point where nobody agrees on it's meaning anymore, and certainly nobody knows how to do it. Can you say software architecture? Now it's happening to Agile. But it doesn't have to. We shouldn't be surprised when this happens. A lot of money is made in crafting complex solutions. Can you say SOA? Soon we'll be reading about it's failures just as we've read about the failures of EJB and CORBA. But success with SOA is so little about technology, and so much about fundamental concepts such as granularity, coupling, and cohesion. But granularity isn't cool, and it cannot be commoditized. So we end up with Web Services, and begin living in a world of extenders, adapters, brokers, buses, appliances, registries, and repositories. What about REST? We tend to favor the cathedral over the bazaar. So it is too with Agile process. You are not agile because you are using an Agile process. You are not agile because you apply an agile practice. You are agile when you understand why a practice helps, and how the practice allows you to embrace change, speed delivery, reduce defects, or increase feedback. Why do you use Java? Why do you use Ruby? Why do you use objects? These are the simple questions with that are so difficult to answer. Yet you must be able to answer. Why do you want to use an Agile process? Why do you want to adopt the practice? What problem are you solving? Understanding allows you to make the necessary adjustments. In fact, any process when strictly adhered to is inherently not agile. Process constrains whereas agility empowers. So you have to know when to break the rules. And knowing when requires a deeper understanding. Process or practice may serve as your guide, but it cannot be law. The ability to remain agile requires reflection, dedication to self-improvement, discipline, and the right attitude. What's working? What is not working? What are the most significant pain points on the project? Do we have software quality issues? Is UI navigation cumbersome? Is system maintenance difficult? Slow response times? Agile development does not aim to prevent these things from happening. The goal of agile software development is helping you discover, and more easily resolve these issues early while they are less significant. Practices exist that help ease the pain, but the practice itself will not guarantee instant relief. Test-driven development does not prevent bugs. Test-driven development helps identify bugs while allowing your design to emerge. Continuous Integration does not prevent integration issues, it helps you discover integration problems earlier. Incremental delivery does not prevent you from delivering the wrong product, it allows you to recognize it before you do. And simply because you adopt one or all three of these agile practices does not necessarily mean you are agile. You must know why you are adopting them, and how they are going to help you. Take a moment and review the values of the Agile Manifesto and it's supporting principles. Can we argue that the items on the right are more important than those on the left? Agility is not a process. Agility is an ability. The ability to interact freely and effectively. The ability to work collaboratively. The ability to respond to change. The ability to deliver working software. If you currently do not have these abilities, agile practices will help. But first, you have to understand.
Comments () |
 |
|
|
|
Tags:
Click to add your tags...,
|
Blogs 
