As you may know, Oli (our VP Product at Innoveo) and myself participated last week to the 2nd “Lean, Agile & Scrum” Conference in Zurich, also called LAS 2010.

The topic this year: From the Scrum project to lean enterprise.

Interesting, isn’t it?

Summary

• For me the clear highlight of the day was the presentation of Mary Poppendieck (she has written the first book about Lean development in the Software industry with her husband) – The tyranny of “The Plan” (presentation here). She explained almost all principles and bases that led to the creation of the Scrum methodology. Very convincing ;-)
• I’ve heard now for three times quite in a row that experienced companies using Scrum are implementing very strictly the Scrum frame (no adaptation and/or tinkering), but are very careful with other Scrum best practices and lessons learnt that cannot be always replicated.
• Again, we have heard very often how far it is absolutely central to have the software engineering and automatization parts under control by introducing such kind of agile approach. What they call “software craftsmanship”.
• All were also confirming how long it takes to transform deeply a company ;-)
• Some speakers were explaining how far they are still struggling with Agile Software Architecture. Seems that maturity in this field is coming quite at the end of the transformation process.
• Heard also that Scrum doesn’t fit well to Maintenance & Support, and that Kanban is more accurate for organizing these activities (but not enough experience yet to confirm Kanban in this field).
• Anecdote: the CTO of bbv (about 110 developers using Scrum since 5 years) said that it is not so easy to spread this kind of agile approach, as “Swiss managers like very much to command & control, which is absolutely against the aim of agile approach”. Not sure that this is so particular to Switzerland actually :-)

Mary Poppendieck

The thinking tool called Agile

Henrik Kniberg, presentation

The illusion of a “good tool”, Don’t blame the tool

Good tools are helping to:

• visualize the workflow
• limit work in progress
• focus on quality
• prioritize
• empower
• support continuous improvements

Using the wrong tool vs. using the tool wrong (both have nothing to do with the tool itself)

The aim of going agile has to be linked with the vision and values of the company => be careful to solve the right problem, i.e. the root causes and not symptoms

Agile is simple but hard!

Transforming BBV into an agile company

Marcel Bauman, presentation

Why changing to agile?

• business requirements are changing a lot, customers are asking for very short projects where you can show step-by-step results, reqs are changing during the projects
• fun for people and developers
• young people are coming more and more on the market with agile teaching

Why Scrum?

• standard method, most used in Europe

Bbv favors (manifesto):

• individuals and interactions over processes and tools
• working software over comprehensive documentation
• customer collaboration over contract negotiation
• responding to a change over following a plan

Scrum works only with:

• source mgt, continuous integration, wiki, test env
• need a lot of virtual machines and processing power
• automate everything that can be automated
• remote access (VPN) for all employees
• XP as a base! => 40% of developers don’t like pair programming

HR:

• no reporting on individual level, just project-level
• incentive on team-level
• pair programming interviews

The tyranny of “The Plan”

Mary Poppendieck, presentation

Key Success Factors for successful projects:

• teamwork
• deeply experienced people
• focus on key constraint
• decoupling
• cash-flow thinking

In other words:

• design the system to meet the constraints; do not derive constraints from the design
• break dependencies
• manage the workflow

Schedules based on experience are reliable. Schedules summed up from task breakdowns are guesses, hypothesis about the future.

Optimize Throughput, not utilization (coming from Queuing theory)!

• minimize the number of things in process
• minimize the size of things in process

Level the workload:

• manage workflow, not tasks
• establish a regular cadence

Limit work to capacity

• timebox, don’t scopebox
• pull, don’t push

Cross-posted on the Innoveo blog.