What is so interesting about this challenge is the observations Tom Wujec presented in his Ted talk(http://bit.ly/rKOoBX) : recent kindergarten graduates score better than business students. Why? Because business students are trained to find the single right plan and then execute on it. Kids just do it, fail, learn what works, and then adapt. Sounds familiar, right? It is the same as Fail-Fast-Fail-Often or Fail Fast, Succeed Sooner!
What is also interesting is the diversity of the team and how executive admin affected CEO’s achievements because they know the process and know how to facilitate.
See also how incentives affected low skilled teams:
I recall another exercise was given at a scrum master training course, where the instructor James Coplien (http://amzn.to/skE2Ov & http://linkd.in/u6IQLT) divided the students into two teams, one with a project manager role and another one with an engineering role. He asked everybody to choose two in his/her mind from the team. He then explained the problem to the teams: each one should stand exactly one meter away from the two he/she chose. He asked the project managers team to come up with a plan on how to do that, and asked the other team (engineers) to just do it. Project managers spent the whole time trying desperately to come up with a plan, and they failed (I was among them :D), while the other team did it in no time.
A number of lessons learned from these observations
- Do things fast, learn what works and what won’t work, then iterate
- Teams should collaborate and work together very quickly
- Team members should have the skills to be able to take on complex activities / tasks
- Self organization
- Diversity of the team is important (cross functional team as we call it in Scrum)
This is applicable in almost everything entrepreneurs do! This also applies to software development even in an established business, and almost everywhere else. Here are some examples from my personal experience:
- Build software systems iteratively! Don’t over design, eliminate waste (learn), and release smaller, yet shippable parts of the system each sprint.
- Instead of spending months designing the system, bring in your senior team members, architects, DBA’s, and whoever is needed. Ask them to come up with an abstract implementation within two weeks to what the system should look like. Working code is delivered instead of documents! Enough design is made instead of long months designing something that will not see its way to implementation (most of the time).
- Product Management
- Instead of building the perfect product in isolation, build a smaller version of your product, yet with enough features, and go out there, get real feedback, and then iterate again!
- Deliver smaller amount of features each time you iterate, keep going back and forth with your users, always listen, and always iterate with better experience / features.
- Instead of living alone with your brilliant idea, talk about it with people that you trust! In worst cases, you will find out that there is a similar product out there! Fail Fast.
- Get your product out there as fast as possible, and then iterate.
- Software Engineers
- Instead of implementing the complete feature at once, take the iterative approach (such as in TDD - I’m not with TDD, just an example). Write a smaller code that compiles and works with the other part of the system, and then iterate.
- Continuous integration - keep integrating part of the system with the system, that will enable you to discover bugs and problems early in the development.
With this approach, I do believe that you will lose fear (perfection), keep failing until you do it, and very fast. You, and your team should work in harmony to achieve that. Failing is an opportunity to learn, and one step to your success.