Reports/week 2

From Riley Consulting Wiki
Jump to: navigation, search

Report for 17 - 21

Summary:
    This week things went far more smoothly than the last week. The large implementations that we put into place last week seemed to really pay off as the storm team was able to complete every task assigned for the iteration. This meant that the majority of my time was spent analyzing other aspects of The RedX's development process. This lead to the creation of my Developer Meetings and Flow Accommodation proposals.
Details:
    The successes of the storm team this week can be traced to a few things that were done differently in this iteration. First, we took the time on our Friday iteration-planning meeting to discuss the tasks that were assigned and to try and ensure that they were reasonably sized tasks to get finished in a week. This was more difficult than might be expected, as it seems that every developer wants to over-promise. We all want to be the hero, the person who gets more done in a week than is humanly feasible. This tendency is compounded when upper management puts pressure on the developers to finish their product in an unrealistic time frame. The productivity of the storm team leading up to this week show that an environment pushing the developers to accomplish the impossible is not effective, at least not in the long term. While in the short term it can be motivating and the last night work days are exciting and driven by a desperate creativity, that seems to be unsustainable for more than a few weeks at most. So the team did better when they refused to succumb to the desire to do the impossible and instead set reasonable and accomplish-able goals.
    Another reason behind the success of the team can be attributed to the parallelization of tasks, not only between developers, but for an individual himself. Each developer had multiple tasks they were in charge of completing by the end of the week. What I saw, in myself and the rest of the team, was that unlike every week leading up to this one, no one ever got stuck. The freedom the developer had to bounce between tasks as he desired led to the tasks getting finished on time. I do see a potential pitfall here though. It is crucial that a developer has time to slip into "flow" if that developer wants to accomplish any meaningful work. If a developer is given multiple tasks, there is a risk that the developer will switch between the tasks too often and pull himself out of flow with each switch, severely hampering his ability to get work done. I do not believe that this is something there needs to be a policy in place for. A policy like "you have to spend two hours at least on a task before you switch" is arbitrary and shows a lack of faith in the developer. The proper way to mitigate the problem is to teach each developer about flow and how crucial it is. Once done, a developer who continues to be unproductive because they are switching tasks to much needs to be put in an extreme programming team, assigned different types of tasks, or fired.
    It is not a coincidence that all meetings with upper management were canceled this last week and this was the most successful week the storm team has had. Pondering this led to my proposal, linked above.