Agile Development Blog

Managing the right goals in software development can have a major impact on your team’s success. You get what you measure. In this regard, the goals you choose can be a defining factor in whether your organization’s Agile adoption thrives or dives. So, what are your choices?

A story about goal-setting

Imagine you are a runner. You have a running coach defining targets for you. Your coach chooses miles and seconds in order to measure you. These metrics turn out to be useful; they are universally understood by you, your coach and your competitors. That’s a good thing. A target goal exchange around these metrics might look like the following:

Coach: “I need you to run a 2-minute mile.”

You: “Uh, I’m not sure I can do that. In fact I don’t think it has ever been done before by any land animal other than a wildebeest, a pronghorn antelope or a cheetah. And, I’m not a wildebeest.”

Coach: “You’re not listening. I already told Sports Illustrated you will. Don’t make me look bad.”

You: “Seriously I’m pretty sure that’s just not humanly possible. I’m no Usain Bolt and I’m not sure even he could sustain a 2-minute mile.”

Coach: “Hey, I set the goals. Run that mile in 2 minutes. Just hunker down and work harder. 2-minutes is the target goal. If you don’t meet it, I’m kicking you off the team.”

You: (muttering under your breath to self, “I can’t do it, you aren’t listening to me, and you are a moron. Why do I even bother to open my mouth?”)

Why goals matter

Get the idea? I’ve been reading John Seddon’s Freedom from Command and Control: Rethinking Management for Lean Service. My colleague Alan Atlas recommended the book. Then my manager Ryan Martens became very interested which led to a book appearing on my desk. Soon after, Karl Scotland mentioned it in an informal conversation about Lean and Kanban. Time to pop it to the top of my reading stack!

Seddon sets a context about Purpose driving Measures that then drive Methods. The combination of purpose and measures start to look like goals. And Seddon breaks goals into two types: Target Goals and Capability Goals. While John’s book is not specifically about software, I could see how we use and abuse goals in our software world. So I decided to delve deeper.

Target goals are arbitrary and doom-laden

Target goals are set to measure hopeful results, often an arbitrary number. Think about our runner story and the 2-minute mile. That target goal was  set by someone else. A target goal typically does not account for your strengths, capabilities , availability and skills. Target goals don’t serve you. They don’t serve organizations either. And yet we cling to them. Consider if, as a developer, I hear the following from my manager:

“Jean! You missed the release deadline we gave you. We told marketing and sales who then told our customers that dev would deliver this specific functionality on this specific date. You’re ruining everything. We’re doomed I tell you, doomed! And all because YOU didn’t hit YOUR deadline.”

Uh, it wasn’t my deadline. And yet, missing that goal is now rippling negatively through the organization. This is a lose-lose situation all due to expectations hinged to an arbitrary target goal.

So why do target goals exist?

In many hierarchical, command-and-control software organizations, target goals are how deadlines are set. As Seddon points out, use of ineffective target goals usually arises due to an impossible purpose coupled with non-value add methods. The measures (or goals) are meant to drive teams to the impossible purpose. A command-and-control organization believes that goals must be set top down. The negative impact of these goals is inextricably woven into unrealistic expectations, death marches, and non-value add methods for controlling the work toward the goals.

Enter the capability goal

Let’s replay the runner scenario again.

Coach: “There is a race coming up, a half marathon. That means we need to start training now. What is your time currently?”

You: “I haven’t been really running lately. Rather than guess my times, I’ll start running now. Do you want to know in terms of how long it takes me to run a mile, or how far I can run in a specific timebox?”

Coach: “Let’s start with how you finish a mile. What is your typical way of getting going?”

You: “First, I do a walk/run combination. Then I can give you my actual mile capability in a week.”

Coach: “Okay, let’s set up a plan and together set some sort of goals based on your capabilities. That will help me guide you and figure out when we are faltering. I know you can do this. I’m going to work with you starting right now.”

You: (muttering under your breath, “This is amazing; yea me! I am going to finally put my passion for running to work, keep improving, and run my first half marathon. I love my coach!)

Capability goals are based on real data

Together, the runner and the coach watch the capabilities of the runner to define goals. The purpose of the goal is clear. Measures are set up that usefully help determine the runner’s progress. The method (or running regimen) for attaining the goal is then applied. Simple.

We use this same approach in Agile teams. A team lead or project manager does not set an arbitrary target goal. Rather, the Product Owner sets an overall purpose/vision. The Agile lead, often referred to as the ScrumMaster, works with the team to assess what goals can be reached based on a team’s capabilities and availability. From iteration to iteration, the team provides feedback on what it is able to complete based on its capabilities. The Product Owner absorbs this information and sets expectations outside the team. The process of continuous improvement continues. The team declares, “Based on what we tend to complete, and given the purpose from the Product Owner, we are going to improve our methods in the following ways.”

When good capability goals go bad

There’s a Gary Larsen “Far Side” cartoon of an open refrigerator with a bowl of glop inside holding a gun. The caption? “When good potato salad goes bad”.

Unfortunately, I’ve seen good capability goals go bad in a number of organizations. Listen to this conversation:

Program Director: “I see that our Agile teams are all now using these things called story points to track their work.”

Me: “Yes, it’s working well. Each team has a good sense of what it is capable of delivering iteration over iteration. That helps me figure out how to help remove impediments, where bottlenecks are, and where any team may need us to better resource them. It’s great!”

Program Director: “Hmmmm.”

Me: (muttering under my breath: “That ‘Hmmmm’ just doesn’t sound good. I think I’m about to get sick.”)

Program Director: “So, what’s the highest story point commitment a team has made?”

Me: “27.”

Program Director: “Great!  I’m setting 27 points as the target goal for all teams to commit to for each iteration. Every point will represent 3 hours of work. This precision will help me calculate exactly what we’ll deliver when. Plus, I’ll know which teams are really working and which ones are slackers.”

Me: “Hmmmm.”

Program Manager: “So, let’s get out there and commit! This Agile stuff is great!”

Me: (muttering under my breath, “We’re doomed, I tell you doomed!”)

What just happened must not be allowed

As you roll out your organizational Agile adoption, you’ll encounter many challenges. Pay attention to the usefulness of capability goals. Insist on using them.  Non-Agile organizations won’t like this. At times, you may feel like Sisyphus pushing a rock up hill for all eternity. Be strong. Don’t allow Agile measurement abuse. Create team and organizational trust.  Remove target goals and embrace the incredible value of capability goals. And, don’t allow any backslide. Don’t let your capability goals devolve slowly into target goals in sheep’s clothing.

You: (muttering under your breath, “You know? This MAY just work. Capability goals versus target goals. For the sake of my team, our organization, and the value we deliver to our customers, I’m going to do it!”)

It’s clear, there is not a one-size-fits-all way to define Agile success. Every organization is different, every Agile team is different, and every software development project is different. Each organization has to figure out how to pilot, extend and excel at Agile. Distinct Agile teams within the organization also have to determine how to move to performance in their own ways and make the most effective use of team members to meet their commitments. Full participation from everyone involved is critical to move the organization, process and infrastructure to a better place. The successful approach to adopting Agile acknowledges Agile is not just fad or a quick fix, it is part of an ongoing dialogue of what’s working, what’s not and what are we going to change.

Bringing the Agile community together is a great way for both new and mature Agile teams to share best practices, pain points and success stories. Rally hosts regional events, called Agile Success Tours, to bring the Agile community together for just this purpose. At a recent event in Dallas, we asked participants how they defined Agile success and posed the same question to Twitter. We caught some great answers on video and got some nice, succinct tweets defining Agile success:

These answers illuminate that Agile is a different way of thinking and working for organizations. It’s a smarter, more skeptical and fun craft that addresses the systemic issues found in our increasingly complex and interconnected world. Through Rally’s work over the years helping organizations both large and small adopt Agile, we’ve come to figure out some fundamental components of what success looks like. Agile success comes down to creating the yearning to continue to ratchet up your agility and discipline as a team.

There truly is a simplicity behind Agile adoption when you create the shared commitment and vision that drives your organization – then you begin to see the beauty and the possibilities attainable in an Agile business.

Brad Murphy, CEO of Gear Stream, gave a keynote presentation at last week’s Agile Success Tour. Brad’s vision includes helping organizations transition from project-driven governance to Lean, continuous flow, product line execution. We sat down with Brad to ask him 5 questions about Agile.

1. What’s the most valuable thing you’ve learned by helping organizations adopt Agile practices?

The dynamics surrounding the adoption of Agile practices are changing in ways that are very different from even two or three years ago. In parallel with implementing Agile practices and establishing effective Agile teams, we’re helping organizations connect Agile philosophies and values to vital stakeholder groups. We’ve recognized that actively involving all stakeholders early in the process is key to ensuring that core Agile teams are able to achieve expected results. Gaining the support of all collaborators in the organization dramatically helps core Agile teams successfully transform and deliver outcomes. Involving the following stakeholders is vital, including:

• The core Agile team
• Tooling, Infrastructure and Release Management – the architecture side of the equation.
• Governance and PMO groups – more than half the time, this group builds the roles of the project managers, Agile teams and the Scrum Master. They consider how Agile teams work off backlogs. There’s huge potential for misalignment here.
• Product Management – since this is frequently a group that doesn’t exist, the responsibilities here aren’t well defined. Loosely, I’ll describe this as a group of individuals responsible for defining business value. This group has to be aligned with the way Agile works.
• Executive Management – all of the focus on Agile change with the groups listed above must be explicitly aligned with the strategy and values articulated by senior executives. Too often, Agile is pursued based on “generic” benefits like speed, responsiveness, quality… while these are “good,” they’re not explicit enough.  We must challenge executives to express exactly how they will measure/recognize their own corporate goals and then map these back to the things we choose to emphasize in an Agile transformation.

Responsiveness would be #1. Having the ability to course-correct and change directions quickly in light of new mandates and directions. A close #2 is innovation.  A distant #3 is productivity.

Gear Stream’s clients are realizing compelling organizational realignment by refocusing the entire value chain on external customers, as opposed to the often dysfunctional inward focus of many organizations.  By aligning the entire value chain on external customers, our clients are able to more predictably influence customer satisfaction and marketshare objectives.

I’ll give the advice I’m most passionate about. Agile teams need to challenge the rest of the organization to rethink and reconsider how work happens up and down-stream to them in order to fully exploit what they’re capable of achieving. It’s really about how Agile teams can actively promote, influence and change an organization beyond just what they do as a team. They really can – and do – influence and engage the rest of the organization. The failure pattern of Agile is almost always the same: we’ve built an Agile team, but failed to build the adjacent stakeholder teams in the process – then, the Agile team gets frustrated and the organization loses momentum and enthusiasm for Agile. Agile teams must have the ability to influence stakeholder teams, and ultimately, the baseline infrastructure of the entire organization.

5. How do you define Agile success? (Can you do it in 113 characters?)

Building, delivering & sustaining outcomes that customers r continually thrilled by, driving profit & value 4 all

I would like to welcome Ed Willis to our blog, as a guest blogger.  I spent a couple of days with Ed and his team of internal coaches this Winter and I am glad to have him share some of their lessons from the field of large distributed Agile – Ryan

Question: What are we, as Scrum team members, committing to in a sprint?

The higher-level Sprint Goal or the more detailed set of selected Product Backlog? If you are a customer of the team, what is the team telling you it will do?

I recall being pretty confused about what the team was committing to in Sprint planning after reading Agile Software Development with Scrum, by Ken Schwaber and Mike Beedle, for the first time. There seemed to be some ambiguity around whether the Scrum Team commits to the set of selected Product Backlog items or to the Sprint Goal, which is a higher level and less precise concept. A couple of quotes from that book will help illuminate the situation:

“A team commits to achieving a Sprint Goal.”

“The Scrum Team commits to turn a selected set of Product Backlog into a working product.”

And this from Schwaber’s The Enterprise and Scrum: “… the team selects as much Product Backlog as it believes that it can transform into a completed increment of potentially shippable product functionality by the end of the Sprint. The team commits to the Product Owner to do its best to complete that amount of functionality.”

From the first book again, “The Sprint Goal is an objective that will be met through the implementation of the Product Backlog … The reason for having a Sprint Goal is to give the team some wiggle room regarding the functionality … If the work turns out to be harder than the team had expected, then the team might only partially implement the functionality. “

Note that that last quote appears nearly verbatim in a recent (Feb 2010) version of the Scrum Guide published on scrum.org.

Between the current Scrum Guide and 2001’s “Agile Software Development with Scrum”, Schwaber’s Agile Project Management with Scrum presents an overview of Scrum in its first chapter which does not discuss the Sprint Goal at all – similarly, “The Enterprise and Scrum” provides a summary of Scrum in an appendix that does not talk about the Sprint Goal.

So what are we, as Scrum team members, committing to: the higher-level Sprint Goal or to the more specific set of selected Product Backlog? And why am I so focused on Sprint-level commitments? I focus on commitments because my stakeholders and customers value them. Their plans are in part based on my team’s delivery and so being able to make and meet short-term commitments makes us a better partner to them – “don’t trouble your customer”.

Can You Commit to an Incomplete Sprint?

“Agile Software Development with Scrum” states, “Sometimes only a partial Sprint Backlog can be created … define the initial investigation, design, and architecture work in as much detail as possible, and leave reminders for work that will probably have to be done once the investigation or design has been completed.”

Both that quote and the earlier one on the purpose of the Sprint Goal suggest that the Scrum canon allows for both incomplete Sprint planning and a mechanism to de-scope the Sprint if the team falls behind. If you find yourself in a situation similar to mine (and I suspect many, many of us find ourselves in this situation) where your customers and stakeholders really do value the ability to make and meet high-level commitments in terms of working software that will be delivered at Sprint’s end, then I think that finding a way to do this more regularly is a path you can and should pursue. And it’s one my colleagues and I have embarked on wholeheartedly. All you really need to do to become a better partner in this regard is advance your Sprint planning practices and adapt the strategies you use when you discover you’ve fallen behind.

Reliably Committing to the Selected Product Backlog – One Group’s Perspective

Being able to reliably deliver against Product Backlog commitments isn’t hard conceptually – it starts with doing a better job in Sprint planning. There are probably many ways to do this but I thought I’d share what we’ve done to accomplish this.

Capacity Planning

Our Sprint planning starts with a detailed view into capacity. Is anyone on the team going to be away on training or vacation during the Sprint? Will the remainder of their time be focused on the Sprint? If not, how much do time they think they’ll have to spend in the Sprint? Knowing the total capacity of the team in the coming Sprint is the foundation of a solid Sprint plan.

Ideal Time Estimation

To estimate our Sprint Backlog tasks, we use “ideal time” as it is described in Planning Extreme Programming by Beck and Fowler: “Ideal time is time without interruption where you can concentrate on your work and feel fully productive.” Ideal time on any given task is in essence the answer to the question “how long would this task take you in a perfect world?” Ideal time is then converted into real time in a very similar manner to how story points are converted into expected duration for stories – you measure the velocity of the team. For example, if ideal time velocity of a team is measured at 0.66, then two ideal days of work has been seen in the past to be about three calendar days.

That use of past experience is critical because it rolls up estimation error, overhead, interruptions et al into a single factor used to improve the accuracy of the task estimates while only requiring of the people doing the estimates that they do so consistently. We’ve found it useful. Conceptually I also like it because, along with the use of story points and their corresponding velocity, it increases Scrum’s fractal, self-similar nature.

Assigning Tasks

Typically we assign all the tasks in the Sprint Backlog during the planning meeting. There’s probably enough divergence of thought on this point to warrant its own post, but to stick to the matter at hand, we do this for reasons relevant to the goal of producing more reliable Sprint plans. One major motivation is the fact that estimates provided by the person who will actually do the work are demonstrably more accurate. The second major motivation is our observation that, when trying to achieve greater work sharing and improve the flow of value to the customer by avoiding bottlenecking through specialists, we do a better job of supporting people who are branching out into unfamiliar territory if we know they’re going to do so a priori. Specifically, we can build time into our Sprints for the people who are more knowledgeable in a given area to mentor or review the work of those who are working in areas less familiar to them.

Spikes

We make frequent use of spikes to allow us to develop a better or more complete understanding of what a given story will entail thus giving us the insight needed to build more complete Sprint plans.

Reviewing the Sprint Plan

We review our Sprint plans to look for mistakes we commonly make. We’ve gone as far as enumerating the mistakes we make most often to help us look specifically for those as we do Sprint planning. Most of these are different flavors of not applying our “definition of done” and thus ending up with incomplete plans. If your goal is to develop challenging plans but plans that you’re likely to deliver on, then trying hard to ensure your plans are complete is important.

Note that none of the above should be intended to suggest that we value immutable Sprint Backlogs or task assignments. We can and do frequently grow and shrink the Sprint Backlog as the team uncovers more information about what’s needed to deliver the committed Product Backlog. Similarly, we shuffle (and re-estimate) tasks regularly. What we don’t do is allow significant parts of the work to go unplanned or unassigned at the point we decide what we’re committing to deliver.

Beyond Yes or No

Beyond improved Sprint planning, the second critical aspect for us in delivering committed Product Backlog in a Sprint is how we deal with falling behind. I frequently say in delivering Scrum training that if someone comes to you asking if a bunch of features can get done given fixed resourcing by a given date, that the best of all possible answers is “yes”. The worst of all possible answers is “no” – but not because you’re delivering bad news but rather because saying “no” reinforces the fallacy that that decision is really binary in nature and ignores the great value to be gained by digging into the details to see what’s actually possible.

Similarly when Scrum teams fall behind, they frequently see their choices as being to either: stick with the plan or remove lower priority Product Backlog in consultation with the Product Owner. Those are reasonable choices but I much prefer a third option: work very closely with the Product Owner to find an easier way to deliver the committed Product Backlog items in the time remaining – essentially, use the combined talents and insights of the Product Owner and the team to find simpler, cheaper ways to get the selected Product Backlog done. Honestly, it can feel like magic when it happens.

We once had a Sprint on a tool development project that had fallen far behind – it appeared that no amount of plan scrubbing or task shuffling would allow us to deliver the committed Product Backlog by Sprint’s end. We met with the Product Owner with the intention of choosing Product Backlog to remove from the Sprint. In the course of conversation though, the Product Owner got a better feel for the approach the team was taking in developing one specific item – the item that was driving most of the over-run. Collectively, they realized that the approach was fancier than was really required and in short order sketched out an alternative. We immediately revised our Sprint Backlog to remove the old approach and built a plan for the new one – in about an hour, we went from hopelessly behind with no chance of delivering the complete set of Product Backlog to being close to on schedule. I think having a strong team desire to deliver the whole of the selected Product Backlog was key to making this happen.

Anecdotally, I can say that my colleagues and I worked hard to improve our Sprint planning and replanning practices and pretty quickly found ourselves doing much better in meeting our Product Backlog commitments. For example, during one ten month stretch, I counted 93% of Product Backlog items delivered on time in the Sprints in which they were planned. This isn’t the only thing that matters but it made a big difference to us and our stakeholders: it gave us confidence in the team.

Conclusions

• Use the Sprint Goal to capture over-arching but incremental project goals if this concept is meaningful to you and if goals like these are more meaningful commitments than would be the selected Product Backlog – but definitely don’t use the Sprint Goal as a crutch to support poor Sprint planning practices.
• Don’t let the Scrum canon hinder your team’s thinking when tuning your process to better satisfy your business needs – the canon wasn’t created to limit your thinking.
• And above all, don’t believe that your team won’t be able to reliably commit to the selected Product Backlog Sprint over Sprint – you almost certainly can and, if your team and your stakeholders value this, then by all means pursue improvements in this area.

I’d like to thank Anne Greenhaw, Selaine Henriksen and Ryan Martens for their help in developing this post.  Thanks to Ryan also for inviting me to post here.

About the Author: This is the first guest blog post of Ed Willis. Ed was a soldier, a cab driver, a security guard, a tree planter, an auto glass installer and shop manager, an employee of several bookstores, a house painter, a dish-washer, and a foot messenger, among at least a few other things before buying his first computer. Since then he has worked as a research assistant at Queen’s University, driven a data mining company into the ground and ridden Nortel Networks nearly all the way down. He currently works for company in telecommunications. Born in NY, NY, he now lives in Ottawa, Ontario.

Yesterday, the Agile Journal posted their May edition of the online publication with the above focus.  To support their release, they asked us to share our opinion on the topic.  Here is our response:

Ryan Martens: Age of Reconsideration, Reform and Regeneration

The last decade marshaled in a new empirical way of working with increasingly complex, interconnected and highly-critical software-based systems – Agile.  We are entering a period of reconsideration, reform, and regeneration in software, systems engineering and project management.  Agile is working, Lean Software and System is working, and the combination is starting to prove very powerful with regard to throughput and workers.  The benefits of autonomous work, engagement and mastery are driving systemic improvements in our way of working and growing to meet complex challenges of our world.

These results illuminate a future vision that has the potential to expand our current notions of Lean and Agile from software teams and into real organizational agility.  As a result, there is a chance to unite and unify many communities under the guiding ideas of flow, pull, and value.  All of these communities are being drawn in and starting to play well.  These are beautiful days with all the implications to CMM/SEI, Agile, Scrum, Lean/LEI, and PMI/PMBok communities yet to be determined.

In the first half of this decade, look for collaborating across boundaries, seeing larger systems and groups working hard to create their future realities.  Following that period, look for messy consolidation as the winners of this new platform emerge for a new golden age of networked, software product and system development. Together we’ll be focused on the problem domain of global scale difficulties in governance, cyber-warfare, energy, water, communication, commerce, medicine, climate, transportation and nano-technology.

Ryan Martens is an amateur triathlete,  founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

Jean Tabaka: Let the System Talk

Thinking about our path with Lean, I’m compelled to draw upon research I’ve been doing in Systems Thinking and, more recently, what I’ve been learning in Systems Engineering.

In Systems Thinking, we recognize a world of system archetypes based on the dance of balancing loops, reinforcing loops and the outside agents that may cause them to transition. Lean, as a system of thinking, has certainly responded to systems that rely too much on take-make-waste. A set of negative reinforcing loops: the more you waste the less you have to take and make. Outside agents, the scarcity versus abundance of materials, has led us to Lean. Lean principles and practices create a positive system wherein the more we reduce waste the more value we get which in turn reinforces more waste reduction. It is a reinforcing loop propelled by continuous improvement.

Recently, I attended the Lean Software and Systems Consortium’s 2010 conference in Atlanta. What a revelation. From James Sutton’s talk on Lean Systems Engineering, I added new vocabulary that I think will become critical to Lean’s future.

Will Lean be our best source of practices and principles in the future? That depends on what will be guiding our systems:

• Scarcity
• Abundance
• Desperation
• Conformity

Once we have clarity about what guides our system, we can understand more about the system in which we are operating:

• Simple
• Complicated
• Complex
• Chaotic

Lean has steadfastly addressed pressures of scarcity and hence a system of complexity. That brings me to Dave Snowden’s work captured in Cynefin, a Welsh word he has used to describe a framework of problems, situations and behaviors in these four systems. For our world of complex systems, Lean provides the perfect high-level thinking for what we must embrace: emergent practices informed by, as Snowden puts it, “sense-making”

As we move into the next 10 years of Lean, I fervently believe that our sense-making must inform us about what supports emergence that responds to complexity. The practices will follow. For now, let us concentrate on the systems in which we operate, what outside agents or pressures are guiding our systems, and how we can best continue to formulate and hold dear the practices that will naturally emerge.

Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development.

Scott Killen is an Agile Practice Leader at PayPal and the President of Agile Austin. He has extensive experience managing all aspects of the software development process, from a twinkle-in-the-eye to final release. In advance of his participation as a panelist at our upcoming Dallas Agile Success Tour, we sat down with Scott to chat about Agile.

1. How have you implemented Agile across your organization?

We have a three-year vision for PayPal to implement Agile development across our enterprise. In year one, we are focusing on basic practices. The idea is to lay a solid foundation for building mature teams. In year two, we’ll focus on making teams successful. That is, using the practices in a reinforcing way to build teams that predictably deliver acceptable products. In year three, we want to focus on optimization. That is, aggressively practicing incremental and continuous improvement of our Agile practices.

To baseline practices and measure improvement in year one, we have a metric that we call “Team Maturity.” This is a weighted score that reflects the number of fundamental practices a team employs and their longevity in terms of iterations completed.

We are in the process of defining the metrics we wish to use to define a successful team. It is important to us that these metrics be methodology neutral. Although not formalized, I expect that some measure of time-to-market and released-defect counts will be used.

2. What was your #1 reason for adopting Agile development?

We want more flexibility in our development process.  We seek flexibility to make late-cycle changes to develop the best product and to decrease time-to-market for those products.

3. What has been the biggest benefit of adopting Agile?

We’re looking forward to receiving the big payoffs. But, surveys generally indicate that we are more effective when we develop in Agile projects, our quality is higher, and our developers are happier.  Cross-functional communication is cited as the big win in these surveys.

4. What one piece of advice would you give to new Agile teams?

Be sure to properly set management expectations. You will not get productivity or quality gains at first, and, in fact, your productivity will decline for about six iterations until everyone begins to learn how to work collaboratively within the Agile framework. Agile development does not come without pain. I’m reminded of the expression “Pain is weakness leaving the body.”  That’s Agile – painful, but the results are worth it.

5. How do you define Agile success? Can you do it in 113 characters?

Happier customers measured by Net Promoter scores. Happier developers measured by lower turnover.

Follow this thread on Twitter - We asked Scott to define Agile success in 113 characters or less as part of a challenge we’re hosting on Twitter. What is your definition of Agile success in 113 characters or less? Tweet your answer to @RallySoftware using #AgileSuccess. The top five tweets received by May 17th will be featured in a follow-up blog post.

Yesterday Forrester Research, Inc. issued the most comprehensive, independent analysis of the Agile development tools market and 10 Agile ALM providers.

The Forrester Wave: Agile Development Management Tools, Q2 2010

Here are some highlights but what I really recommend is that you read the report titled “The Forrester Wave™: Agile Development Management Tools, Q2, 2010, Forrester Research, Inc., May, 2010″ 

• The report says, “Rally offers the best combination of capability and strategy.”
• It goes on to say Rally “has a strong services group with lots of experience around enterprise Agile adoption, benchmarking and assessment.”
• Thanks to Forrester’s deep analysis, there is a lot of other great information on Agile adoption (currently at 35%) and where this market is headed.

See the full report for details.

For me, this is a culmination of 6 years of hard work building a great product, roughly 32 product releases (that’s just on our core ALM product),  countless demos to our now 96,000 users to get the features right, and the company evolving from just me to 165 phenomenal team members at Rally. Wow, I am a proud Rally-er today.