It seems that excitement over agile processes and engineering techniques has finally migrated southward. Well, not “finally.” Last fall, Buenos Aires played host to Ágiles 2008, the inaugural South American conference on all things agile. But last month, the official website for Ágiles 2009 went live. This year, the conference moves to Florianopolis, Brazil for four days of “agilidad” in October.

With retrospectives guru Diana Larsen and Agile Manifesto signatory Brian Marick slated to deliver the keynote presentations, it looks like a great program, whether for South American software developers or North American coders looking for an excuse to mix business with pleasure.

Check out the full program here.

“Sometimes it’s murder—death by intent to kill: high-performance teams often achieve what they achieve by breaking the rules of the prevailing corporate culture. Managers can feel threatened and so they disband them, in order to preserve the status quo.”

“Sometimes it’s manslaughter—death by negligence: the management doesn’t understand the high-performance team or its mode of operation and so it does things that unintentionally eliminate high-performance, e.g. moving members of a high-performance team to other teams, ostensibly with the goal of creating more high performance teams but typically with the result of eliminating any high performance.”

Have any of you experienced the scenarios described above? I’d be curious to hear if many of you readers have experienced “teamicide” at your organization. And, lest we end on such a negative note, be sure to check out the end of the InfoQ article, which concludes with some great tips from Ominlab Media’s Stefan Gillard for finding individuals who will likely contribute to a high-performance team.

I suppose my take is that yes, the notion of “hyper-productivity” is somewhat beside the point, but measuring rates of improvement over time is absolutely essential to push a team to grow and increase its capacity. However, it’s essential for the team, not to be compared to some gold standard of hyper-productivity.

One reason cited for the relative uselessness of such a metric is that, in Scrum and other agile environments, work is estimated in terms of story points—an abstracted unit of difficulty that is agreed upon by the team. Because these units possess no direct correspondence to the amount of time required to complete work, they remain, at best, estimations. However, team members who work together over time typically develop a common of understanding of their estimating system and do, in fact, begin to assess work in a consistent manner. Thus a team’s rate of improvement is reliably measurable—just not in the sense that Sutherland suggests. While identifying an absolute measure of hyper-productivity misses the point, having a trend line to refer to as an indication of improvement over time is still valuable for teams.

“On one side of the argument are those who believe that adopting any of the steps is a move toward agility; that the important thing is not adherence to the steps but instead an improvement in the organization’s software development.”

What I think is important in this quote is Rubinstein’s articulation that the end goal of adopting agile or Scrum is measurable improvement within the organization, not perfectly complying with every aspect of the methodology’s processes. Again, the “rules” of Scrum and agile are there for a reason: They give teams guiderails to lean on during the difficult process of wide-spread organizational change. But an organization does not win if it adopts every aspect of an agile method. They win when they realize change within the organization and begin to work in ways that lets them do things they never could before.

One note: I found it interesting that Rubinstein decided to interview a representative from every major agile tool vendor except the one that we use! In case you’ve missed it in previous posts, we use Danube’s ScrumWorks Pro to manage our projects and it’s really great—mostly for being so easy to use and aligned with the Scrum framework. If you’re using Scrum and find yourself in the market for a tool, you should definitely look into this one.

1. What is the purpose of a backlog in your opinion?
2. How would you define a backlog?
3. When/where should a backlog be considered waste?
4. When/where should a backlog be considered essential?
5. Is there a question or questions that I should have asked and I haven’t? If so, please ask and answer.

There’s a still a healthy amount of differing ideas even among this group, but some commonalities do emerge. You can take a look at all the responses here: http://www.infoq.com/articles/backlog-panel

As I read through all of this, I couldn’t help but think, “Well, of course, standups break down when you try to use them with really big teams!” Scrum is designed to succeed under the recommended conditions. That is, all Scrum literature advises that teams should be cross-functional and composed of seven team members, plus or minus two. That’s a range of five to nine—pretty small, really. So it’s a no-brainer that these teams aren’t getting the advertised results. Would you stuff 30 people into a five-passenger sedan and expect a comfortable ride? Of course not! The same principles apply here.

One valuable point of inquiry in the article was the problem of scaling. I work for a small company that has never had to implement a Scrum-of-Scrums hierarchy, so I’m hardly an authority on the subject. But if you are, I’d be curious to hear some of your strategies for making that configuration work.

Authored by Danube Certified Scrum Trainer Michael James, this new Refcard is exactly the kind of document I’d want to give to someone who had just joined a Scrum team and needs to learn the basics fast. It is very readable and doesn’t get caught up in tangential conversations that would distract or confuse a newbie. Instead, it simply defines Scrum’s most foundational, non-negotiable elements: its roles, meetings, and artifacts. Scrum is a very skeletal framework and James does an excellent job of explaining them in a linear fashion that’s easy to follow, even for the uninitiated. Elsewhere, he provides his insight on related practices and the challenges of scaling Scrum teams across very large organizations. In all, it’s a comprehensive introduction to Scrum’s fundamental tenets and a few of the most relevant topics for practitioners.

Download the pdf of Michael James’ Scrum Refcard below and use it to train new members of your Scrum team.

Scrum_Refcard.pdf