Agile Development Blog

In the mid-1990′s, I worked on a great team (which included three members of Rally’s current technical team) as a consultant and eventually as a Director of IT at US WEST Communications in a part of the IT organization that became known at the Global Village Labs.

You can read about some of our early Intranet work in this 1995 Fortune Magazine article.  In addition to being filled with great people, we had a great leader by the name of Sherman Woo (great profile on ZoomInfo), who was a complete rebel.

Sherman, a 25-year veteran of the Bell system, was rebelling against slow IT services in the age of the 1996 Telecommunications deregulation act. To meet the rapidly changing needs of open network, he built this amazingly agile organization that leveraged Mosaic and then Netscape browsers to screen scrape mainframes using ORAPerl.

We used these agile teams of 5 to 10 people to build tools for customer service representatives and field technicians.  These were typically simple tools that bridged a couple of mainframes to build compound views that could answer really tough questions.

These questions were hard because each role was only trained in a limited scope in limited mainframes and that full training took 24 months.  So we used early Internet technology to open the access and bridge that gap with simple tools.

We made it into Fortune Magazine because our time to market was measured in months and our ROI was 1000%.  In our agile model, we delivered our first working increment to the business on test servers in a fixed time box of six weeks.  If these solutions showed value and promise for 5 users, we would run another 6-week time box and then roll the application to 50 users.  Successful projects then went on to 500, 5,000 and then up to 20,000+ users following this 6-week time box approach.  Marginally valuable applications got tabled at the end of the 5 or 50 user-demonstration time-box.

As a result, we grew the group from the initial 10 folks to the 150 person organization in IT in just 18 months.  (See the internal brochure we used to drive business to our group – (BTW, this was really fun to research on the Internet – such good memories.)

QSMA Agile Impact Report showing Agile teams 25 to 50% faster versus 7,500 other projects

50% Faster Time to Market OR 50% Less Staff?

It was all about Time to Market (TTM) for GV Labs and for most folks adopting Agile in this decade.  However, now with the cost-cutting focus of these turbulent times, we see many organizations trading off some of the TTM for cost savings.  As a result, they will use fewer Agile teams on a project and deliver a lower throughput per agile, time-box cycle.  In many cases they are using fewer people, because they have fewer people due to staff cuts.  (If you have not taken staff cuts and are wondering how to do that and maximize your Agile success, read an earlier article of mine on TechTarget – Cutting Your Way to Increased Agility and my post on Israel Gat’s Social Contract for Agile Software Development)

Of course this is a continuum of speed and these savings exist in either getting done faster with more or getting done slower with less.  You and your organization should be careful to consider the total cost and benefit of the project when right-sizing the team size to completion date. There is an optimal range for most projects and with true agile project teams you get the benefit of adjusting this based on actual performance over short time-boxes.

To gain these benefits, you have to actually become Agile and not just adopt some of the practices. Agile means dedicating you and your team to learning and continuous improvement.  We did it at US WEST in the 90′s and QSMA shows how many of our customers are doing it today.

If you truely become agile in these times, you can accelerate out of this downtrun smarter, stronger and leaner.

Further Reading:

• Brutal Prioritization in Agile: cut costs by NOT building the fluff
• Agile Cuts Costs by a  Factor of Four – or More!
• How Does Agile Deliver Time to Market Improvements of 50%?

Several weeks ago, in an interview with Dave West of  Forrester Research, Dave posed a provocative question to me.

“Do you have to be smart to do Agile?”

In retrospect, Dave’s question reminded me of an old joke: “Have you stopped beating your wife?“  In this “deeply philosophical” question, there is really no good answer. “Yes” looks bad; “No” looks worse. Answering the question about Agile and smartness could be the same. For me to answer “Yes” could be interpreted as, “Gee of course; look how brilliant I am!” To answer “No” could be interpreted as, “Gee of course not! Look at me! I’m as dumb as a doorknob!“

All jokes aside, I answered “No,” to Dave’s question and here is why.

The real question is not about individuals. The real question is, “Do Agile TEAMS have to be smart?” And to that question, I would answer “Yes.“

Agile relies on the collective wisdom of the team, not on the brilliance of one individual. I learned a lot about this, not just in my research of Katzenbach and Smith’s The Wisdom of Teams. I also have experienced it in the variety of teams in which I have worked and with the teams I have mentored. High team E.Q. (emotional quotient) is what makes Agile really hum. In fact, high team collaboration, their ability to invite and manage conflict, and their ability to create consensus, actually is the fiber that weaves the cloth of a high-performance team. High-performance teams have a collective high goal for which they hold themselves mutually accountable. It is about the team and its commitment to one another and their goal.

So, back to our title math question.

• 7 + 2 = 5 if your team mistakes collaboration as working in a “dumb down” or “group think” mode. That is not the intent of Agile collaboration or consensus. We’re an Agile team because we intend to increase our collective wisdom.

• 7 +2 = 9 if you are not gathering all the insights of all the team members to inform your decisions in your work. You are not quite yet truly Agile.

• 7 + 2 = 11 is where the collective wisdom of the Agile team raises its team I.Q. That is, the Agile whole team is indeed greater than the sum of its parts. And besides, as Spinal Tap says, it’s great to, “Go to 11!”

Further Reading:

• #6 Collaborative and Smart – Top 10 Charectieristics of an Agile Organization
• Get Serious About your Meetings with Jean Tabaka and Seth Godin
• Live from LA Success Tour: Advice on Socializing, Testing and Collaborating