Agile Development Blog

I have a friend who was my Engineering Geology Professor and his name is Bernard Amadei.  Bernard found his “good work” right about the time I was starting Rally.  Bernard has a wonderfully friendly manner and a great French accent.

In early 2000′s, he took a trip to Mail to help a village engineer a solution for potable water.  Upon his return, he started working on Engineers Without Borders, which is now a movement.  At the beginning of this work, I collaborated with Bernard as he started the chapter at the University of Colorado and wove it into Bioneers.

At that initial collaboration, Bernard said he was forcing engineers to ask the question, Why? So often engineers just focus on how and what.  He was starting Engineers Without Borders to help give engineers a stronger sense of purpose in solving the world’s systemic problems. (Please see the YouTube video)

Bernard and Paul Hawken had a huge influence on me as I worked to draft the vision for Rally. You can read about my thoughts on the purpose of Rally on my Agile Commons profile page or listen to my BlogTalkRadio interview.

Without a clear vision and mantra , it is hard to answer the question, Why do you develop and operate software?

As you and your software team/organization undoubtedly ask the core versus context questions in your business, I have been providing thinking tools for analyzing your portfolio in these turbulent times.  As Israel Gat pointed out in his recent post, “Can you afford the software you are developing?“

You do not need to take a long time to do this work, but it does provide a checklist of things to ask before you decide what product/code lines you might STOP DOING:

Things to ask before you decide what to stop doing:

1. What are your core values and vision?
2. What is your core purpose – Why? (this post)
3. What is your receipt for sustainable shareholder value?
   
4. What is your approach for getting your software organization leaner and getting stronger in 2009?

Once we have taken all the costs savings from distracting/mis-aligned efforts out of the portfolio, it is time to figure out how to increase the performance of your software development organization.  Jean and I will dedicate most of February to making the “Agile development cuts costs” case for groups that are working on core/mission critical efforts.

While you think about those arguments, I ask you to reflect on Bernard’s point:

Have you found your “Good Work?” and does that match up with your core work?

Today at Rally, we completed a redesign of Agile Commons and changed a number of other things in our online communities.   As a result, you are now receiving RSS updates from the AgileBlog instead of the Commons Blog in Agile Commons.  If you would like to continue following RSS feeds from Agile Commons, please take a look around the redesign and subscribe inside the Commons.

To understand all the things we are doing with regard to this blog and Agile Commons, click on More.

(more…)

I have linked to Israel’s work before and I have seen him talk about the social contract that he made at BMC in 2006.

However this new post and the attached slide share decks give the seldom-heard whole story. Israel has also provided a new introduction with a solid historical as well as current context; this makes the social contract concept even easier to apply in today’s turbulent times.

This post hits the heart and mind of leaders of Agile teams.  I have responsibility for our product development and operations teams at Rally.  This post caused me to find ways to double my efforts to lead our team from “within” as we are expanding with a new office/team as well as continuing down the flow-pull-innovate road of agile expertise.

Check out some of Israel’s other great work by visiting his blog, The Agile Executive

Side note: Many people love to give folks that live in Boulder, Colorado a ribbing about spiritual “woo-woo” focus (home of natural food including soy and herbal tea, Naropa Insitute and plenty of hippies).

I think many skeptics like to give that same line to folks who talk about the “people” side of effective Agile enterprise adoption.

Israel’s post is all about managing and leading the team – without this kind of leadership you will be destine to always remain an Agile amateur. Think big about your Agile adoption, but also think big about your personal journey to this level of team leadership.  Everyone wins on this journey and this posts keeps you on the rails, especially in these times.

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

2008 was a very good year for Rally, the Agile development movement and me personally.

At Rally, we measured ourselves by winning the third consecutive Jolt Product Excellence Award and delivering 6 product releases to a fast-growing list of great software-driven companies.

We leveraged our Agile and customer community and new products to deliver feature priorities based on our customer’s feedback and votes.

With the help of QSMA, we benchmarked that Rally customers are 50% faster to market and 25% more productive than industry averages.

On the local front we were named one of the best companies to work for in Colorado as well as awarded the Affiliate of the Year by the Entrepreneur Foundation – these are awards we strive for and help us validate we are building the type of company that can endure.

You can see the customer and financial growth that resulted from these market achievements in an announcement we issued this morning, or you can go to the Rally by the Numbers page on our web site to see the transparency we use to communicate our progress.

On the Agile industry front, the Agile Alliance had a blow-out conference in Toronto in 2008.  It was the culmination of my two years on that board and a very fulfilling experience.

We also saw this market grow with new customers and a host of incumbent as well as new competitors.

The Agile tools and applications market became real and Gartner put out a market map as a prelude to a magic quadrant; good news Rally was ranked in the “Positive” category.

What key performance indicators (KPIs) do you use in your business, and how will you improve or adapt them in 2009?

At Rally, we’ll be busy doubling our efforts to make our customers successful with Agile and effective on both prongs of short-term efficiencies and long-term growth.