Introduction to Agile

There have been many different descriptions of agile development, and all of them have their pluses and minuses. Our definition may be a bit different than most. Rather than concentrating on the practices to define the process, we prefer to concentrate on the results. Our definition of agile is “Building the highest value software, with high quality, as quickly as possible.” We believe this definition will drive the agile practices used by other agile definitions. Based on this definition of agile, certain practices become very important. Let’s unpack the definition one piece at a time.

Building the highest value software” implies that we have a way to measure the value of software being delivered. Furthermore, once we have value associated with the software we have to be able to prioritize that value in order to be able to maximize it. In agile this is known as working from a prioritized product backlog. All possible features for a product are in the backlog and the backlog is prioritized by business value. Depending upon the agile methodology being used, the role that prioritizes the backlog has a different name. In eXtreme Programming (XP) it is the customer role, in Scrum it is the Product Owner. We prefer the generic role of Product Champion. Almost every agile method has a role that is similar to this one, and we will use Product Champion to represent all of them.

“with high quality” seems obvious, but deserves a bit of mention anyway. In agile it is assumed that high quality software is created in small pieces. Each individual piece is completely coded and tested before it is considered “done.” In agile there is no concept of “throw code over the wall to QA.” The process is used to build quality into the code rather than testing quality into the code. Specifically how this is done is up to each team, but it generally involves automated testing, continuous integration, nightly builds, etc.

“as quickly as possible” does NOT mean hacking is acceptable since we are also looking for high quality. Agile achieves this goal by using short, time-boxed iterations for creating software. Iterations are generally 1-4 weeks in length (although Scrum recommends 30 days). Most teams using agile methods today are using 2 week iterations. During each iteration the team makes a commitment to create a specific amount of completed software (i.e. coded and tested). Note that the commitment is done in a way that the team works at a sustainable pace based upon estimates created by the team.

There are certainly many other agile practices that can be used, but building software from a prioritized list in time-boxed iterations using quality practices is a great starting point!

The process we teach is shown below (click on the image to get a huge version of it).  It is simple to show on a diagram, but the hard part is how to actually do everything it implies.  That is is where training and coaching can really help a team be successful.  Feel free to call us at 303-766-0917 or email us at info@agileforall.com and let us help you!