Agile Engineering

Iteration Planning, if done right, can go quickly and painlessly. The objective of iteration planning is to understand what you're attempting for the next iteration and to plan out just enough that you're confident that you can achieve it.

On April 7th, Scott Bellware gave a presentation at Agile Austin entitled "5 Things I Learned from Lean". Scott had worked on a rewrite project that failed. He looked to lean to identify the issues that led to the failure / how he could prevent similar failures in the future. This presentation was focused on those lessons learned.

In agile, we attack the most important things (those with the highest business value) first. We learn as we go and constantly refine our priorities based on the knowledge gained.

Here are some of the items I enjoyed most from the most recent installment of Alan Shalloway's online course on Lean: An Introduction to Lean Software Development. See this link for notes from previous sessions.

Metrics can be useful indicators of how things are going. They can help you identify areas to investigate / learn more. They can also be misused.

On Tuesday, Israel Gat and Sebastian Hassinger gave a talk at Agile Austin on The Use of Agile Methods by the Entrepreneur.

Israel started by talking about market disruptions and the synergy that software brings to them (a follow up to a recent blog entry he wrote on the subject):

I've been attending a web based class on Lean development presented by Alan Shalloway. The most recent session was on the Lean-Agile Connection. See this entry and this entry for notes from previous sessions.

It struck me the other day that organizations have some similarities with code. Agile promotes designing as you go. Think ahead just as much as you need to. And implement for the now. When things change, "refactor" the design. I.e., morph it so that it looks like it would if you were to do a design for the current functionality of the system.

Multi-tasking can be a problem at a couple of levels. From an organizational point of view, people can be allocated to multiple projects. This could be two different releases, it could be a new release vs. support of an old release (for more on this topic, see this blog entry), etc. Working on multiple projects causes several issues.

It seems like large companies have evolved to adopt some practices which, in retrospect, are not ideal. Some common ones: specialization, multi-tasking and not refactoring. In this blog entry, I'll cover specialization. I'll cover multi-tasking and not refactoring in future entries.