IT Conversations has an interview (mp3 41min) with Alistair Cockburn (pronounced koh-bern) that makes for a great listen. Doug Kaye hosts a great conversation with Alistair, discussing several topics, including the four principles of Agile development. Alistair explains that the wording is precise and intentional, and represents four sets of preferences, not four absolutes.
Ten Essential Practices of Continuous Integration
Martin Fowler has identified the key process elements of making Continuous Integration work. You could even argue that they are the elements that define Continuous Integration (done correctly). We include his list and our thoughts below:
Foundation Series: Continuous Integration
Continuous Integration is the software development and quality process where all team members merge their code and verifies it frequently – at least daily. This verification project includes both an automated build process and automated testing. The main benefits of continuous integration come from risk-reduction and cost-reduction.
The Agile Dragon
When Alan Cooper and Kent Beck debated the benefits of eXtreme Programming versus Interaction Design, they disagreed on a lot of things. One thing they agreed on is that Agile processes are designed to minimize the impact of changing requirements. Cooper believes that it makes more sense to minimize future change by understanding the requirements better up front. Beck believes that the requirements can not be understood by the team until something is delivered. Beck’s point is that the customer doesn’t understand the requirements until he has something in his hands. We’ve shown how this is both a strength and a weakness for Agile in the real world. In The Hobbit, the dragon Smaug was missing a scale on his belly, that made him vulnerable. Agile processes have a similar weak spot.
Agile’s Biggest Strength is Agile’s Biggest Weakness
Agile works because it is designed to help teams adapt to changes in direction. Agile is designed to minimize the pain of changing requirements. Agile proponents believe the premise that requirements will change and no amount of upfront planning will impact that. They believe that the requirements simply do not exist until after something has been built. Agile processes save a lot of time by not doing big upfront requirements gathering or design work. They also don’t involve big up-front planning. They do small planning work. And they do it again and again, throughout the project. This works because they minimize wasted planning effort.
Getting agile – should we?
Should we adopt an agile process for our team? Methods and Tools has posted a two part article titled Adopting an Agile Method. In thier article, they explore five areas of consideration. We provide our thoughts on each area. Five areas to consider (from the article) Our organization’s culture Our […]
Gartner research on Agile Requirements Definition and Management (RDM)
Gartner has a research report available for $95, titled Agile Requirements Definition and Management Will Benefit Application Development (report #G00126310 Apr 2005). The report is 7 pages long and makes an interesting read. Gartner makes a set of predictions for 2009 about requirements definition and management (RDM) systems, and the software created with RDM tools. Gartner misattributes several benefits of good process to RDM tools. We give them a 3.5/7 for their analysis – check out the details here.
Two big benefits of incremental delivery
Tarun Upadhyay wrote a fair criticism of our previous post on why incremental delivery is good on his blog today. It is great that he is extending the conversation, and he makes some valid points. We definitely missed a big benefit of incremental delivery, and will cover it in this post.
Scheduling requirements changes – part 2
This process goes against agile principles on paper, but makes teams more agile in practice. Scheduling delivery of a project is an exercise in managing complexity. Scheduling changes to the requirements on the fly is really only marginally more difficult. The key to managing changes is to set expectations with our stakeholders. By defining rational deadlines for change requests, we assure ourselves that we can manage the changes. We also demonstrate responsiveness to our stakeholders. Rational deadlines are not arbitrary deadlines nor are they unreasonable deadlines. Deadlines that vary with the complexity of the changes are rational, easy to communicate, and easy to manage.