Scrum Is Not Just For Software
The new home page of the Scrum Alliance is showing a change of focus for Scrum:
Scrum: A team-based process to develop complex systems and products.
Scrum is an iterative, incremental process for developing any product or managing any work. It allows teams to deliver a potentially shippable set of functionality every iteration, providing the agility needed to respond to rapidly changing requirements.
For more information see the paper Scrum Is Not Just For Software: A real-life application of Scrum outside IT.
The 5 Questions Series
James Brett has started a series of interviews where he asks the following five questions:
- Can you describe what you would consider the top Scrum enabler in an organisation?
- Where do you see Scrum in 5 years time?
- What has been your toughest Scrum challenge so far?
- What makes you passionate about Scrum?
- What can we learn from you about Scrum?
The first interview is now available: Issue 1: Ron Jeffries.
Top 5 Scrum Transition Anti-Patterns
I am sharing some Scrum experiences that I have had in both Australia and Europe through a series of anti-patterns that I am posting on my Software With Style blog. These anti-patterns are:
- Mistake #1: Premature Process Optimisation
- Mistake #2: Exceeding the Transition Speed Limit
- Mistake #3: Misaligned Sashimi Slicing
- Mistake #4: Accumulation of Undone Work
- Mistake #5: Individual Heroics
These anti-patterns cover a broad cross-section of project concerns including method customisation, transition strategy, work breakdown, technical and quality debt as well as teamwork issues. Each anti-pattern is presented in a consistent structure comprising background material, a short experience report, smells that may represent a symptom of the problem, factors that may cause the problem to arise, potential consequences if the problem is allowed to fester and guidance as to what can be done to avoid or resolve the problem.
I hope that these help readers to avoid falling into these traps and to deal with them effectively if and when they arise.
I’m keen to to hear your thoughts on these. If you have had a similar experience or have a different perspective on this, please post a comment on my blog.
Self Organising Teams and Formal Software Development
The Agile Advice blog has links to two interesting articles that have been recently rerepublished by Fast Company.
Engines of Democracy (from 1999). Self organising teams who build jet engines for General Electric.
Manufacturing jet engines may not be like developing software, but…
The most interesting measure may be one that the people at GE/Durham talk about themselves. They don’t really think that their main job it to make jet engines. They think that their main job is to make jet engines better.
They Write the Right Stuff (from 1996). Writing software for the space shuttle. Their process is the opposite of agile, but the article gives insight into the effort, cost and discipline required to write (almost) bug free software.
Some of the figures are astounding:
- Budget of $35 million per year.
- Team of 260.
- 2,500 pages of documentation for a change that required 6,366 lines of code.
- 40,000 pages of documentation.
- One error in each of the last three releases (420,000 lines of code).
Australian Scrum Survey Results for January 2009
James just pinged me to let me know that the January 2009 Australian Scrum Survey results are now available for viewing. Interesting stuff! Check it out.
Kudos to James and Martin for collating and publishing the results.