You are here
Top 10 Things I Learned from Agile 2008
- There is wisdom in crowds. The conference was kicked off by James Surowiecki (author of The Wisdom of Crowds). Crowds are very good at coming up with answers (assuming they meet some prerequisites such as having some understanding of the problem). There were many examples where the average answer of the crowd was better than the best guess of any individual. Diversity can really help in working through issues as it introduces new ways of thinking about problems / solutions.
- Principles are more important than practices. Practices are easy to follow, but if you don't understand the principles behind them, you might be missing the mark. Ex., if your stand up meeting isn't useful, you should probably focus on the principles behind stand ups and figure out how to achieve those principles in your context.
- Software is still a craft. You have to have good people who understand how to produce good software. Technical leadership is still critical to the success of a project.
- Open source projects are successful because people care. It is personal. Personal pride and getting personal value out of the solution (i.e., engineers are stakeholders) greatly increases the odds of success.
- Distributed version control (ex., Git) is a technology to watch. It is particularly valuable in the open source community as it allows non-committers to easily create / maintain their own versions.
- There is value in the fact that bug trackers are an end user tool for open source projects. End users see all the issues and directly contribute.
- Focus on business value, not features. Too often we focus on what features users want. We need to make sure that we understand the business value (to us) behind them.
- Lean is now a core part of agile. See previous blog entry for an excellent book on lean. 95% of problems are systemic. But we often don't look for the root cause, instead we fix the symptom and more problems arise as a result.
- Agile is becoming mainstream in the software industry. The focus now is on taking it to the non-software enterprise.
- Scrum-ban is a concept that could cause some divisiveness (people with passionate opinions on both sides) in the agile community. The idea is to move away from iterations and to simply pull things as you need them. No iterations. No planning/estimation. No burn down charts. Generalists are optional. The future or an anti-pattern?
