I've been attending a web-based course from Alan Shalloway on lean. Here are some of the highlights from the final session (focused on Product Coordination and Release Planning). See this link for the previous session (which contains links to the other sessions as well).

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.

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.