- Deb one way to remove the threat of utilization harassment is to reduce the number of hours in an FTE. Many schools of thought think this is a good idea as itMessage 1 of 41 , May 1, 2006View SourceDebone way to remove the threat of utilization harassment is to reduce the number of hours in an FTE. Many schools of thought think this is a good idea as it helps you get to a better understanding of how much time you really have.I prefer to rely on the education people's parents paid for to make adjustments in the amount of time professionals estimate it will take things to get done. But please remenber that I also demand that estimates be viewed in their true light. WRONG! of course they can get better but they will never be right, elsewise they would not be estimates.I am even being persuaded (by some very smart people who beat me with heavy practical thoughts) that estimates should be driven by the cone of uncertainty and that their wrongness be projected over the life of the task.Mary's comments about the evils of utilization are well founded but will only be overcome when people stop given stupid responses like "yea sure we can do that" when no one has the slightest idea what "that" is and start promising to give estimates that reflect the quality and completeness of the description of the task. We will know that utilization demons have been exorcised when we commit to not agreeing to a delivery without having some idea what we are being asked for.Finally, when we - as a community - begin laughing at the fools who rush into the meeting demanding a full resource and utilization plan so they can sit down and develop a budget yet are unable to even tell you what it is about. When we start taking responsibility back for what we allow to happen to us then a lot of things change.I rant no more.--
Perseverance is not a long race; it is many short races one after another. ~Walter Elliott, The Spiritual Life
The greatest oak was once a little nut who held its ground. ~Author Unknown
-------------- Original message --------------
From: "Deb" <deborah@...>
> Well, yes.
> The point of our sim is that when we organize around value we can
> produce more. When we organize around utilization, we get stuck
> because 100% "busyness" seems to signal no change needed (or worse:
> more people needed - a total red herring). Our third iteration happens
> to have utilization near 100% but that's not what we are measuring. In
> that iteration we aim to maximize completed "products" i.e. customer
> Good point though: I'll make a note to mention slack directly during
> the sim :-) and to be sure that production of value is underlined as
> the aim of iteration 3!
> thanks, Mary
> --- In firstname.lastname@example.org, "Ma ry Poppendieck"
> > Deb,
> > I still don't understand what you are trying to measure.
> > Utilization is a poisonous measurement and attempting to achieve
> > high utilization is one of the most sub-optimizing practices there
> > is. Slack time IS NOT WASTE, it is required for rapid delivery, and
> > because of this it underlies the ability to deliver high quality.
> > This is not to say that you need to have low utilization - it is
> > only to say that attempts to maximize utilization are virtually
> > guaranteed to decrease it.
> > If you were an operations manager and tried to optimize the
> > utilization of your servers, you'd get fired. Development managers
> > who try to optimize the utilization of their people have no sense of
> > queueing theory, or p erhaps think that the laws of mathematics do
> > not apply to them. They are wrong.
> > --- In email@example.com, "Deb" wrote:
> > >
> > > My question about utilization stems from my understanding of the
> > > difference between efficiency & effectiveness :
> > >
> > > "everybody busy?" doesn't tell you much about how well you are
> > > delivering value.
> > >
> > > In our sim, iteration 1 has specialists very busy in a waterfall
> > > producing pieces of things customers don't value because they are
> > > incomplete. In iteration 3, *generalists* are very busy producing
> > > little waste and 3x the customer value in the same space of time.
> > >
> > > In this thread, in fact the writer was measuring "% of busyness
> > > applied to sprint w ork" which is quite different. That's what I
> > wanted
> > > to know :-)
> > >
> > > deb
> > >
> > > --- In firstname.lastname@example.org, Ron Jeffries
> > > wrote:
> > > >
> > > > On Sunday, April 30, 2006, at 1:57:46 PM, Deb wrote:
> > > >
> > > > > What exactly do you measure to track utilization?
> > > >
> > > > > I'm wondering because I'm currently working on a sim about
> > metrics
> > > > > where both scenarios A and C have high utilization (people
> > busy close
> > > > > to 100% of the time) but A produces 2 finished products during
> > the
> > > > > time that C produces 7.
> > > >
> > > > Tell us more about what's going on in this sim? What's causing
> > the
> > > > difference in productivity? What insight into the sim would you
> > like
> > > > to have that you don't have?
> > > >
> > > > Ron Jeffries
> > > > www.XProgramming.com
> > > > Learn the principle, abide by the principle, and dissolve the
> > principle.
> > > > -- Bruce Lee
> > > >
> > >
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to:
> Yahoo! Groups Links
> <*> To visit your group on the web, go to:
> <*> To unsubscribe from this group, send an email to:
> scrumdevelopment-unsubscribe@yahoog roups.com
> <*> Your use of Yahoo! Groups is subject to:
- Hi Pablo, ... exactly the opposite of the essence of Agile s good engineering practices. I did not propose any Agile operations in my post. I simply andMessage 41 of 41 , Feb 23, 2009View SourceHi Pablo,
> The "agile operations" you seem to propose would, in that sense, beexactly the opposite of the essence of Agile's good engineering practices.
I did not propose any Agile operations in my post. I simply and emphatically wanted to make clear that ITIL and COBIT are neither Lean nor Agile, and have no orientation or basis on these principles. Colleagues who have been contracted to implement ITIL have been educating their customer on Lean and are using Lean principles to define the what and how of ITIL. That approach is great for their customer, however it is quite unusual as ITIL is implemented to provide centralized control and limits on change.
The analogy to CI does not make sense. Are you equating the work orders we had to complete for db changes to CI?
The Lean model for handling operations is much more efficient and effective than the ITIL set of practices. Interestingly the WIKI entry for ITIL says that it is based Edwards Deming, however I don't see the connection. A Lean solution will involve a lot more automation code, more visibility, less control, and thoughtful responses to outages to mistake proof operations. ITIL tries to stop outages by imposing control to reduce firedrills. It is treating a symptom - firedrills.
Now having said all that, I would start with lean principles, a value stream map, causal diagrams for key incident areas, and Scrum or Kanban to handle service requests. I would organize a process that pushes decision making down, and allows teams to find solutions to vexing operational problems. I would read ITIL for ideas that I can use to help support Lean principles, and be very cautious about practices that remove decision making away from those with the most information to resolve the issue.
What is interesting is the history of ITIL, and the power struggles around its formation. Why would that be?
Robin.On Fri, Feb 20, 2009 at 9:27 PM, Pablo Emanuel <pablo.emanuel@...> wrote:Robin,first of all, as Paul wrote, there's nothing on ITIL that is essentially contrary to Agility, although no framework is immune to bad implementations. On a deeper level, however, ITIL is about service management, i.e., operation, and Agile methodologies are about projects.From an operation standpoint, changes are the source almost all operational risks, while, on the other hand, there's no improvement without changes. So, one of the key issues of any service management framework is how to control changes in a way that it doesn't paralyze the improvements, yet doesn't let them jeopardize the operation stability. The analogy within the software development world is the continuous integration tool, that guarantees that the changes commited to the codebase are under the nightly build control, so one's able to easily track the offending change and restore the codebase's stability. The "agile operations" you seem to propose would, in that sense, be exactly the opposite of the essence of Agile's good engineering practices.That said, I can't see the relation between ITIL's change management process and the service metrics that have been asked for on the original message.Regards,Pablo Emanuel2009/2/20 Robin Dymond <robin.dymond@...>Hi Hank,
Don't waste your time with ITIL or COBIT if you value Agility. Neither of these S&M organizational bondage frameworks offer anything other than Grief and Bureaucracy. I know as I have had the unpleasant exercise in navigating the organizational stupidity they brought to a large Fin Serv organization that atempted Agile. Colorful language aside, it is in the blind application and locally optimized implementation of these frameworks that realy drives waste in the org.
A small example: development teams not allowed to make changes to development databases! Not kidding. Change control process and handoff for any server in the CMDB. Just brutal. Cause huge delays, and the db etam making the changes were _completely_ disconnected from the teams. If they made a mistake, back into the work order cue you went.
I would look far and wide for alternatives that are based on Lean Agile, or create one myself based on the lean agile principles.
Hope that saves you some time and pain.
Robin.On Fri, Feb 20, 2009 at 2:22 PM, Ryan Shriver <ryanshriver@...> wrote:
Hank,Thanks for the additional detail. I'm not sure that I have all your answers, but perhaps I can point you in some directions.From an outside-looking-in, start simply with Availability. This is the most important quality. There are varying ways to measure this, uptime is the most common. Following Availability I'd argue is Throughput (workload capacity of system under defined conditions such as normal or peak). Closely related to Throughput and third would be Response Time - what's the latency between request and response under defined conditions.I wrote a blog post about how to quantify Availability, Throughput and Response Time here:http://theagileengineer.com/public/Home/Entries/2008/11/7_The_3_Key_Performance_Qualities_for_all_web_systems_(Part_1).htmlYou can't leave out Security, so it may pre-empt some of the qualities above. Security can be a complex quality with multiple legitimate measures (access, authorization, encryption, integrity, etc.). Other qualities you may want to consider:- Recoverability - How quickly your team can response to a defined situation (power outage, hard drive crash)- Scalability - How easy or hard (expensive) is it for your system scale to meet new demand?- Maintainability - Another complex quality including efficiency of adding new features, resolving issues, isolating bugs, etc.- Reliability - Mean time between faults- Usability - How efficient is it for your customers to do their Top N number of transactions? Do they enjoy the experience? How much does it cost to train new users? Likely another complex quality.For further reading online, try www.gilb.com and search for any of these terms - you'll find a wealth of information.-ryanOn Feb 20, 2009, at 7:46 AM, Hank Roark wrote:
Robin Dymond, CST
Managing Partner, Innovel, LLC.