Lean Software Development - Experiences

Over the next few days I'm going to post information on experiences with lean software development.

I find it surprising that people actually believe Scrum can work without Lean. LSD helps to organize the backlog, figure out what to do during the sprint, and gets the business on board.

The principles of LSD are most important. Principles drive the practice which drives the technique. Most people concentrate on the techniques, but before you look at techniques, you should ask why (and more questions). Why use these techniques, why do they work, why should I change them. Going back to the principles will guide you when the work at hand can't be boiler plated into a technique. For example if one of your principles is that honesty is the best policy, when your wife asks if her pants make her look fat, you should tell the truth - not doing so would violate your principle in favor of 'say what doesn't rock the boat'.

The LSD principles are:
Optimize the Whole
Eliminate Waste
Build Quality In
Deliver Fast
Defer Commitment
Create Knowledge
Respect People

Over the next few days I'll go into each.

My Presentations at Agile 2008

My game presentation was spectacular. The participants asked a lot of participation and a number of questions related to the game. In fact some of the people were going to use this game at Nokia. Others suggested that is would create an interesting experiment in group communications. Take away is that I’ll probably play the game in the following months.

Agile 2008

Trip report from Agile 2008
Trip Date:
August 3, 2008 through August 8, 2008 in Toronto Canada.

Overview:
The majority of the sessions were in workshop format. I.E. the instructor would lecture for the first part of the session, the tables would break into teams and work an exercise, then the instructor would debrief the teams, bringing home some of the points of the lecture. While this worked in some instances, some of the sessions provided very little new information as the exercises were necessarily simple. Most of the sessions that I attended were related to team work and personal interaction rather than technology.

Takeaways
• Other sciences have potential contributions to agile development.
• Over coaching dilutes influence.
• People matters are of primary concern in Agile development and teams must focus on problems at hand.

Agile 2008 takeaways

I attended Agile 2008 in Toronto this year - August 3, 2008 through August 8, 2008.

Toronto - not a bad city at all. Agile 2008 was a good presentation with a bit too many sessions - 500 over the course of 5 days.

The majority of the sessions were in workshop format. I.E. the instructor would lecture for the first part of the session, the tables would break into teams and work an exercise, then the instructor would debrief the teams, bringing home some of the points of the lecture. While this worked in some instances, some of the sessions provided very little new information as the exercises were necessarily simple. Most of the sessions that I attended were related to team work and personal interaction rather than technology.

Takeaways

• Other sciences have potential contributions to agile development.
• Over coaching dilutes influence.
• People matters are of primary concern in Agile development and teams must focus on problems at hand.