As part of our coaching at Rally, we usually recommend that new Agile teams use capacity as a countermeasure for not having a historical velocity. Considering individual and team capacity can help the team make an informed commitment for their iteration plan if they don’t have a historical velocity.

One general way to calculate the capacity can be seen below:

A team can use their individual capacities to indicate the maximum theoretical amount of work that each individual can complete in an iteration. Reviewing individual capacities against task estimates can help the individuals not over-commit and also help the team determine the amount of risk in committing to the stories that have been chosen for an iteration.

You can see your utilization percentage in Rally by looking at the Team Status page. As a general rule, I usually recommend that a team try not to exceed 70% of their capacity for each individual on the team.

There are many times that this recommendation is met with resistance because of the basic assumption that 100% utilization (total work divided by capacity) is the ideal state. I’m often asked to justify my general rule of 70% and asked why I would pick a number that is lower than the maximum.

Why I recommend capping individual capacity at 70%:

At a basic level, it seems to makes sense that we want everyone to run at full capacity. If the capacity exists, why shouldn’t we use it? Why would we ever want someone to do six tasks if they have the capability to do eight?

The problem with the 100% utilization mindset is that we have assumed that our outcomes of the iteration are fully deterministic.

When we consider the delivery of software, we need to acknowledge that a given set of inputs do not always result in a given set of outputs due to various degrees of variation in multiple aspects of the process (e.g. fire-fighting, estimation precision, defect introduction, management directives, interpersonal interaction, et cetera). In reality, software development activities are stochastic in nature.

If we look at other areas that are defined as being stochastic, we can build a mental model that can help us understand why 100% utilization isn’t the ultimate desirable state.

Let’s use a highway as an example…

photo courtesy of devinkho

As a few general observations, you’ve likely noticed:

• The highway typically slows significantly below 100% utilization (the maximum number of cars that can fit on the road).
• The rate at which the highway slows is non-linear. Traffic will start to slow significantly faster between 80% and 90% utilization that it would between 40% and 50% utilization.
• When accidents occur or a lane shuts down, the effect is much more significant at times of high utilization (rush hour) than at times of low utilization (late night).
• The likelihood of reaching gridlock in a fully utilized highway becomes almost certain if it fills to capacity.

These observations can all be attributed to variation in the process.

In many ways, creating software is very similar to driving along a highway. There are a variety of unknowns, a variety of random events that might occur, continuous minor corrections, and a variety of options in getting to our end goal.

Luckily, software development isn’t the only place that we can look for to get some guidance on how to effectively determine our utilization.The nature of stochastic systems has been studied in many fields (telecommunications, fast-food restaurants, transportation systems, manufacturing, processors, and many others). In many of these fields, the general approach at modeling the variation in the system can be found in the study of queueing theory.

If we look to queueing theory, we can find some level of guidance with the following general capacity model.

This model shows us that utilization in a stochastic system follows a power-law distribution.

As we reach the upper levels of utilization, the nature of the work we are performing will likely lead to intense thrashing and will likely have impact across all areas of the work that we are performing. If anything doesn’t go exactly to plan or any other non-planned items come into play, we are likely to jeopardize our commitment.

Given the rate that these items tend to occur, I recommend not aiming for 100% utilization.

Bottom Line: When I see a team of individuals that have (1) calculated a realistic capacity, (2) applied honest estimates to their tasks, and (3) targeted a maximum capacity of 70%  - then I feel good that they have done their best to provide a realistic commitment to achieving the completion of their stories for the iteration.

[ Check out more posts from Ben Carey by visitng his blog - The Sherpa Project ]

Filmed at Rally’s Agile Success Tour events, these videos detail the real-life agile implementations of software/IT executives who have taken the enterprise agile journey and are now realizing the benefits of enterprise-scale software Agility.

Our coaching and technical account teams (including Jean and myself) provided guidance to many of these panelists during their initial steps in their journey.  It gives me great pleasure to see them now become the teachers and share their expertise with the new generation of practitioners.

Don’t pass up this great opportunity to learn from the experiences of others!

Catch the next Success Tour event in Washington D.C. on July 23.
The event is free, but registration is required.

#3 in our list of the Top Characteristics of an Agile Organization is Quality and Faster.

Ryan and I have been talking about quality and faster as necessary components of an Agile organization for awhile. A non-Agile view of a successful organization would have us believe that pushing more and more features into a release and to the market necessitates a loss, or at least reduction or great variance, in quality. In an Agile organization, the thinking is quite the opposite.

Curiously, when we speak of quality and faster inside Rally or with clients, we talk about each being indispensable to the other.

For a traditional, non-Agile case study, let’s look at the RCA case study Ralph Aguayo brings up in his book “Dr. Deming: The American Who Taught the Japanese About Quality.” At its height, RCA’s business model focused on getting as many televisions into the hands of consumers as possible. (Did your family have an RCA T.V. when you were growing up? Mine did!) Quality was secondary to the savings RCA could make from cheap components and speed of product to market. Cheap and fast meant greater profits. Well, as it turned out, no…

Nipper on RCA's first color tv set - the CT 100

Unfortunately for RCA, their model began to crumble when television sets started being returned due to defects, lots of them all still in the warranty period. The cost of attending to these faulty sets ended up being as much as 25% more than the cost of manufacturing the existing set.

Do you have a similar situation in your software product delivery? Are you trying to get profits by pushing features out with “defective parts” because they are “cheaper”?

And to throw another wrench into the works, are you taking so long to get these feature sets pushed out that you have too much of a delay in your feedback to find either the defects or the value of the features you pushed? In other words, is your emphasis on speed, at the expense of quality, coupled with very large feature-rich releases, exactly the wrong way to create greater value and fewer defects?

In an Agile organization, the entire organization concentrates on value delivery and quick feedback on that value.

That is, “are we delivering the right features to the market?” In turn, a real Agile organization understands, “there ain’t no such thing as a free lunch,” and they do increase throughput without the traditional expense of decreasing quality. Defects held in check through a “stop the line” mentality free-up the organization to always respond to value feedback information faster. Think about RCA. If your scarce resources are tied up in managing defects and “returns,” they can’t be working on new feature sets. Or the feature sets delivered are being pushed on defects not yet resolved.

And so, the notion of “quality and faster” is not so counterintuitive as we may have once thought.

We need faster and faster feedback loops in time-to-market in order to continuously improve our ability to deliver quality (defect-free and valuable) features back to the market. Symmetrically, we need higher and higher quality features that are not defect-ridden or dubious in value in order to respond ever faster and more innovatively to the market.

See our previous coverage of #10 Work/Life Balance, #9 Being a Servant and Leader, #8  Sustainable and Successful, #7 Contributing to the Community and the Company, #6 Collaborative and Smart, #5 Bottom-up and Top-down Decision Making and #4 Flexibility and Rhythm. Stay tuned for #2 “Creating Your Own Reality” and Corporate Vision.

With regard to the video reference to Jim Collins, you can read the interview about his new book and his personal rhythm on the NYTimes site. Verne Harnish’s Gazelles.com teaches the Rockefeller Habits on business rhythm.

One of the replies on the Agile Alliance Group of Linked-In countered that my statement isn’t accurate - and in fact a team being both “Agile and Lean” is an oxymoron. So, I looked in the mirror and said this must not be clear. I need to communicate better in both words and pictures.

“The term Oxymoron originates from the Greek oxy (”sharp” or “pointed”) and moros (”dull”). Thus the word oxymoron is itself an oxymoron.”  Wikipedia’s Etymology for Oxymoron

Instead of trying to figure out which is sharp and which is dull, I thought I would present my mental model on the evolving Agile software development ecosystem.

Agile as an umbrella term

First and foremost, Agile as an umbrella term was hatched in 2001 to represent a “way” of developing software that is focused on rapid value delivery, collaboration with a customer, face-to-face communication and measuring progress in working code.  It casts a wide net of iterative and incremental process frameworks including RAD, Spiral, Extreme Programming (XP), Scrum, DSDM, Feature-Driven Development (FDD), Lean Software Development, OpenUP and Kanban. These methods stand in contrast to highly structured methods that tend to measure success based on meeting plans and following the process.

My rendition of the geneology of Software Development Approaches

Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.

I believe it is not a fad, but a natural by-product of the increasing scientific as well as craftsmanship approach brought to this critical industry.

Lean merges with capital-A Agile

I see the pictured genealogy tree merging Lean software development methods together with capital-A Agile methods. This is because the physics behind Lean design and production are the same physics that make Agile deliver impacts like we see in the Agile Impact Report from QSMA - 50% faster time-to-market and 25% increased productivity.

Though the principles of the Agile Manifesto do not sound like the principles of Lean, the patterns are the same. (For a great overview of Lean software do not miss Corey Ladas’ guest post on Shaping Software.)

• Small batch sizes, short cycles that create rhythm
• Reduction in queues through pull
• Reduction in work in process inventory
• Design quality in
• Stop-the-line defect control
• Value streams the link to the customer
• Integrated learning through reflection
• Last responsible moment decision making

These patterns are the same for an effective Lean effort or an effective Agile effort. This thinking has me advocating that Agile is an instance of Lean, not just a ground-up new tree that was born solely from the roots of OO, Spiral and RAD.  I am having a hard time seeing the black and white separation between agile and lean. This is all grey, maybe I should say blue and red based on the diagram, to me. 

What do you believe - is Agile is an instance of Lean, or together are they are an oxymoron?

Runners in the Loch Ness Marathon pacing themselves

So I started an ambitious training program. As time progressed and I was not getting any faster, I started training harder. Four weeks before the race I had to pull out with a stress fracture and slightly torn Achilles tendon.

As an Agile coach, I had failed to heed my own counsel.

I tell my students that the number one cause for failure with Agile development is scaling too fast. Always start with baby steps.

Looking for a better way to train, I was intrigued by Danny Driver’s book Chi Running: A Revolutionary Approach To Effortless, Injury Free Running. He says that the optimal conditions for running and the fundamentals of the method are:

• Great posture
• Relaxed limbs
• Loose joints
• Engaged core muscles
• A focused mind
• Good breathtaking technique

He says the benefits of running are:

• Great posture
• Relaxed limbs
• Loose joints
• Engaged core muscles
• A focused mind
• Good breathtaking technique
• Plus more energy!

His point? The process is the goal.

Similarly with Agile teams, the optimal conditions and fundamentals of the method are:

• Deliver highest value first
• Release early and often
• Shared vision
• Empowered collaborative decision making
• Engaged customer proxy
• Sustainable pace

The benefits of Agile are:

• Deliver highest value first
• Release early and often
• Shared vision
• Empowered collaborative decision making
• Engaged customer proxy
• Sustainable pace
• Plus more energy!

I realize now that if I’m headed the right direction with the fundamentals, I will reap the benefits without the burnout. This year I’m entered in the marathon again, but I’m going to take it easier with the training and not care where I finish in the race.

Same with Agile - get headed on the right path, pace yourself, look back often to check your process and you will achieve your goals.

The market is no longer asking, “Can we scale Agile across the enterprise and large distributed teams?” and instead is asking, “How do I get there?” and “Who can help me?”

BusinessWeek asks, “Can eBay Get Its Tech Savvy Back?”

Watch the video of eBay's Mark Carges on BusinessWeek.com

Author Douglas MacMillan says: “Carges’ plan for eBay is to take the “agile” method of software development epitomized by the daily deal widget and expand it to other areas of the site. New product pages will be customized to better accommodate different categories, such as jewelry and clothing. And the company is helping third-party developers create applications for eBay’s site such as a UPS-branded terminal for monitoring shipments” Read the full article >>

Author Note: Mark Carges was my boss and mentor at BEA.  I know a good bit about his current efforts and they are really going for it at eBay and PayPal.  It is great that their enterprise agility efforts will unfold in public eyes.

In other mainstream signs of Agile…

I was excited to see a couple of other great articles on Agile this week, including:

• Marketers often say you’ve reached the mainstream market when you notice your peers are doing it, and you feel behind enough to move. InfoWorld’s Paul Krill noted in his article Software Companies Jump on Agile Programming Bandwagon how many providers are “eager to hop on the agile development train.” (Clearly, we have an early mainstream market now.) See my post about traditional providers, including IBM, entering the space.
• Gantthead’s Bob Weinstein handily made the case for transitioning to Agile development in his article on Making a Case for Agile Project Management. He says:

“If ever there were an ideal time to make the leap from a traditional to an agile project management approach, it’s now. In this tense, uncertain, cost-cutting environment where CIOs are watching their bottom lines like hawks, the concept unfailingly proves successful. It not only delivers consistent, excellent results on time, but often under budget.”

• Finally, David Rubenstein from SD Times tackles the issue of Agile Development Built to Scale. I agree with Robert Holler that scaling anything across an entire organization is tough, and that sometimes Agile just gets a bad rap for something that is universally a challenge. It does take commitment from the team, a bit of training and a lot of inspecting and adapting to be the best Agile organization you can be.

The question these days is: how good do you want to be, by when, and who’s the best partner to get you there?

I am putting out a call for SaaS companies to share their footprint per user.

Rally’s benchmark - 8 tons of CO2 per year for every 100 users

At Rally, we have been growing steadily (227% in 2005-2007, 242% in 2007-2009) at the same time working hard to limit our carbon footprint.  Unfortunately, as a company grows, its carbon footprint often grows with it.

We have been able to keep carbon per 100 users flat at 8 tons per year for the last two years - the same amount produced by a single person flying from New York to Deli, India round trip 4 times. In addition, we estimate that our SaaS customers are avoiding an additional 1 ton per year of CO2 as compared to running an application in a robust manner in their own data center.

What is your SaaS carbon footprint per 100 users?

Lacking any other information, I used our figure - 8 tons per 100 users per year - to calculate our carbon use per 100 SaaS seats for each of our SaaS suppliers including: Google Enterprise Apps, Salesforce Unlimited, NetSuite, Big Machines, Eloqua, Xactly, and Open Air.  I assume our numbers are conservative because we are not the scale of the Google or Salesforce, and we count airline miles and employee commute in our footprint.  Can any other SaaS providers tell me your carbon per 100 users to increase the accuracy of our calculations?

Like Salesforce, we buy renewable energy credits from NativeEnergy to offset the carbon of hosted operations.  This is a very small portion of our overall carbon footprint -  about 7 tons per quarter.  However, it does a couple of things for us: 1) It supports our SaaS service being carbon neutral since 2008,  2) It keeps us learning about carbon credits at a national and local level, and 3) most importantly, it keeps us focused on our goal of zero carbon by 2020.

Do you want to partner?

In addition to our efforts to battle climate change in our industry, we are also working hard in social responsibility by following the 1% model started by Marc Benioff and Suzanne DiBianca at SalesforceFoundation.org.  Last year, we hit our 1% target of volunteer time with over 2,500 hours helping 90 charities.  This year, we are in search for a strategic non-profit partner to help us focus our corporate social responsibility efforts and volunteer time in one of three areas:

1. Reducing the environmental burden from the IT industry (carbon, e-waste, toxins, take-back efforts)
2. Decreasing the digital divide in society (universal access to the Internet)
3. Increasing the level and engagement in corporate social responsibility behaviors

If your non-profit believes it can leverage the 3000+ volunteer hours from a company in Colorado, North Carolina and the UK to help on one of these efforts, please contact us.  We are looking for a true partner who wants to start developing a relationship in 2009.

The importance of sustainability at Rally

Our efforts are based on trying to stand on the shoulders of Ray Anderson from Interface. See Ray’s Fortune interview on pushing through on sustainability in light of the current economic crisis that is radically affecting his commercial carpet business.  Since then, Google’s efforts and Salesforce’s efforts in the SaaS IT space have kept us moving forward.

We look forward to driving zero footprint data centers, increasing remote collaboration technology and having a zero footprint campus in the next decade. We are preparing a sustainability report for 2008, following the Global Reporting Initiative format.  It is not a small project, but it was the clear next step for our sustainability efforts that started in earnest in 2007.  Our goal is to release it by July 1st so stay tuned.

ADDED After Publishing and based on comments:

A better video of Ray Anderson is his speech at TED in 2009, it gives more background, and more data.  - Thanks to David Koontz

Graphic below to provide clear breakdown on sources of Carbon in our business - 6/17/09

Last week I attended the Agile Success Tour in Santa Clara, CA. I noticed 5 themes to the discussions and breakout sessions with the nearly 200 software and IT leaders in attendance.

Catch the next event in Atlanta on June 25. The event is free, but registration is required.

1. Product Owners are very important

Waterfall product marketing will find it difficult to adapt to the new responsibilities of Agile teams, unless they learn what is expected of the Product Owner. An absent or uneducated Product Owner can handicap a project before it even gets started.

2. For Agile to be successful, you must gain consensus and commitment

When rolling out new Agile teams, you must get consensus both from the team members converting to Agile and your management. Everyone involved needs to understand that growing pains will occur, but ultimately lead to higher performance. In addition, you must dive in and get started with a “burn the boats” mentality that prevents anyone from considering turning back. See Jean’s post on 12 Agile Failure Modes for more on behaviors that can inhibit your success.

3. Distributed teams, though popular, are hard to make successful

With obstacles like quality of life, cultural and time zone differences, and the drag from waiting for decisions, distributed teams pose special challenges that require Agile teams to inspect and adapt with respect to all. Team building at each location, enhancing communication, mentors, travel, group pictures, and sharing the load all help break down barriers that can prevent distributed Agile teams from reaching their potential.

4. Successful Agile adoption can help companies realize quantifiable benefits

Jean Tabaka shared how companies who are adopting Agile development are seeing significant cost savings in their development organizations with faster ROI, improved time-to-market, and increased productivity. In tough economic times, speeding up Agile adoption to help companies realize cost-savings quickly is more critical than ever before.

5. An Agile community is a valuable tool

Agile development may have simple values, but it is not always easy to implement. Capitalizing on the “wisdom of crowds” and learning from each other’s experience are key to avoiding common pitfalls.