Agile software development has been around for a few years now and has started to gain hold even in large companies. I have used the Extreme Programming version of agile development in my last two companies and am currently using (and am a big fan of) software from Rally Development to manage this process at my current company. The tenets of agile development are mostly common sense and extend beyond the boundaries of managing the development effort. Here are a few:
- Keep in constant touch with the customer - make sure you are delivering a product with the highest value to your customer
- Integrate Often - Don't wait til the end of a long development cycle to see if everything hangs together, instead, constantly integrate to ensure that modules don't drift apart.
- Refactor - Is there a simpler and more elegant way you could have accomplished something? If so, change how it is done.
- KISS - you all know what the acronym stands for. Find the simplest way to deliver what the customer needs. Refactor later if new requirements emerge.
- Deliver often - At the end of each development iteration show the customer the product to get feedback as to whether you're on course or not.
- Pair programming - Two heads are better than one. At least on critical components of the code.
Here are the tenets applied to business:
- Keep in constant touch with the customer - developing a close relationship with the customer will: 1. keep them happy, 2. help you focus on what is important to the customer base, 3. build a good reference account that can be used for further pipeline development.
- Integrate Often - keep your departments in sync with one another. Have a unified goal for the company and make sure all departments are striving towards this goal. Proximity does wonders. I remember speaking to the CEO of Freshwater Software a few years back (bought by Mercury Interactive in 2001). She mixed up the seating arrangement in the company so that people built personal relationships across departments. This fostered inter-department communication and helped keep the company on track.
- Refactor - Is there a simpler and more elegant way you could have accomplished something? If so, change how it is done. This advice is good across the board. If licensing doesn't make sense for how your customers do business, change it.
- KISS - you all know what the acronym stands for. Find the simplest way to deliver what the customer needs. Refactor later if new requirements emerge.
- Deliver often - If something needs to change in the business, test market this with customers. This goes hand in hand with bullet one and further emphasizes a focus on customers. Remember, you're in business to deliver value to your customers.
- Pair programming - Two heads are better than one. At least on critical decisions in the company.
5 comments:
Tim:
Great article. I like to take it one step further though and focus on creating "agile software", not just being agile while developing software.
bf
Tim,
I definitely agree with your thoughts on software development, however I would add that there is a balance on the "Deliver Often" component. As someone who is currently providing software QA testing for some software that is still very much alpha code, sharing this with a customer might create an inaccurate impression of how the software will perform once it is more mature. I have seen a few (not many) companies deliver too frequently to potential customers and end up scaring them away because the process was too painful...
Bill,
I agree with you that it would be great to deliver agile software. The best translation we've experienced in the past however is highly configurable software. Most of the time highly configurable software comes with it's own price of either paying an "expert" to configure the software or spending the time to become an expert. We need to figure out how software can adapt itself to the needs of the user without getting in the way. Sort of a software of solipsism, it would adapt to become centered on each individual user or use. Perhaps the n-tiered architecture could be infused with a smart agent layer that would adapt and tailor the software with each use. Building out an infrastructure that can be all things to all people certainly goes against the agile development methodology, since you tend to over design or make things so abstract they become unusable. I think the idea is a great one and It will be interesting to follow your progress at MyST.
Can you name any successful agile software projects that have shipped? From my experience I'm inclined to believe that it only "works" for services, not actual products that are delivered. From my experience I also cannot name a single profitable company that uses agile exclusively to manufacture software.
I'm inclined to think that it's just snake oil to help some people make money by "coaching," selling books and speaking at conferences. On the surface it does provide exposure in to the team and process but there is no real world data, that I'm aware of, that shows increased quality, customer happiness (measured by profits?) or increased development speed. I suspect it might also provide for a great way to launch smaller companies and get them rolling with a strong team but when the product starts to matter there will be a painful transition from agile to actual software engineering.
Agile dev is certainly great for startup companies. This is where I've used it with much success. I think it is tough for mature enterprise product dev teams to adopt agile methodologies mainly due to process momentum. The agile process is so much different than what companies are used to that the only adoption is on small break away projects from the core. There is also a dirth of tools in the agile process to support a large dev effort. In fact, Rally is the only one I've seen worth using thus far.
Post a Comment