I failed.
There it is, in writing for the world to see. You might think it is a bad idea to write about a project that failed – especially since I was the product owner. Fair point but I would have to disagree for the following reasons:
- If we spend time reflecting on the reasons behind our failures, we can learn more than when we succeed. Success leads us to believe we know how to lead a project and that we are a key contributor to the success of the project. What can we learn from success? Failure is a humbling experience and spending time to analyze our decisions allows us to improve our abilities in the long run. So failure isn’t good but failure without retrospection is even worst – unless you are looking to repeat your mistakes.
- If you want to grow as a person, you need to take some risks. The same logic applies to organizations that want to grow, they will also take some risks. As a consequence, if you want to take risks, you better tolerate failures. As Michael Dell once said, it’s OK to fail as long as you fail quickly and gracefully.
- Someone else (I don’t remember who it was) said that you judge people’s character not by the number of time they failed but by how quickly to got back up on their feet and went on to tackle another challenge. The point here is not to run away from your failures but not to sob and feel sorry for yourself.
So here’s the short version of my failed project.
About six months ago, I presented to our executive committee the idea of launching a content based web community geared toward Agile software development. There area already some well known sources of information around agility and some more specific geared toward Scrum but there isn’t a single leading source of information in French (being located in Canada and serving Quebec and France, this is an important need for people we work with). I thought it would be a great way to contribute valuable content to individuals and organizations looking for help in their implementation of agility.
As a true innovator, my boss challenged me to think of the next generation of a web community. Let’s not use what exists today and let’s create a place where people will enjoy gathering – not just a blog or a wiki but something better! So the project began.
After a few weeks, a few of us had brainstormed the new concept, pitched the idea to a few colleagues and went on to do a Sprint 0 (see below for the definition of a Sprint 0). The new concept was a tool that would support collaborative text edition where the community would vote on the best content. Since it is unlikely that we will initiate the same project twice, I might write about some of the project details in an upcoming post. Stay tuned for that.
So a small development team and a Scrum Master were assigned and we started our first sprint of 2 weeks. Than the usual product demo took place followed by the sprint retro. Then another round of sprint planning, execution, demo, and retro. We repeated the process for a few weeks until we realized we weren’t making enough progress. Quality code was being written, must product demos were successful, the team retrospection were informative and the team was increasing its velocity. So why weren’t we getting closer to the goal?
The make a long story short, the concept turned out to be innovative and the development project turned into an R&D project where most of the efforts were spent on the research part. So after 4 months of iterative development, I killed the project!
What I learnt in the process is the following:
- In an organization where there are many competing priorities, launching a new content based web community is a challenge in itself. Adding to the complexity of the original project by launching an innovative collaborative text editing plate form isn’t a smart idea. It would have been a thrill to hit a home run but getting to first base would have been a better strategy. It might not be as glamorous but it is a safer bet and there is always the opportunity to build incrementally after you get the first version out.
- Execution is much more difficult than coming up with an idea. Since the idea seemed good and that people agreed with the concept it was easy to believe we could deliver an outstanding product.
- Every organization is resistant to change, so when a new idea is launched internally it is critical to explain the vision and the benefits to as many people as possible to get their buy-in and identify potential pockets of resistance. It is naive to assume that everyone will see the value of the new concept and will immediately accept it. Once the idea is conceived, promote it as if it was already ready to launch.
It is great to work with an organization that supports entrepreneurship and that invests in its people. Next time around, I will get to first base…
Note: The purpose of a Sprint 0 is to draft a project charter that includes the following elements: vision for the project, objectives, assumptions, success factors, success criteria, roles and responsibilities, priority matrix (scope, time line, and budget), risks, and mitigation. In addition to a project charter, the planning stage allows the project team to start populating the product backlog.
