• Agile Enterprise Architecture
  (tags: via:mrchippy agile software)

For waterfall projects, the classic defect curve is used to determine when a product is ready to ship. This is because most of the features have been “completed” during the first part of the development cycle, and the only work left to do is fixing the remaining defects. With Agile, there is a different approach where the work for the next iteration (2-4 weeks) is determined at the beginning of each iteration. This work should include taking the highest priority items from the backlog and working on those. In an idea environment, any defects are including the backlog and prioritized along with all of the features or enhancements to complete. However, when the defects are separated, the counts take on a life of their own.

These counts create perception issues and also cripple the Agile process because they are not prioritized with all the other work that is needed for the product. For instance, ten defects may cause one engineer to cringe, while a customer may not care about one thousand defects as long as the software performs its job. In addition, these defect lists have to continually be reviewed as a separate work set, which makes overall prioritization nearly impossible. In general, separating the software defects from the rest of the work is a relic of the waterfall days, while the Agile way is an all-encompassing backlog. When looking at a defect chart and waiting for the slope to point downwards, a good question to ask is “Why am I looking at a defect chart?”.

Having personally developed lots of software as well as worked with many software developers over the years, I’ve formulated a theory on why lots of developers are resistant to unit testing and test driven development (TDD). The theory is simply that most developers know that 90% (or more) of the lines of code they write are defect free; consequently, forcing 100% of the code to have tests seems counterproductive to many of them. It’s a theory that seems obvious after being said out loud, but I rarely hear it explicitly verbalized in discussions to increase testing.

The mental hurdle that is difficult to overcome is that the 5-10% of the code with defects is like a minefield scattered throughout the product. Many Agile software processes promote a test first then code approach, and this considered a mythical utopia by most software shops. Even though more companies are adopting test first strategies, the key to changing the mindset has to occur in technical textbooks and classrooms. After the ‘hello’ program has been taught, all other examples should start with a test and proceed from there.

At last year’s Agile conference, I was entertained to hear one of the group discussions involve ‘relating Agile software development to every day situations in life’. I didn’t attend this group discussion, but there have been many times over the past year where I have taken a mental note of some similarities. While this will surprise very few people, since our work processes often stem from actions outside of work and vice versa, some of the similarities help explain why Agile works in developing ‘craft-like’ products, such as software. I’ve listed a couple of incredibly simple ones, but there are many more.

Paying bills. As any financial planner will advise, a wise person should pay their utilities and other necessities before buying that new ceramic unicorn for the collection. With an Agile process, the truly important features are added first, and once these features have been added, the extras are worked into the product. In the end, there’s little chance of the electricity being turned off!

The big spelling test. When I was in 5th grade, I aced a ~70 word vocabulary test that we were given a couple of weeks to prepare. I’m no word buff, but when the teacher asked me to explain to the class how I did it, I said I had casually studied 5 new words every day for the past couple of weeks. I hadn’t tried to learn the whole list all at once nor cram a few days before the test. This is very similar to the iterative approach prescribed by Scrum and other Agile methods. Break the work out into discrete blocks and concentrate on those blocks for short periods of time.

The point is not to trivialize Agile processes in general, but it is important to note the methods used in Agile are also methods that generate higher success rates in other practical areas.