It been about a month since I mentioned scrum as a methodology. And Id just like to do a quick recap on a few points that I mentioned in my last point. The first note, my wife told me a few nights ago that her scrum team was not going to deploy on time; rather, they had decided that they were going to deploy a week later than planned, because the team was not confident that their code was ready for qa. No big deal actually. This kind of stuff happens all the time, which was one of the points of the last post. Once once steps away from the perfection of the books reality still has to be dealt with.
Her other comment to me was that her team no longer wanted to use the scrum software they had been using, Rally, and had decided to just use a white board instead. About a month ago Rally was the best thing since cornflakes. I remember one night I got an unasked for 20 minute introduction to it extolling all its features. Again there is theory and practice.
Companies provide tools for their workers to manage projects but what kind of a tool is needed for a developer to do his work? Its not enough to just give us a tool -- 'this is great use it'. In practice a tool has to provide value to the people that are using it or it ends up like the ~$1000+ a year per person licence for Rally, unused. Or more likely, from the companies, I have been a part of, one has to force people to use it and give some kind of punishment for not. At my last job reliably filling out forms once a week, to provide metrics to management, became a element in our year end review. Part of the problem with this type of monitoring is that the people you want to stay with the company don't give a shit about year end reviews because (a) they are pulling far more than their weight and suspect that you need them amidst the mass of incompetence and (b) because they can go some place else where people wont pester them if its an issue.
I've spent some time thinking about what managerial tools would help me develop and I have done a bit of experimenting here and there. I have a few thoughts about what is good and what is bad. And I am going to start with the bad.
Tools that collect metrics, the popular term for data these days, are less than worthless. The big objection to a statement like the above is management needs to instil accountability, and needs 'insight into the process' so that they can then 'improve the process' through repeated virtuous cycles. Multiple problems here. First, usually proper metrics are not collectable for the type of work I do. Several years ago I worked for a CMM 5 certified dev group and I remember on my first day of work there was a big debate between the dev lead and the project manager about how the # of lines of code should be reported. This is not a very good metric to start with and the debate was over the question -- do we include comment lines in the count of lines of code?. After consultation with the facility manager the answer was -- yes, comments are counted in lines of code. Good metrics are hard to come up with and the bottom line is that good people in an organization know who among their direct peers is doing good work but those same people are rarely able to quantify their opinions.
The above story brings out a second problem with metrics. The people that provide metrics have a very strong self interest to make the metrics appear as good as possible. For metrics that are going to be visible across an organization, both individuals and the operating units that provide the metrics, will generally do whatever they need to do to make those number be whatever upper management wants to see. People are intimately concerned with their careers and the more focused they are the better cheaters they will become.
The last problem with metrics, that particularly peeves me as I have done a lot of statistical work, is that data is collected in a very uncontrolled manner and then it is analysed by people who lack the background to do the analysis -- like, for instance, have ever heard of a Gausian distribution. At the CMM 5 company I mentioned above the statistics where put together by a secretary and then management reviewed the final numbers and added fudge factors to make the numbers come out more to their perference. So try not to force tools on people so one can obtain metrics. Most likely the final result will just be accumulation of the wrong kind of data, analysed incorrectly and then falsified to show what people want their superiors to see.
The last 'bad' for today are tools that add steps to work processes. There are people in companies whose reason for living is to build processes and unfortunately these same people are the ones who seem to drive the tool building efforts within and organization. Using computers for that kind of activity just introduces two liabilities (ie - code and process steps) into an organization. My feeling here is that any tool that is built has to be created with the specific intent of removing some task that has to be done manually, making some current task unnecessary, or replacing someone's job or a class of jobs with a computer. There is always a cost benefit trade off for new tools and, just to keep everyone honest, I expect that when I perturb my system with a new tool that that perturbation takes me immediately to more optimal equilibrium on the 'work smarter' curve.....
And with that I try to get some ideas about what is 'good' in at a later date
Do your best - Marco
Her other comment to me was that her team no longer wanted to use the scrum software they had been using, Rally, and had decided to just use a white board instead. About a month ago Rally was the best thing since cornflakes. I remember one night I got an unasked for 20 minute introduction to it extolling all its features. Again there is theory and practice.
Companies provide tools for their workers to manage projects but what kind of a tool is needed for a developer to do his work? Its not enough to just give us a tool -- 'this is great use it'. In practice a tool has to provide value to the people that are using it or it ends up like the ~$1000+ a year per person licence for Rally, unused. Or more likely, from the companies, I have been a part of, one has to force people to use it and give some kind of punishment for not. At my last job reliably filling out forms once a week, to provide metrics to management, became a element in our year end review. Part of the problem with this type of monitoring is that the people you want to stay with the company don't give a shit about year end reviews because (a) they are pulling far more than their weight and suspect that you need them amidst the mass of incompetence and (b) because they can go some place else where people wont pester them if its an issue.
I've spent some time thinking about what managerial tools would help me develop and I have done a bit of experimenting here and there. I have a few thoughts about what is good and what is bad. And I am going to start with the bad.
Tools that collect metrics, the popular term for data these days, are less than worthless. The big objection to a statement like the above is management needs to instil accountability, and needs 'insight into the process' so that they can then 'improve the process' through repeated virtuous cycles. Multiple problems here. First, usually proper metrics are not collectable for the type of work I do. Several years ago I worked for a CMM 5 certified dev group and I remember on my first day of work there was a big debate between the dev lead and the project manager about how the # of lines of code should be reported. This is not a very good metric to start with and the debate was over the question -- do we include comment lines in the count of lines of code?. After consultation with the facility manager the answer was -- yes, comments are counted in lines of code. Good metrics are hard to come up with and the bottom line is that good people in an organization know who among their direct peers is doing good work but those same people are rarely able to quantify their opinions.
The above story brings out a second problem with metrics. The people that provide metrics have a very strong self interest to make the metrics appear as good as possible. For metrics that are going to be visible across an organization, both individuals and the operating units that provide the metrics, will generally do whatever they need to do to make those number be whatever upper management wants to see. People are intimately concerned with their careers and the more focused they are the better cheaters they will become.
The last problem with metrics, that particularly peeves me as I have done a lot of statistical work, is that data is collected in a very uncontrolled manner and then it is analysed by people who lack the background to do the analysis -- like, for instance, have ever heard of a Gausian distribution. At the CMM 5 company I mentioned above the statistics where put together by a secretary and then management reviewed the final numbers and added fudge factors to make the numbers come out more to their perference. So try not to force tools on people so one can obtain metrics. Most likely the final result will just be accumulation of the wrong kind of data, analysed incorrectly and then falsified to show what people want their superiors to see.
The last 'bad' for today are tools that add steps to work processes. There are people in companies whose reason for living is to build processes and unfortunately these same people are the ones who seem to drive the tool building efforts within and organization. Using computers for that kind of activity just introduces two liabilities (ie - code and process steps) into an organization. My feeling here is that any tool that is built has to be created with the specific intent of removing some task that has to be done manually, making some current task unnecessary, or replacing someone's job or a class of jobs with a computer. There is always a cost benefit trade off for new tools and, just to keep everyone honest, I expect that when I perturb my system with a new tool that that perturbation takes me immediately to more optimal equilibrium on the 'work smarter' curve.....
And with that I try to get some ideas about what is 'good' in at a later date
Do your best - Marco
RSS Feed