Reports/week 1

From Riley Consulting Wiki
Jump to: navigation, search

Report for Feb 10 - 14

Summary:
The majority of work this week was focused around trying to discover why the Storm team was falling so drastically behind on their deadlines and ways that the project manager might be able to both increase the rate of work and lower the expectations of executive management with regards to the product that we could have available by the end of the quarter. I also was able to interview some memebers of the support and QA teams to discover their process for reporting bugs to the storm team. I found that the process was non-existent and that their needed to be one. Details on that are in my Bug-Reporting Process report.
Details:
    The storm team is behind its deadlines. At this point, the configuration, testing and logging frameworks were to have been put into place as well as getting a single line to dial out from the storm freeswitch server. As of the writing of this, there is no logging, configuration or testing for the client side of the app and dialing out is only in a prototype stage. I sat down with Brandon (the project manager) and Lynn (IT support) to try and diagnose the problem and find a potential solution. One of the biggest things to come out of this meeting is that the storm team is forging new ground into things none of us have ever done before, even though there is a version of Storm out right now. The logging frameworks took about 8x longer to get right since we had to heavily modify the existing ones we were using, and we didn't understand them beforehand. The dialing logic is being written in C++, a language that Brandon has not worked in for years. In addition, the problems we are solving are difficult by their very nature. The dialing module is a multi-threaded, real-time piece of code that has to be perfect as it is the heart of the Storm application. Just getting it to work is a difficult task, then actually testing it in the timing-based, multi-threaded environment it needs to be in takes even longer. Since there is no test team at The RedX, that falls on the developers to do. The bottom line is that trying to get that system written in a week was completely unrealistic, and the logging frameworks were things about which we had a 3rd order of ignorance going on: we didn't know what we didn't know until we were in the thick of it, at which point it took days to dig our way out when only hours had been estimated. Examining this information led us to the conclusion that we don't feel like we can estimate the time for any tasks at all. That is of course at odds with our management, but consistently missing arbitrary deadlines is at odds with our moral. A few things were decided to try and fix this problem. First, we would work on things that we can show the management, so that they can see that we are making progress. This means we run the risk of skimping on quality or testing to get something ready for management, but we feel that is a risk we are willing to take, and since the team at large is quite quality focused we believe that a shift of focus to things we can demo will help get us on the track we need to be on. Second, each programmer would have two tasks assigned to them each week. The thinking behind this is that we noticed we would get bogged down in some task and spend hours trying to push through it, only to go home frustrated and then fix the problem first thing the next morning. That break time seemed to be the time that our minds could sub-consciously work through the problem and then we could return with the solution well in hand. Having two tasks assigned means that when a developer bogs down in one, he can immediately switch gears to the other problem, giving himself some space and time to rest from the problem task and hopefully return with a fresh pair of eyes and be able to plow through the roadblock. The other large motivation behind the multi-task assignment had to do with estimating. The idea we landed upon was that each task has some unknown element to it, something we can't estimate because we don't know what it is. For some, that unknown will be trivial. For others, it could mean extensive, unplanned work. However, there is a notion in statistics that if you put a bunch of unknown distributions together, you end up with a normal, well-behaved Gaussian distribution. At its core, the idea is that one thing on its own is completely unknown, but many unknown together will become a normal, defined distribution. We decided to apply this to our tasks. We might not be able to estimate a single task, but running ten tasks in parallel we should be able to give more accurate estimations. Using this we hope to be able to keep moral among the development team high and also play the management's game by giving them constant estimations and accurate weekly status reports.
    Another reason that the storm team is behind its deadlines is that it didn't get to set them itself. Management simply came and told us that they wanted this product by 1 April, 2014. The only reason they decided on that deadline is because it is the end of the quarter, when many other goals are to have been accomplished. In my talks as a consultant with the executives, I have found that they genuinely believe that setting a deadline motivates the developers to somehow work smarter or harder and reach that deadline. This conflict with what "Peopleware" teaches, and our efforts reinforce the ineffectiveness of this approach. The developers feel they are missing milestones because it is impossible to make them. I have interviewed a few people about this and distilled my thoughts into the Deadline Creation Proposal.