How cognitive biases and/or suspect group decision-making processes may have affected decision-making and performance at your previous workplace.
As a unanimous decision, we in the product leadership team decided to make the move to the Agile methodology of software product development. We had been doing things the traditional “waterfall” method for the longest time, where each team works to complete their piece and then finally integrates into the final product. The waterfall model was an old way of software development where responsibilities of individuals were clearly defined, the order in which the execution was carried out was important, for example quality checks after the entire development process was complete.
The move to Agile was an attempt to revamp the entire development process. In retrospect multiple biases were built into our old software development lifecycle model:
Availability bias: The new feature description was based on inputs collected from few customers all in the UK region, who were easily accessible to the local management team and the information was readily available. We had run into issues because we used “readily” interchangeably with “frequently”.
Optimism bias: As an engineer I had a difficult job estimating, I almost always underestimated my task since these estimates had to be turned in upfront before the project began.
The agile methodology is a software practice that as an organization we adopted to correct some of these oversights/assumptions we had made.
Agile is a procedure heavy methodology, purposely so to ensure that the product/feature development is not done from one engineer’s perspective alone. The project started with a kick-off meeting - which is a planning meeting where the “Product Owner”, in our case the product manager presents a set of features prioritized based on the customer preferences. This was the meeting where we also established timelines for the project. Before we arrived at numbers the task was discussed, the problem and the solution discussed by the team. This exposed the task owner to multiple perspectives, ensured that the same information is reviewed by multiple minds before a solution is finalized and estimated. To improve upon our previous issues with estimation, this time we adopted the “Three-point estimation” technique, which is really a weighted average between the best, most-likely and the worst estimates, with more weight placed on the most-likely estimate. This technique forced me to put in enough buffer by placing the additional weight on the most-likely estimate.
Discussing and reviewing designs with the team ensured that a problem was looked at from at least more than one perspective. My performance improved, it definitely helped me generate