Every software team has some great engineers, and some not so great ones. Typically, when you are doing a project, you would take your list of features and categorise them into a breakdown of how difficult or how easy they are. Once you have done this, you would get into the process of estimating these tasks and assigning them to different members of the team. One somewhat hidden portion of this entire exercise of estimation and assignment is that you would do the estimation based on a specific person to do the feature (for a more complicated feature, the person who is more skilled would take far less time than the mediocre engineer in your team - and every team has bright people and mediocre people). What this results in is that you have already done some amount of thinking about whom to assign to the more difficult features - typically you would look at the total time available for your skilled people and assign accordingly.
So, you have started the entire exercise of getting the work done, with different parts of the project assigned to different people and are tracking progress of these tasks. This is where I tell my example where some amount of bad planning and some assumptions landed the team in some serious trouble - we had some critical features that were very important for the ongoing version of the product, with marketing depending on these features to be the ones that would get highlighted in reviews, and these were the ones that were pulled up in stakeholder status and review sessions. In fact, part of discussion with stakeholders was about assignment of these features, and once we had presented the assignment of these features to the more skilled engineers, there was approval to proceed.
Now, how many of you have heard of Murphy's Law ? If something can go wrong, it will. And guess what, it did. We were deep into task assignment, and since the engineer doing the most complicated feature was skilled but a bit moody, we had neglected to do periodic sharing of the code and design with a buddy engineer. And of course, we ran into an issue where the engineer ran into some sudden health issues with his daughter, which caused him to take leave for a period of 2 weeks, causing him immense emotional stress. It landed us in a tricky situation. Given that he was already stressed and was already out to take care of his daughter, any kind of information sharing was very difficult. We had permission to drop a couple of features so that we could divert some engineers to this sudden issue, but the information sharing was proving to be a big handicap.
We asked the replacement engineers to study the code intensively, but it did cause us a 6 day delay in delivery of the important features, and also caused a higher number of bugs to turn up since these replacement engineers did not have the same level of familiarity with the code. You would not want to know about the reaction of stakeholders to this delay, especially since these features were critical. And, the biggest problem was that we had a process whereby we used to get engineers to share their current status with their buddy, but for tight-scheduling reasons, we had gone a bit slow on the buddy program; and that was what hit us the most.
So, you have started the entire exercise of getting the work done, with different parts of the project assigned to different people and are tracking progress of these tasks. This is where I tell my example where some amount of bad planning and some assumptions landed the team in some serious trouble - we had some critical features that were very important for the ongoing version of the product, with marketing depending on these features to be the ones that would get highlighted in reviews, and these were the ones that were pulled up in stakeholder status and review sessions. In fact, part of discussion with stakeholders was about assignment of these features, and once we had presented the assignment of these features to the more skilled engineers, there was approval to proceed.
Now, how many of you have heard of Murphy's Law ? If something can go wrong, it will. And guess what, it did. We were deep into task assignment, and since the engineer doing the most complicated feature was skilled but a bit moody, we had neglected to do periodic sharing of the code and design with a buddy engineer. And of course, we ran into an issue where the engineer ran into some sudden health issues with his daughter, which caused him to take leave for a period of 2 weeks, causing him immense emotional stress. It landed us in a tricky situation. Given that he was already stressed and was already out to take care of his daughter, any kind of information sharing was very difficult. We had permission to drop a couple of features so that we could divert some engineers to this sudden issue, but the information sharing was proving to be a big handicap.
We asked the replacement engineers to study the code intensively, but it did cause us a 6 day delay in delivery of the important features, and also caused a higher number of bugs to turn up since these replacement engineers did not have the same level of familiarity with the code. You would not want to know about the reaction of stakeholders to this delay, especially since these features were critical. And, the biggest problem was that we had a process whereby we used to get engineers to share their current status with their buddy, but for tight-scheduling reasons, we had gone a bit slow on the buddy program; and that was what hit us the most.
No comments:
Post a Comment