Toluu

On Be(come)ing Agile

The top stories from the Agile Commons Community

Lean and Agile on TechCrunch - join the debateDecember 22 2008

blog entry by Ryan

Jeff Windman posted a nice little article on TechCrunch IT about Lean, Agile, Rally and Toyota.  Please join the deep and skeptical discussion.

Six Ways to Evolve Your Product Council (3 Comments)December 10 2008

blog entry by Alex

entry

Running the Product Council for Rally ALM has been an interesting learning experience.   Any time you take a group of VPs and directors from a rapidly growing business, put them together in one room, and ask them what your product should do, you're setting yourself up for a challenging and possibly contentious conversation.  Each person has a different set of responsibilities and motivations.

At Rally, Evan  (VP of Services) wants to make sure we're building the features that our coaches can use to help customers be successful with Agile.  Don (Sales) wants to make sure we have a competitive product that solves the problems that prospects care about.  Marc (Support)would like us to build features that solve problems existing customers struggle with.  Dan (Partners) wants to support partners who are building integrated solutions.  Mark (Integrations) needs API capabilities to support his team.

It's critical to get input from each of these different groups, but often there is no correlation between their requests.  Marc's existing users might all be clamoring for the ability to re-arrange a particular screen, but Don's prospective users are so thrilled to have the screen at all that they don't notice it could be improved.

Without good facilitation, it's easy for a group like this to get mired in conflict and disagreement.   I've found that if I d

Lean Economic Times Call for Lean, Agile Software DevelopmentDecember 9 2008

blog entry by Ryan

Right now, we are all working through our 2009 budget process with the unknowns of the economic recession staring us in the face. This budgeting cycle holds more unknowns than we've seen in awhile, so it's making everyone cautious about finding the right moves that will cut costs in the short term without damaging our businesses.

Unfortunately, layoffs may be part of the solution to achieving short-term savings, especially for firms hit hard by the recession. In short, layoffs suck. These highly personal actions are sad, and I am sure you and your staff may need some time to grieve the losses. But prior to cuts, there is a bigger issue to consider while managing belt tightening -– your long-term vision and direction. Put simply, it is imperative to refresh your 2009 vision before the cutbacks, or you risk destroying the morale of the whole team, losing key personnel, and dropping market share.

As you look to make cost-saving cuts, the first question is, how are you going behave?

1. Take the easy way out and cut in a way that fixes the short-term at the risk of harming your long-term prospects. "Across the board" cuts fit this behavior.
2. Rise to the occasion and cut in ways that meet short-term needs and advance your long-term goals.

On Nov. 9,

Getting happy with Slack (6 Comments)December 4 2008

blog entry by Rachel Weston

I have been thinking about and recommending the practice of Slack quite a bit recently. An attendee to one of my workshops just asked me to explain again why I asked him to reduce his committed capacity from 120% to 70%. He wondered why we wouldn't strive for 100%. I started to respond and then remembered a great post on the topic I wanted to reread.

From James Shore: http://jamesshore.com/Blog/Slack%20and%20Scheduling%20in%20XP.html

The most insightful statement he makes (at least for me) is: The more often you face these issues [customer unavailability, technical debt (including design debt)], the more unpredictable your environment is, and the more slack you need in order to meet your deadlines. In the case of technical debt, you can even use that slack to eliminate the problem!

I think that the amount of capacity you leave uncommitted is correlated to how much unexpected work and doubt you have going in to the iteration. Remember, we are trying to create visibility and become predictable. So we need to not over-commit. If you have interruptions, unexpected complexity and other challenges popping up in your iteration, then your estimates are going to be less accurate. When this is true, you need more slack in your capacity to allow you to deal with all of this uncertainty.

Conformity, progress, and innovation (1 Comment)December 1 2008

blog entry by Chris.Spagnuolo

In the 1950's, Solomon Asch, conducted a series of experiments designed to understand the phenomenon we know as conformity. In his experiments, a group of participants were seated around a table and asked to examine a series of vertical lines. They were then asked to tell the group which vertical line, A, B, or C, matched the test line. The vertical line series looked very similar to these:

The catch was that all of the participants except one were confederates of Dr. Asch. The confederates gave the correct answer for the first few trials, but then all began to give the incorrect answer in subsequent trials. Amazingly, the test subject began giving the same incorrect answers as the confederates. In fact, overall, after 18 trials, 36.8% of the answers given by the ‘real' participants were incorrect, effectively conforming to the wrong answers given by the unanimous confederates. Only 25% never gave a false answer, therefore showing that 75% conformed at least once. The results show a surprisingly strong tendency to conform under group pressure, even in cases when the answer is clear.

How does this inform us? When we're working on teams, we need to be cognizant of this study. We