Is hard to achieve success without any failures. It’s best to learn from others’ failures, but some failures seem inevitable. Here are some failures that apparently I was not able to avoid, and frankly I’m not particularly proud of them. But if you want to “learn from others’ failures” or feel better about your own screw-ups just enjoy the reading. So here are some approaches that didn’t work.
1. Very efficiently doing the wrong thing
After 1 year of building the new feature set for the brand new product, testing it thoroughly, and eventually shipping it, it turned out that not many of the end users knew how to use it. Meanwhile my team and I have put a lot of effort in optimizing the processes, built an extensive test suite, fixed hundreds of bugs, used thousands of man-hours on building the product. Eric Rice’s book “The Lean Startup” just confirmed the lessons learned: much effort could have been saved. So what could we have done better? We should have used more time and effort on interacting more with the early adopters, take ownership of the usability tests to shorten the feedback loops, schedule regular pivot-or-preserve meetings taking into consideration early adopters’ and usability testers feedback, and finally make pivot decisions earlier, when cost of change wasn’t dramatic.
2. Neglecting importance of F2F meetings
This might seem obious, yet when deadlines are looming it’s easy to forget this simple truth. It’s specially important in outsourced projects where opportunities of meeting the customer might be rare and need to be proactively seek for. There is no better opportunity to understand your customer than during a face to face meeting. Proactively seek for regular meetings with customers. Is worth the effort and money that pays off in long term. For complex projects it is good to have a liaison role established at customer premises. It should be a technical, experienced person who understands technical implications of the problem and can advise on design and architecture of the solution. He or she can be a part of the Scrum team. This role can be rotational – different members of the team might fulfil it. Rotating at this role in addition to constant technical advise gives other benefits: it helps team members to perceive the problem from customer perspective, it helps them to understand business and cultural drivers behind the technical solution, it usually brings a positive motivation impact.
3. Agile as a mini waterfall
This is a classic problem for teams with small Agile experience. And many times it is rooted at the legacy roles at the organization where it’s common to have programmers, testers, build- or release- managers. My team and I have gone through it. After organization switch to Scrum, we thought that we will shorten the release cycle to 2 week sprints, code for the first week, then merge our code and build the stable version during 1 or 2 days, test and fix bugs for the next 2 days, and finally prepare the demo. The consequences of such setup were following: using code-freeze anti-pattern, delays in integration, delays in testing, hectic code fixes, panic mode at the end of each sprint with preparing Sprint demo. It took us a while to create automated tests that were treated as part of the product (not as an overhead maintained by the separate team), implementing continuous integration with nightly builds, and automated deployment tools.
4. Forgetting about small wins
Any project can become appealing if you keep a steady flow of events that bring the team spirit up. Celebrating successful sprint demo, bringing pizza to sprint retrospective, assigning time to technical knowledge sharing session, organizing readers club, organizing hack day, or celebrating a night out with a team at the pub. At times such initiatives bring much better effects than optimizing the processes.
5. Not enough planning
Years back my senior design project teacher used to say: if you fail to plan, you plan to fail. In organizations some products or features need to be done fast. It usually happens when a problem and solution seam clear enough to ask a person or a team just to start coding. My rule of thumb in such situations is: if it cannot be done in a week it should be a separate project. In agile terms it means dedicating a product owner, a team, creating a product backlog, and assuring people availability. Otherwise, a product or a feature becomes at no ones responsibility and the implementation of it drags forever bringing lots of frustration to anyone near it.
The above are one of the most important lessons learned for me. Hopefully, I will not repeat the mistakes and will know what are the right things to do in certain situations. Still, knowing the right things to do is not enough. One needs ability to communicate, persuade his colleagues and superiors, be aware of organizational constraints in order to actually make the right things happen.