Agile Development Blog

I’ve noticed a piece of advice repeated in many Agile blogs, articles, and books.

Seeing it makes me roll my eyes until it hurts. (Why I would hurt myself on purpose will be the subject of another post, on a blog reserved for psychotherapists.)

Even my very most favorite Agile book, “Scaling Lean & Agile Development” by Craig Larman and Bas Vodde, has a section in there with this advice.

I saw it in Jim Highsmith’s new book, too, although by the time he’s done discussing it he does make a couple of good points. It’s an old piece of advice that pre-dates Agile.

What is this old chestnut? Here it is:

Hire the best.

I mean, come on. Is this supposed to be a big lightbulb moment? Where do they find stuff like this, in the “Journal of the Totally Obvious?” Am I supposed to leap out of my chair, smack my forehead and exclaim “Eureka! All I have to do is hire the best! Why didn’t I think of that?”

Is this really good advice? Is it actually possible, or necessary in an Agile world? Is this sensible, if trite, piece of advice useful at all? Talk amongst yourselves while I blather on for a bit.

The problem with “Hire the Best” as an operational principle is that:

a) it immediately excludes most of us, and
b) it’s extremely difficult to do.

What’s the best? The top 5%? 10%? Certainly no more than 20%.

So what about the rest of us? What are we supposed to do? Are things hopeless for us? Should 80% of companies worldwide just give up and shut down because the top 20% of people are taken? What about big companies and the Law of Large Numbers? Can you really hire only the best when you’re hiring 10,000 or 20,000 people?

Something that makes much more sense to me, and which has much more power, is this idea:

Hire well, and develop people.

Check it out! Everybody can do this. “Develop People” is one of the two pillars of Lean, while “Hire the Best” is not. So far, those Lean folks have been right about pretty much everything, so why not this, too? Why would I need to develop people if I only hired the best? Why not save the money so I can pour it into my “Hire the Best” employment initiative?

The Agile Principles say something like […find motivated people and trust them…], and I believe in Agile. So I cannot find in the bedrock of either of my professional beacons, Lean and Agile, any indication that I should “Hire the Best”.

My common sense and experience tell me that it is incredibly hard to actually hire the best, and I like that it might not be absolutely necessary for success. How cool would it be to hire the ‘pretty good’ and then kick the butt of some company that thought it was hiring the best? Is that possible? Yes.

“Hire the Best” is really hard to do.

I’ve worked as a full time hiring manager at more than a dozen companies, all of which thought they hired the best and only one of which actually did. That company really worked hard at hiring the best. At that company, one rule of the hiring thumb was that you only hired people onto your team who would immediately place in the upper 50th percentile.

In other words, when you were on an interviewing team in that company, you were expected to vote to hire somebody who was better than half the people on your team. You think that’s easy? You think that isn’t scary? Try it sometime.

What I’m really really really interested in is something that can take my average team (and let’s face it, Ms. Wishful Hiring Manager, it is overwhelmingly likely that our team is average, for some value of average) and make it better or improve its ability to deliver value to my customers. That’s worth some effort to achieve because it is worth money to my business. If I believe in “The Art of the Possible” then I like this better, because it’s a lot more possible than simply hiring the best.

Anybody can embark on a long, expensive and likely unachievable quest to only hire the best, but if Agile were really valuable,  it would help me to take my team of competent professionals and make them significantly more effective than they were. It might even make them more effective than a gaggle of “the best” somewhere else.

The Agile Principles talk about motivated people, but they don’t actually mention “the best”.  I view this as a good thing because I strongly believe that the best teams are not built from a homogeneous mix of the smartest, fastest, bestest people.

Teams work best when they are diverse and when the power of the team can be unleashed by empowerment and self-organization. I also know from bitter experience how hard, and frankly scary, it can be to really hire the best. (Sorry if I harp on that, but I have scars…)

What I want is what I think both Lean and Agile offer to me as a businessperson. They offer me a way to take solid professionals and then ignite their passion and professionalism within a framework of continuous learning in a way that allows them each to contribute to the fullest extent possible.

That’s something that make Lean and Agile worthwhile to me, and not some lazy idea about hiring the very best (somehow) and then automatically winning.

About the Author: Alan Atlas is a Soul Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

Looking for the perfect trend article to pass on to your executives about Agile development? Check out Dan Woods‘ well-researched, executive-level article “Why Lean and Agile Go Together” on Forbes.com Jargon Spy.

Dan describes how the Agile impact in software is similar to the Lean impact in manufacturing of the 90’s.  I initially struggled with the analogy until I realized he is not saying that software development is like manufacturing. He is saying that the concepts and techniques applied in Lean manufacturing are coming to large-scale software development.

I completely agree and believe the model of how we build software is changing just like Dan describes.  Using the model from the Fifth Discipline Fieldbook, the change looks like this:

Lean Software Concept

That was a great decade – I see much of the last decade of improvement coming from a real effort to take responsibility for how we perform our craft.  The ground up work in Agile, Scrum, XP and Lean has increased velocity, increased quality and increased the quality of life for many in our industry.  I am personally in a much better working environment; how about you?

So what’s ahead for 2010?- With Agile software development hitting the mainstream, the guiding ideas on how to design and deploy software is changing for most software driven organizations.  As more teams and organization make the transition to the Agile/Lean triangle, I see us increasing our investments in skills training, teaching, experimenting and innovating with an increasing number of new tools, techniques and methods.  As a result,  I see this decade moving us past the Lean models of Toyota to something uniquely our own.  I am really excited about the improvement this decade could bring to our industry and all the industries that we impact with our software.

About the Author: Ryan Martens is a goat cheese maker,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

For 2010, lets find ways to focus on teaching our craft and growing the world of skilled software development professionals instead of trying to figure out who is “right.”

I believe much of the “Escalation” that Jean is seeing was correctly titled by Regina Mullen as a battle to be “right.” (see and read Escalation is Killing Agile – Can We Please Stop It? and Escalation is Killing our Healthy Conflict in Agile). That behavior focuses on carving up the pie instead of growing the pie.   There has been so much added to the field of software development methods, tools and techniques from the guiding ideas of Agile.  Now is not the time to stop and eat.

For me, 2010 is about continuing to grow the Agile software development pie’s reach and innovations.

I believe one of the key fixes to the problem of escalation can be found through increased professionalism and certification in Agile. By raising the bar through “difficult and skills-based certification,” as Brian Marick and the board at the Agile Alliance described, we can advance the Agile discourse through :

• a defined a bar that is deep in skill, knowledge and practice
• a significant enough bar to engage College and University study and examination
• research and curriculum that explore the tough questions in a scientific method
• development of more flexible or “T” shaped individuals that can see and work beyond silo roles.

With this back-drop, I am motivated by the notion of creating a  A Community of Thinkers,:

I am a member of a community of thinkers and I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

A Community of Thinkers creates more leadership in our profession. I see the expanding certification efforts in 2010 as great steps in these directions:

• Lean Software and System Professional – new certification emerging
• Agile Developer Certification – that is also emerging
• Certified Scrum Practitioner – especially as it intertwines with the PMI’s Agile Community of Practice

I encourage everyone in our community to figure out how to put energy toward one or more of these efforts.  The benefit of actively learning, teaching and reflecting on our work should lead us all to expanding civil dialogue that works to understand all points of view and keep expanding our thinking.  Thus broader education and difficult certification helps create a “Community of Thinkers.”  And, a Community of Thinkers will create a virtuous cycle of win/win and thus a larger pie for all.

That is my hope for 2010 in our profession.

About the Author: Ryan Martens is a happy father,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

Recently, I wrote the post “Escalation is Killing Agile – Can We Please Stop It?”  My passion around escalation brought 40+ in-depth comments.  With my travels and lack of internet access, I had been unable to sit down, sift through, and absorb all the various perspectives.  Until now.

I’m offering this follow-up post as a means to provide an overall response to all these great comments. I want to add some further background on the “escalation” topic and some more of my personal conviction around it. Specifically, I’d like to provide some insights into delayed feedback, the need for conflict, and how to “show up”, all without escalation.

In one part of the comment stream, I heard and felt the call for an effort to get to the root cause of such deep-rooted assumptions.

According to the Systems Thinking Toolbox from Pegasus Communications, to break an Escalation structure, ask the following questions:

1. What is the relative measure that pits one party against the other and can you change it?
2. What are the significant delays in the system that may distort the true nature of the threat?
3. What are the deep-rooted assumptions that lie beneath the actions taken in response to the threat?

So, in our system of sharing information in the Agile community, we have to ask, “Are we setting up a dynamic that pits us against one another?” If this is true, then we have to ask, “How can this be addressed and still ensure that we share insights?”

Guided by Systems Thinking, that means we need to check in with: what is distorting our communications and what might our deep-rooted assumptions be that would have us act as we do?

Here is an example:

I created a delay in feedback by my not responding to posted comments. I believe that created assumptions around what I may or may not have intended in the post.  I think some individuals thought I had written the post pointed specifically at them. Faster feedback would have helped quell that assumption.

I was writing about, and continue to write about, the Systems Thinking Escalation archetype and how I see it in our community. I was and am looking at a dynamic not at an individual. Escalation is NEVER about an individual; it is about the system in which blame is occurring and allowed to continue. I am fearful that blame and the win/lose game are in our system and that is what I do not like and I want to address.

Some of the comments to my post seemed to indicate that I was anti-conflict. Far from it! In studying the inner workings of high-performing teams, I have often referred to Sam Kaner’s model for participatory decision-making. Conflict is a must.

In this model, Kaner insists that, to get to high performance we must bring forth conflict to discover the best informed decisions. Divergent ideas must be invited. Divergent voices must be heard. Divergence must be allowed to just be. That is, don’t just jump to conclusions. With enough time and patience around divergence, we can then move toward informed convergence.

Conflict in this context is dialogue. It seeks insights. It invites greater and greater participation. I also want to emphasize that in this context of dialogue and non-escalation, our purpose is to engage in forward thinking. We let go and we look forward. And as we look forward, we let go.

So, as a member of the Agile community, my interest in expending energy in discussions is to seek insights, encourage divergence, and discover convergence as it emerges. All of these practices help and encourage me to create more and more forward thinking. If this is not occurring in our community, then we are not getting enough for the energies we expend.  If in our community we really “must win”  in order to “be heard”, we are stuck in an “Escalation” archetype. And, that means we are all trapped on an up escalator to nowhere.

What could any individual do to break an escalation pattern in a system? Create energy around your insights and share them without a need to apply win/lose stakes. Stop expending energy to refute others.

Here is a simple formula for bringing your viewpoint to bear without escalation:

1. Show up. (Be willing to be engaged.)
2. Find out what has meaning to you. (Be willing to be honest about your perspective.)
3. Tell your truth. (Be articulate about your insight without attacking or assigning blame.)
4. Let go of what happens. (Be courageous enough to allow others to agree or disagree.)

I believe this formula provides guidance on how to remain forward thinking, remain open-minded, and remain engaged.

I have some more mental models I want to offer here. But they will wait for another post.

Thank you in advance for your considerations, insights, and comments.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

At Rally, we are always working on both maturing and growing our use of Agile. We started with a single development team and over the past 6 years have been through the process of splitting, growing, partnering, and acquiring.

We did this while continuing to inspect and adapt our development and our strategy execution processes.  We have teams in various stages of maturity using Scrum and Kanban to run all parts of our company.   As the CTO, I have my focus on our strategic planning and execution process.

In 2008, I started to focus on maturing our annual and quarterly planning.  To do that, I used Pascal Dennis’ book titled “Getting the Right Things Done” to structure those efforts.   (See related post about Learning from A3’s a story of 2009 Quarterly Planning at Rally.)

As part of that effort, we worked to change our quarterly and annual planning process to specifically follow a Plan-Do-Check-Adjust model. (Note that I like Pascal’s use of Adjust, not Act which is typically quoted in the Toyota models.)

Prior to 2009, we were simply using an inspect and adapt process to determine annual and quarterly priorities, aka quarterly rocks, based on feedback from last quarter’s results and the corporate roadmap.

This process worked well, but we had some issues including:

• A moving definition of done based on different standards of work (research, implementation, campaigns..)
• A delay in the feedback loop on strategic efforts made it hard to check and close well
• Too many efforts in a quarter lead to poor quality (We found 5 rocks to be too many for us during a quarter)

None of these are different than what most teams experience with going Agile.  So we (1) adjusted and moved to limit our WIP to three rocks, (2) focused on inspecting the definition of done in the meeting, (3) used company wide survey’s to keep from developing group think and (4) chose to do company celebration based on quarterly metrics and not the completion of quarterly rocks.

These all helped make the current process work, but the process was still frustratingly unpredictable, semi-random and always left something to be desired.  Many of the reasons for this are explained in Alan Shalloway’s and Don Reinertsen’s posts on PDCA and types of process The Difference Between “Inspect and Adapt” and Plan-Do-Check-Act (PDCA). Unlike Alan, I do not see or perceive a big issue with Scrum.  Based on my previous post around the roots of agile; Dean Leffingwell and I are in the same camp; Scrum is Lean.

As a result of moving to PDCA approach, we created a single “True-North” goal for the year and drove our quarterly rocks  towards that goal.

Now in Q4 of the year, we had some new changes to our process. By following the PDCA cycle for the year, we put a fine point on CHECK in this final quarter; Subsequently, we have a  Q4 quarterly rock focused solely on checking our Q3 and annual work to fine tune it based on real output.  This is an example of where PDCA cycle is more intentional than basic inspect and adapt at forcing the discipline of checking.

We focused a quarterly rock on checking  to make sure that we are done-done-done with our True North goal for the year.  We also have another Q4, cross-functional rock team focused on preparing for Q1 and 2010 annual planning.  This PDCA-driven rock is a major milestone for me personally.  It moves annual planning solely from my shoulders to a team effort; this pushes ownership of strategy down to the extended management team.  As a result, I am very happy with the move to PDCA for our 2009 strategy execution process. In Don Rienertsen’s terms,  our PDCA-driven process is more defined, while still with un-predictable output and governed with lots of feedback.   This was simply an increase in process maturity that was mandated by our continuing growth.

To do this, we create a team, called the Mountain team, to help the company transition our strategy execution process.   This team steered the transition and proposed our quarterly rocks based on the PDCA process.  And thanks to the ego-less and steady hand of our CEO, we have a very collaborative culture that quickly converge on these changes and quickly put them into action.

I hope this was helpful for you to learn about our experiences with continuous process improvement and our step-function transition processes.  Please note that we are not a perfect comparison to larger organizations trying to transition to large scale agility.  In addition to doing lots of growing, we have another difference that started when we began back in 2003.  We built Agile and Lean principles into our core values.  You can see the difference this might make in my comments to Israel Gat’s post More on Agile Social Contracts.

Specifically our core values are:

• Create your own reality
• Make and meet commitments
• Theory-driven decision making
• Treat people with respect
• Support our community and give back
• Maintain a healthy work/life balance

This is the social contract that we keep with employees. During transitions like this you need culture or a social contract to reinforce your moves toward Agile and Lean behaviors.

About the Author: Ryan Martens is a telemark skier,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

I’ve written previously about my allergic reaction to process maturity models for Agile development. Based on 5 years of empirical feedback being a part of or watching what  succeeds versus falls back, I do not believe their is a “cookbook” for Agile adoption. Of course, the question then becomes:

If there is no cookbook, then what is the best approach to succeed with my Agile adoption?

Enter the crib sheet for Flow-Pull-Innovate, which is a guidepost for the key transitions in Agile organizations based on proven bottom-up success. Because the hurdles and challenges are unique for each organization and code base, this is not a prescriptive approach. It’s a framework to thinking about how to approach Agile adoption incrementally and iteratively and is essential to establishing quick wins that create a virtuous cycle of success to keep the ball rolling.

The three phases of Agile maturity are based on work by Jim Womack in his book Lean Thinking.  However,  Jean and I thought it was appropriate to substitute “Innovate” for “Perfect” in Agile organizations.  In IT/high-tech, it seems more about continuous innovation than the ultimate pursuit to “resource” efficiency.

Getting Over the Hump - Critical Step #3

Over the past 5 years, our focus at Rally has been getting our customer’s successful at Step 3, which we call Multi-Team Program Pull. (See our whitepaper on Leaning IT and moving to Program Pull.)

We focused on this step because at Program Pull, whole software products or major IT systems come to market typically 50% faster, according to the QSMA studies included in the Agile Impact Report. However, in this tough market and with mainstream Agile adoption, more and more organizations are adopting Agile at scale, making it important to light the path beyond Program Pull and into Organizational Pull and Organizational Innovate.

What do think of the crib sheet for Flow-Pull-Innovate? Do you agree with the key metrics? Are these failure signs you’ve experienced? Would your organization be willing to stand behind items in the commitment needed column?

About the Author: Ryan Martens is a trail runner,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

Last week, I ran our quarterly planning session and was very positively surprised with the results of testing Toyota’s A3 method in the meeting. Before the meeting, I was convinced that I was trying to “push” too much, but instead the team sucked them up.

Breakout groups at Rally quarterly planning

If you don’t know what an A3 or problem sheet is, I recommend starting with John Shook’s article in the MIT Sloan Management Review.

What is an A3?

John says in his article, “At Toyota, there exists a way to solve problems that generates knowledge and helps people doing the work learn how to learn. Company managers use a tool called the A3 (named after the international paper size on which it fits) as a key tactic in sharing a deeper method of thinking that lies at the heart of Toyota’s sustained success.”

An A3 is a problem sheet in which the owner attempts to:

1. “Establish the business context and importance of a specific problem or issue

2. Describe the current conditions of the problem

3. Identify the desired outcome

4. Analyze the situation to establish causality

5. Propose countermeasures

6. Prescribe an action plan for getting it done

7. Map out the follow-up process”

There is much more information on this topic on the Lean.org blog.

Introducing A3’s to the Rally team

At Rally, we started using A3’s to diagnose issues due to growth and market maturity last summer.  I hired a trainer and friend from my US WEST days Jay Arthur and focused our first effort on product marketing and product management.  In that three-month effort, we had very positive results from working 4 simultaneous A3’s and built a well prioritized backlog of countermeasures.  We knocked off the highly feasible and highly effective ones that next quarter, but we continue to work off that list today.  After product marketing and product management, we brought the technique to operations team, too.

Given this foundation and 25% of our team trained on A3’s, we brought them into quarterly planning as part of our rock prioritization process. Jean and others warned me that it was a ton to grasp in fully packed day of checking the last quarters results and adapting for the next quarter. For that reason, I was prepared to fall back to our old way of working and prioritizing.

Homework is good?

What happened was even more than I could expect. Instead of throwing out this process, the team embraced it and even worked through breaks. Using A3’s to structure your thinking requires discipline and critical thinking.  I guess there was more pull waiting in the room than I expected; maybe it was the required reading of John’s article that helped?  My conclusion – homework is good?

As Jean and I continue to explore what makes an Agile organization, I am curious as to what others are using in their business planning processes to prioritize their quarterly or annual efforts.

About the Author: Ryan Martens is an avid outdoorsman, founding board member of the EFCO, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

I have been told repeatedly that my brain thinks in pictures, and as a result I have to work hard to communicate my logic effectively in words. Recently in my argument against an Agile Process Maturity Model, I made a comment that Agile is an instance of Lean.

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?

As part of our goal to have a zero carbon footprint by 2020, we calculate our total carbon footprint each year including building facilities, travel, commuting, IT and waste.  As we get more accurate every year, we are adding in the impact of using Software-as-a-Service (SaaS) to that calculation. I have been unable to find a benchmark of other SaaS companies carbon footprints, so 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

I have always answered the question “Where does Agile not work?” with the answer: “We have customers in all forms, geographies, and technologies working in Agile. It works everywhere!“

Of course that is my Agile Convert persona coming screaming through…

In his article “Agile Processes Go Lean” on the Dr. Dobbs portal, Forrester analyst Dave West does a great job illustrating the true challenges and roadblocks in successful Agile adoption beyond the team. His research across numerous sources, collaboration with Tom Grant and ability to synthesize these concepts makes this article a must-read for executives in software development organizations.

Dave sums it up nicely:

“The problems, broadly, tend to be technical, cultural, or organizational. Technical problems relate to infrastructure, tools, and architecture, and are often the most visible of the changes involved. But many companies find the cultural and organizational issues are the hardest to resolve.”

“When a development organization uses the approach to transform itself, it often runs into problems with other parts of the company that haven’t undergone similar transformations. Clashes come with the business operations, governance, and organizational structures, among other areas. For example, hierarchical organizations may struggle with agile development’s quick, iterative review cycles and decision making.”

In the past few months, I’ve talked with Dave and Tom about the opportunities and success of large-scale and successful Agile adoptions (beyond single teams and beyond simple flow) using examples from our customers and even our own internal processes. I’m excited to see analysts tackle the meaty topic of scaling Agile and Lean with real data and customer stories.

Further Reading:

• Lean Webinar Q&A Part 3: Championing Agile
• Scaling Lean and Agile Development – Ask Bas and Craig
• What Are Your Favorite Resources for Lean and Agile?