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.

But oftentimes, you need to be able to predict where you're going to end up. You want to know roughly what features are going to make it in the release given the current priorities. This allows you to give stakeholders a feel for where things are going and whether their investment is justified. It allows you to give customers and partners a feel for what is coming their way. Most importantly, this knowledge helps you to make adjustments along the way so that you can ensure that what you end up releasing is best aligned with the needs of the business.

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.

• Focus first on the time between efforts, not the effort of actually doing things. This is often the easiest place to remove waste.

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.

• When doing value stream mapping, focus on the delays, not improving the work.
• For example, delaying testing or integration makes debugging issues significantly more difficult.

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.

I really enjoyed the talk I gave at Agile Austin tonight. Lots of good questions and interaction. The Austin agile community is vibrant and growing quickly. Kudos to Scott Killen and Agile Austin for their work in establishing and growing the community. There were almost 100 people there.

If you missed the talk or attended and would like to see the presentation, you can find it under presentations here.

For those in the Austin Area, I'll be doing a talk at Agile Austin next week on Tuesday, February 3rd. I'll be talking about my experiences in establishing and scaling agility within a large software organization.

Time: 6:00 - 8:30 PM
Location: Microsoft Technology Center; Stonebridge Plaza One; 9606 North Mopac; Suite 200; Austin TX, 78759