September 29, 2005
"Agile Metrics" at SD Best Practices Conference - Boston
Just returned from Boston where Joshua Kerievsky and I gave a talk entitled "Agile Metrics: Keeping Deadlines from Killing Your Projects and Ruining Your Life."
A most lively reaction came from the audience of 100+ attendees, especially when I commented that "Agile Metrics" seemed an odd oxymoron, akin to terms like "Homeland Security", "Central Intelligence", or "Federal Emergency Management." (Couldn't resist...) But seriously, what we mean by the term Agile Metrics is actually two-fold: The first being about how to measure quickly and reliably (which you can do on your own) and the second being about gaining measurement insights into the “before and after” (think ROI), of implementing an Agile approach.
Joshua began by talking about the void in the industry when it came to productivity metrics on XP projects. To some extent, he even laid the blame at the steps of the Agile community for the absence of measures that senior managers would believe. ("Metrics? We don't need no stinking metrics.") He commented that many of the proponents of XP sought to go it alone, to their eventual chagrin, and didn't see how to collaborate with those in the field of metrics to understand how XP projects were behaving versus the status quo, and make a compelling enough case to senior decision makers who would ultimately hold the purse strings on approving an Agile initiative.
Kerievsky then went on to talk about his excitement about the prospect of synthesizing what we are able to accomplish with modern benchmarking practices that I’ve written about over the last 10+ years, and how this collaboration yielded powerful results that were clear and concise when it came to schedule and defect patterns on XP projects.
My portion of the talk gave insight into how we can quickly and reliably get a diagnostic reading on the outcomes for any development paradigm, and what we saw when we measured "before and after" an Industrial XP implementation, at a major medical devices company.
(Rather than repeat the findings described in an earlier post, you can view the results in this blogosphere. See the entry on "Reassessing XP.")
Ironically, one thing I believe we conveyed in this session was the debunking of some myths about Agile, and about software measurement.
Myth #1: Agile is another term for "License to Hack". I've heard critics of XP and other Agile methods dismiss it as undisciplined. But, truth be told, what seems like programmers running amuck is actually one of the most disciplined executions of software invention that one can imagine. It seems to me that, done properly, something like Industrial XP is more rigorous than most organizations that claim a high degree of process maturity. Tim Lister says they’re at least the equivalent of CMM Level 3.
Myth #2: Metrics is a Frederick Taylor inspired, “heavy methodology” that slows things down by detracting from real work. Yet ironically, companies that know how to use measures well, quickly gain insights into their current IT capacity, can reliably generate project scenarios using advanced modeling techniques in days rather than weeks, and are more able to respond to changes on a project, from a management perspective.
So to sum it up, we’re discovering that Agile can be highly disciplined, and measurement can be about fast and accurate knowledge about software productivity, along with accelerated decision making. In my opinion, we've only just scratched the surface on this subject.
Posted by Mike at 03:15 PM | Comments (2) | TrackBack
September 26, 2005
In Praise of Slowness
If you like the idea of Optimal Friction, the book, then you'll also love "In Praise of Slowness", written by Carl Honore.
In fact, Honore references the fact that our capitalism is getting too fast for our own good. He says, "Consider the computer industry. In recent years, software manufacturers have made a habit of rushing their products out before they're fully tested. The result is an epidemic of crashes, bugs, and glitches that costs companies billions of dollars every year."
Our research data even shows, that by doubling staff on a project, the time compresses only twenty percent. But at a severe price in defects, which rise six-fold. I call it the 200/20/6x Rule; that is, you can double your effort (200%), and get only 20% faster speed, but suffer 6x the defects.
Like "Optimal Friction," the book "In Praise of Slowness" has a prescriptive cure in one word: Balance. IPOS says that people are discovering energy and efficiency where we may have least expected - in slowing down. But this is no Luddite call to throw away our Blackberries, laptops, and cellphones. It's a way of saying "Slow is the New Fast."
In Optimal Friction, I'll set out to prove that.
Posted by Mike at 11:35 AM | Comments (0) | TrackBack
September 23, 2005
Climbing El Capitan
Some years ago, I had the privilege of traveling to Tokyo, Japan to give a 2-day workshop on software development management. It was a blast. I had a bank of interpreters that translated my talk into Japanese, which made it all the more unusual.
On the way, I had the good fortune of having United Airlines seat me in the middle of another group traveling from NYC. It was the Mostly Mozart Festival Orchestra at Lincoln Center. Shecky Ballantine (one of their cellists) and I struck up a great rapport. I got to go backstage at the Bunkamura Music Hall during the concert, and afterward, we all went out for sushi.
Apparently, being a world-class musician isn't just about sushi and late-night fun in Tokyo. I was surprised to hear that it can be quite grueling, with all the rehearsals and travel. In fact, it's so demanding and there is so much tension between the musicians and management, that the musicians formed a labor union. Imagine that! Seems like the general public only hears the music. Backstage it's a different story.
By far, Shecky had the most interesting method to reduce his stress and cope with the rigors of his job: In his spare time, he'd rock climb the face of El Capitan in Yosemite Valley. Shecky said he tried to do this every year. It was how he kept his sanity. (For the record, El Capitan is the largest granite monolith in America, and rises over 3,593 feet from the valley floor - 3 times the height of the former World Trade Center.)
Anyone interested in trying this out?
(By the way, I spoke to another climber who regularly rappelled El Capitan. He claimed that he believed many of his fellow rock climbers were actually drug-addicted to their own adrenaline and endorphins. When he wasn't hanging by a thread at 3,000 feet, he felt depressed. Interesting...)
Posted by Mike at 11:24 AM | Comments (0) | TrackBack
September 22, 2005
Yosemite Climbing
Posted by Mike at 11:14 AM | Comments (0) | TrackBack
September 19, 2005
Tools Stimulating Change
Do tools drive change in process, or should process happen first, which then drives the organization to implement tools?
This is a question I get asked frequently. My answer is both; however, I believe that the best tools allow organizations to still use what they're comfortable with, and offer a framework that a user can adapt at their own pace. This would be the case regardless of whether the tool being considered is SLIM, Seer, CostXpert, Cocomo, Price-S, or any of the widely available commercial measurement and estimation models.
For example, many estimating tools force a paradigm change that requires managers to fit their way of doing things into the tool. I believe that this is a roadblock that actually prevents change. Managers wary of new methods are risk averse. They'll likely procrastinate using a tool because it is too risky to change how they estimate with so much at stake. Defending the tool estimate is risky because one has to be able to explain all the assumptions and the end results. An example of this is when someone is forced to size the project using function points.
Rather, I like to think that the best tools allow managers to transition at their own pace - fast or slow. They enable one to produce a scnario BOTH ways, and then compare. It's even better when a manager can prepare a project plan using "their way", then having the tool recreate that plan, essentially "cloning" it, and extending the plan by offering a benchmark of say, the deadline, against industry, or deriving the implied productivity.
That directly allows for people to achieve a comfort level at their own pace.
Posted by Mike at 10:17 AM | Comments (0) | TrackBack
September 16, 2005
Why This Blog...
Recently, a few colleagues have asked about the genesis of this blog. As a result, I wrote the following "About..." profile that gives an overview of what I see as its purpose. It's been sent to our blog architect folks for permanent inclusion on the sidebar, but I thought it important enough to post right away for those who might be interested. So here it is...
--------------------------------
About Optimal Friction
This blogosphere began as my idea to create an online community that could share thoughts about work life in the Information Age - to create better outcomes for teams on high-pressure projects in high technology. It also emerged out of our collective experience that the rapid speed of the Internet Age was largely the “fuel” behind an epidemic of conflict in the technology industry, as many researchers have described. (This is similar to the notion that warm temperatures in gulf waters can often fuel the emergence of powerful hurricanes.)
I find myself in the interesting position as an observer with two lenses through which I view work life in the modern era: one trained in high-technology and another people-intensive side, as one who facilitates negotiations and mediates disagreements on deadline-intensive projects as a management consultant and executive coach. Moreover, the friction I’ve observed seems problematic in all industries, especially when difficult software projects are the norm and not the exception. I’ve been fortunate that my work has taken me into numerous client organizations ranging across medical/scientific applications, telecommunications, avionics and flight controls, military weapons systems, real-time embedded systems, systems software and middleware, IT billing and transaction processing, and financial services. I’ve discovered that this pattern is prevalent everywhere – time pressure is the universal catalyst.
Given enough time, most conflicts among people, teams, and companies have a reasonble chance at finding resolution. However, when placed under the vice-like pressure of harsh deadlines, conflict frequently erupts. People’s inherent mind-set and behavior seems to change dramatically under time pressure. An illustration of this has been observed by author Malcolm Gladwell in his book, The Tipping Point. In his account of a controlled experiment, roughly nine out of ten theological seminary graduate students at Princeton University who are “running behind schedule”, neglect to help a person (played by an actor) writhing in pain alongside a path between lecture buildings. The punch line was that the students were on their way to give a talk on parables of moral significance, including the story of the Good Samaritan.
Furthermore, it is clear that the acceleration in the world is not decreasing, but increasing dramatically, on a global scale. A model of this acceleration is offered by someone I also admire greatly, a physicist and futurist named Peter Russell.
Peter explains: If the whole timescale of evolution were represented by a 108 story skyscraper (Peter used the former World Trade Center as an example), we can say that the street level would represent the formation of Earth, 4.6 billion years ago.
In this model, complex cells arrive on the equivalent of the 70th floor. Crustaceans and fish arrive between the 94th and 97th floors. Dinosaurs on the 104th to the 107th. And mammals arrive on the top floor – the 108th. Homo erectus walks on two legs at about a few inches from the top floor. And the entire period of human history from the Renaissance to the present day occupies the top one-thousandth of an inch – less than the thickness of a layer of paint.
Now, from a population perspective, we’re also in a super-exponential acceleration curve. It took 7,000 years from the beginning of man, for the planet to reach 1 billion people. In the last 1,000 we’ve multiplied that six-fold. Just beyond the year 1900 (when my grandfather immigrated to America), the world had about 1.6 billion people. When my father was born in 1940, the number grew to 2.3 billion. At my birth in 1960 the figure was 3 billion, and today it stands at about 6.4 billion people. From the Earth’s perspective, in just my own nano-second lifetime, people on the planet have more than doubled, with over 3 billion more souls alive today than in 1960. Experts believe that the total number it may eventually top out at about 10 – 12 billion perhaps about 90 years from now.
To sum it all up, not only are things accelerating rapidly in this world, but it’s fast becoming more crowded, very quickly. That - in and of itself - will fuel conflict as more and more people compete for ever scarcer world resources.
I believe that one of the challenges for high technology is to help address the problems of humanity. Whether that means curing sickness, creating reliable communications, solving energy production/distribution problems and transportation needs, repairing the environment, providing enough food for the people on the planet – all are worthy causes that demand us to efficiently create solutions. To do that, I believe we have to effectively solve the problems of friction and conflict within the technology industry itself so we don’t waste our time with costly rework and destructive infighting.
I am hopeful and optimistic that this can be done. Many of the ideas shared on this blog are intended to stimulate the conversation about how this might happen. Some of these ideas have already been explored by remarkable people whom I respect, and I welcome all to join this dialog. Many of my ideas I plan to pre-publish for feedback as part of an emerging book with the same title as this blog, Optimal Friction. From time to time, excerpts and chapters will make their way to this forum for your comment and feedback.
Michael Mah
Posted by Mike at 04:14 PM | Comments (0) | TrackBack
September 13, 2005
Short Lists
I just came across an interesting article by Steve Andriole, a professor at Villanova. In it, he talks about an experience where he presented his Top 10 CIO objectives to his then-CEO. The CEO cancelled the meeting, and told him to come back when he narrowed it down to his Top 3. Ten items were too many, he said. As in the movie "Amadeus", the symphony can have "too many notes" for the Emperor's ears.
With that, Steve came back with these three priorities: 1) Get the overall technology investment strategy right. 2) Get the infrastructure right, not just in the short-term, but longer-term. 3) Get the people right. Do we have the right people -- given the overall technology investment strategy and the infrastructure?
Steve asks, what would your short list look like? I thought about that question for high-pressure technology projects, and I came up with these: 1) Get the deadline right. Is it too short, too long, or just right? 2) Get the scope right. Have the teams taken on too much, too little, or just right? 3) Understand our capacitity/productivity. What is it given the complexity of what we build? Have we planned beyond your capacity?
Truth be told, I confess to knowing that these are loaded questions, primarily because the definition of "right" versus wrong is a matter of perception. Most IT organizations have little data on their deadline performance and productivity, so it stands to reason that their deadlines and scope commitments are largely shaped by (mis)perception. But asking the questions starts a dialog around the risks associated with these commitments.
Thos are mine and Steve's. If anyone has their versions of a short list, feel free to let us know.
Posted by Mike at 04:39 PM | Comments (0) | TrackBack
September 10, 2005
Cutter Council Opinion on XP
The Cutter Technology Council has weighed in with their opinion on Extreme Programming (XP). The "Assertion" is that XP has "come of age". I recall that, during the initial years, many sniffed at it with only mild curiosity. A common phrase was that the approach was "good for 'pond-bridges', but maybe not for 'large-scale suspension structures.'" Most SEI-centric organizations still saw moving up the CMM scale as the way to reduce cycle time, costs, and defects. You can see a PDF of the council opinion at www.qsma.com.
The Council is like an IT Supreme Court, with opinions of concurrence with an assertion, or dissent. They are among the leading thinkers of our industry.
Therefore I was impressed with the fact that all of the members cast their opinion on the "concurrence" side of the assertion. Fascinating that Josh Kerievsky, contributor along with myself on this opinion, gave a "partial conurrence." That can be read as a partial dissent. This is notable since Joshua is the creator of "Industrial XP", that is, XP for large-scale applications.
As far as the metrics are concerned, my findings of "before versus after XP" on time, cost, and defects at a major medical instrument company were significant: 25 percent improvement in speed, with a four-fold reduction in defects. Time will tell if this is repeatable, as we get more data.
But what really got my attention was that defects fell so dramatically in spite of relatively large sized teams. Normally this doesn't happen. More people on a project always results in more defects. It didn't happen here. I think it's because of co-located client/developer teams along with paired programming. I'd be curious to hear what other people think as more data comes in...
As I said in the text of the opinion, "stay tuned..."
Posted by Mike at 05:39 PM | Comments (1) | TrackBack
September 07, 2005
Extreme Programming - Productivity Metrics
Tom DeMarco recently called. The Cutter Technology Council is issuing a Council Opinion on Extreme Programming. I find these Council reports extraordinary. The format is like a U.S. Supreme Court position, where the topic at hand is invited for concurrent or dissent by the group. I find myself always wanting to hear how folks like Ed Yourdon, Tom DeMarco, Rob Austin, Ken Orr, and others weigh in on a major topic in IT today.
Tom asked if I would contribute a section on the productivity measures observed on XP projects. I plan to discuss "before" and "after" metrics from an actual company in the medical industry in the August Council Opinion. I compared cycle time, effort/cost, and defects in non-XP and XP projects against medical/scientific applications in our database of 7,000+ projects. Inquiring minds want to know... Enough of the "fluff": what do actual numbers say?
By the way, I'll be co-presenting this case study at the SD Best Practices Conference in September with Joshua Kerievsky, fellow Cutter author and XP expert. Come to the show!
Posted by Mike at 03:00 PM | Comments (0) | TrackBack
September 05, 2005
Deadline Dynamics
Ahh.. it's good to be blogging. I thought it wise to get things going by taking straight aim at a central issue that, for me, is at the essence of social and organizational dynamics in the Information Economy: Time Pressure.
In fact, time pressure is so omnipresent, I feel it's the driving force behind all things good and bad around the subject of work for those of us in the field of software and information technology.
Truth be told, it's embedded within the essence of my upcoming book, Optimal Friction. As a technology professional originally trained in electromagnetic physics, electrical engineering and later, conflict resolution and mediation, I intend to take a very unusual spin around this subject.
Let's start with this fact: The scarcity of time drives we humans to do strange things. One example by Malcolm Gladwell in his book, "The Tipping Point", tells the story of a time pressure experiment at the Princeton University Theological Seminary. At this school, people study to become ministers. The story of the experiment goes like this: two groups are told to give a lecture at a campus auditorium. One by one, members of a group are to make their way from building A to building B and give a lecture - a sermon - on a biblical theme. Members of the first group are told to head over to give their talk, one at a time, without any time pressure. The second group is given the same instructions, except they're told that they're running a little late, and to move quickly.
Between the buildings, an actor is "planted", writhing in pain alongside the pathway. The question arises: How many of the students stop to help the man lying on the ground? The first group - about 60 percent.
How about the second group? The ones "running late"? About 10 percent.
The punchline: the topic which they're about to give a lecture on - is the story of the Good Samaritan.
The point that Gladwell makes is that context within which we find ourselves MATTERS. It’s so powerful, that even future ministers who are tasked with sermonizing on helping others, would leave a person lying on the side of the road.
Similarly, my contention is that we professionals in the information economy are doing the moral equivalent. Under time pressure, all of us, executives, project managers, designers and builders alike, are leaving bodies on the side of the road. Lots of things are being set into motion within companies and between companies, that I welcome all of you out there to ponder. Enough blathering for now; the blogging can take it over from here. Tell us what you think about Samaritans… Welcome to the party.
Posted by Mike at 03:30 PM | Comments (0) | TrackBack