Do You Get What You Measure?
in [OOP]
|
From: Nick Malik [Microsoft] on 15 Apr 2006 13:04 Hello Jason, You've made some assumptions that I would like to challenge: <jasongorman(a)blueyonder.co.uk> wrote in message news:1145088647.067648.188630(a)z34g2000cwc.googlegroups.com... > Processes don't have performance characteristics. Teams (or machines, > or trained animals) performing processes do. A process is a composition of steps in a specific order. The order and the composition matterns. One of the goals of process optimization is to improve the order and to remove unnecessary work from the steps. Within the boundaries of a step, however, there is not a lot of control. It is always better to let folks manage their work as best they can. Therefore, process orientation is entirely about defining boundaries so that you can have "process anarchy within very clear and testable boundaries." As such, processes do have performance characteristics. If you take any process of sufficient complexity and you set the steps up in different ways, there are measurable impacts. If you divide responsibilities or combine them, there are measurable impacts. The impacts may have to do with the amount of time that a work items runs through the process, or the rate of defects for the work item when it emerges, or the speed (throughput) by which the entire team can work through a set of work items and get them done. An important measurable is how satisfied the team feels with the work they are doing. You measure these things, you determine what change you want to effect, and then you work on the process, recording the results. You may end up with three or four alternative processes, each with measurable values, and you pick the one that is most in keeping with corporate values. > > The problem with process-orientation is that it tries to ignore the > whole messy business of people and what they do when they get together > in groups to get stuff done. I totally disagree. I am a Scrummaster and an Agilist. I understand the goals of XP and the Agile software movement. I would say, firmly, that XP and RUP and CMMI are each very concerned with the "whole messy business of people." At the end of the day, the only reason that a process will keep going is if everyone is happy with it and likes the results. > > I find cats tend to self-organise towards cat food when they're hungry, > for example. I've tried giving them a proper process to follow, but > they must be one of the bad shops to which you refer, because they > don't seem at all process-oriented. > > Of course, a true professional does exactly as he's told, doesn't he? > Not like those naughty self-organising cats! No one succeeds by herding cats. However, if you actually experimented with actual cats, you would find that it is quite simple to get, for example, specific measurable goals to occur (no fights at suppertime, every cat gets their fill, etc). You can offer different types of food, allowing cats to choose the bowl. You can make some bowls reachable in a way that doesn't allow the cat to return when they leave it. You can seperate the cats into different areas, so that they self-select smaller groups by personality type. There are lots of ways to work this out. As long as you know what goals you are trying to achieve, it is really quite simple and the cats prefer it. Process engineering is the most 'cat-aware' way to do it. -- --- Nick Malik [Microsoft] MCSD, CFPS, Certified Scrummaster http://blogs.msdn.com/nickmalik Disclaimer: Opinions expressed in this forum are my own, and not representative of my employer. I do not answer questions on behalf of my employer. I'm just a programmer helping programmers. --
From: jasongorman on 16 Apr 2006 05:29 Nick Malik [Microsoft] wrote: > As such, processes do have performance characteristics. If you take any > process of sufficient complexity and you set the steps up in different ways, > there are measurable impacts. If you divide responsibilities or combine > them, there are measurable impacts. The impacts may have to do with the > amount of time that a work items runs through the process, or the rate of > defects for the work item when it emerges, or the speed (throughput) by > which the entire team can work through a set of work items and get them > done. An important measurable is how satisfied the team feels with the work > they are doing. You measure these things, you determine what change you > want to effect, and then you work on the process, recording the results. > You may end up with three or four alternative processes, each with > measurable values, and you pick the one that is most in keeping with > corporate values. How fast I can run is, at best, a good indicator of how fast I can run. It doesn't tell you how long my legs are, or how effective the specific technique I use for running is. It just tells you how fast I can run. If Coke sales go up 3%, is that because of the change they made to the can, or the ad campaign they ran, or the new European VP of Sales, or the new fleet of delivery vans they hired, or the market climate, or the tiny change they made to the formula, or...? There are so many factors in team performance - thousands upon thousands - that to suggest that improvement X was down to process change Y can be deduced from metrics is to deny the complex and holistic nature of these problems. Some would then argue that we should make one isolated change at a time so we can get the feedback just for that, but this also denies the complexity and holism of the situation. No two iterations in a project can be that identical. Repeatability is an impossibility, so there will always be some random noise along with the changes that interest us. Sometimes random noise turns out to be the actual solution (e.g., penicillin), so we might not wish to remove it, even if we could. It's precisely for this reason that Agile SPI refers to "random process mutations" from one cycle to the next. > > > > The problem with process-orientation is that it tries to ignore the > > whole messy business of people and what they do when they get together > > in groups to get stuff done. > > I totally disagree. I am a Scrummaster and an Agilist. I understand the > goals of XP and the Agile software movement. I would say, firmly, that XP > and RUP and CMMI are each very concerned with the "whole messy business of > people." At the end of the day, the only reason that a process will keep > going is if everyone is happy with it and likes the results. I see that you, like me, have experienced the lure of Cat Poetry between well-defined interfaces - http://parlezuml.com/blog/?postid=148 I have two basic principles of process architecture: 1. The process must appear to work - that is, it must be possible for an effective team to succeed DESPITE THE PROCESS 2. The process must sell - that is, teams must gain a career or financial advantage by learning and pretending to follow the process (how many case studies for Method X were actually, really doing Method X?) The process of Software Process Improvement is a classic example. I have discovered that teams find a way to deliver the improvements they're asked to deliver - despite all the CMMi/Six Sigma/TQM/Systems-thinking/Theory-Of-Constraints process voodoo. And I have also discovered that you can get ahead if you have SPI experience on your CV, and that - like Scientology - it's primarily designed to spread itself before it consumes the host organisation. More controversially - as if that wasn't controversial enough - there's a growing body of statistical evidence that the ongoing quest for leaner and meaner creates organisations that lack sufficient adaptive capacity to respond when the market flip-flops - as it tends to do randomly in this day and age. Kodak are a great example of an organisation whose decades-long quest for better, faster, cheaper led to them being caught with their pants down when people stopped doing chemical photography. Tom DeMarco's book "Slack" makes a similar argument. There has to be room to react to the unexpected, and spare capacity - unused organisational DNA, if you like - to find new directions when the existing strategy suddenly becomes obsolete. The danger with incrementally getting leaner and meaner is that we can end up turning Borwn Bears into Panda Bears. I've said it before, but I believe methods are essentially cults and the rituals we go through are, in most respects, just rain dances or placebos. The real reason why quality improves or productivity increases is because teams learn to do things better *all by themselves*. They learn especially well when they have good, honest, regular feedback. More often than not, they don't even consciously realise that they're learning. The subconscious mind is vastly more powerful than our conscious minds, and can deal with extraordinary complexity and uncertainty. We're designed for an adaptive, self-organising and intuitive approach to learning and organisation. Teams - and the individual human beings working in them - build an instinct for development. They might not be able to explain why, but a really experienced programmer can probably sniff bad code a mile away. When we try to articulate it and reduce it to a set of documentation, or a training course, or an activity diagram, it just crumbles away before our eyes. Conscuously, rationally, we can't explain it - just like we can't really fully explain how we run faster. SPI should be more like gardening and not like watchmaking :-) PHEW! There, I've said it! > > > > I find cats tend to self-organise towards cat food when they're hungry, > > for example. I've tried giving them a proper process to follow, but > > they must be one of the bad shops to which you refer, because they > > don't seem at all process-oriented. > > > > Of course, a true professional does exactly as he's told, doesn't he? > > Not like those naughty self-organising cats! > > No one succeeds by herding cats. However, if you actually experimented with > actual cats, you would find that it is quite simple to get, for example, > specific measurable goals to occur (no fights at suppertime, every cat gets > their fill, etc). You can offer different types of food, allowing cats to > choose the bowl. You can make some bowls reachable in a way that doesn't > allow the cat to return when they leave it. You can seperate the cats into > different areas, so that they self-select smaller groups by personality > type. There are lots of ways to work this out. As long as you know what > goals you are trying to achieve, it is really quite simple and the cats > prefer it. Process engineering is the most 'cat-aware' way to do it. > > Obviously I would disagree :-) This is the frontier that we seem to be passing through today. The boundary between the good old-fashioned and reliable/predictable mechanical/reductionist view of the world and the exciting but unreliable/unpredictable organic/holistic world of complexity theory. I think there's more than an element of "creationism vs. evolution" in this kind of debate. I think you either believe order can be imposed on complex systems, or you don't. I don't. There's a significant body of evidence to suggest that it doesn't work (e.g., the less-than-glowing track record of BPM since the early nineties), and plenty of sound theories as to why this is the case. It's a very exciting time to be a consultant, because I've been through a crisis of faith in the approaches I've learned and now I think I'm coming out the other side of that with a better understanding of what really happens, and why things really work (or don't work). I've also got a renewed enthusiasm for SPI because it all feels shiny and new and genuinely unexplored. I fully expect to be out here largely by myself for a while (and to get a lot of flack from this post, of course - I have everywhere else!). But I strongly recommend people do their own research and reading and explore this frontier for themselves. It's not a cosy, comfortable Newtonian world - but it's more like the real world than any model I've come across before. Okay, that's enough preaching from me. Here endeth the lesson! Jason Gorman http://www.parlezuml.com
From: Bjorn Reese on 16 Apr 2006 13:21 jasongorman(a)blueyonder.co.uk wrote: > placebos. The real reason why quality improves or productivity > increases is because teams learn to do things better *all by > themselves*. They learn especially well when they have good, honest, > regular feedback. More often than not, they don't even consciously Trial-and-error can be an expensive way of learning, so an organization does not have an interest in having all its teams make the same mistakes. What means do you suggest to share lessons learnt between autonomous teams? -- mail1dotstofanetdotdk
From: jasongorman on 17 Apr 2006 10:47 Bjorn Reese wrote: > > Trial-and-error can be an expensive way of learning, so an organization > does not have an interest in having all its teams make the same > mistakes. What means do you suggest to share lessons learnt between > autonomous teams? > Crossbreeding :-) Jason Gorman http://www.parlezuml.com
From: Bjorn Reese on 18 Apr 2006 06:44
jasongorman(a)blueyonder.co.uk wrote: > Bjorn Reese wrote: > >>Trial-and-error can be an expensive way of learning, so an organization >>does not have an interest in having all its teams make the same >>mistakes. What means do you suggest to share lessons learnt between >>autonomous teams? >> > > > Crossbreeding :-) What about companies with many teams (where crossbreeding will be slow) or geographically distributed teams (where crossbreeding is expensive or even impossible)? -- mail1dotstofanetdotdk |