Agile Engineering

I just finished reading Mary and Tom Poppendieck's second book on Lean Development: Implementing Lean Software Development: From Concept to Cash. It was a great book. Highly recommended. In this blog entry, I'll cover some of the major things that I got out of it. For more details (and lots of additional valuable insights), read the book.

A key concept behind agile practices is that once an iteration starts, you try not to change its scope. After all, it is only a short time until the next iteration. Why can't the interruption wait? By adhering to this approach, it allows the agile team to focus and not get killed with interrupts.

How does this approach work with third level support (which by definition works on an interrupt basis). You usually can't wait until the next iteration to start working the customer issue. To do so would typically violate your SLA's.

Agile Development and Object-Oriented Programming share many similarities as trends in the software community.

The first aspects of Object-Oriented Programming originated in the 1960's with Simula. Smalltalk carried it forward into the 70's and 80's. It finally crossed the chasm and hit the mainstream in the early 90's. C++ and Java helped greatly in driving its adoption.

On Wednesday, I (along with 80 other people) heard Jeremy Miller give a presentation on Agile Design at Agile Austin. Generally speaking, it is a hard topic since it is difficult to discuss without going into specifics. Jeremy did a great job at it. This blog entry captures what I took away from his talk.

One of the hardest things in agile development is adjusting customer / stakeholder expectations on the way that things are promised.

Last night, I went to a talk given by Luke Hohmann of Enthiosys for Agile Austin.

The talk was focused around prioritizing the backlog. A more in depth version will be presented by Luke at the Agile Conference in August. There were a few good points that I took away from it.

This was the title of a session hosted by Jeffrey Palermo at the Agile Austin Open Space Conference that I attended recently.

It got me thinking a bit about the relationships between the various agile methodologies. I've always stressed the use of Agile over a particular methodology (such as Scrum) because I wanted to ensure that we felt free to use the best of each. In the end, I've generally found myself using Scrum with some concepts from XP.

A common misconception is that agile doesn't scale to large and/or distributed teams. Many of the agile methodologies focus on smaller teams, but that doesn't mean that their usefulness is limited to that context.

Large, distributed teams present their own challenges. These situations can be more difficult in any project management approach (including waterfall). Agile has proven to be compatible (I would argue superior) with these scenarios.