Agile Advice - Working With Agile Methods (Scrum, XP, Lean)

I have just started reading Crystal Clear: A Human-Powered Methodology for Small Teams by Alistair Cockburn. I was not too sure what this book would provide for me in the way of relevant learning.

I am intrigued that this work came out of years of experience by Alistair. This quote from the book “Crystal Clear does not aspire to be a “best” methodology; it aspires to be “sufficient,” in order that your team will shape it to itself and then actually use it.” gave me hope. I work on a small team and I wonder about which practices will best suit our situation. I also wonder how our team can use tools and processes then reflect on their usefulness to decide if we will continue their implementation.

I am interested in reading the whole book, but a little concerned that there will be too much techno-words used throughout. I have a background in business, marketing, and the web but not to the degree of the some of the other books that I have read.

What learning have you gained from working on small teams? Have any of you read this book? If so, did you gain any insights that would help my team to develop?

So far, we’ve discussed learning and value as benefits of agile. Now we turn to a more human side: satisfied stakeholders. Agile methods provide multiple roads to satisfaction for customers, users, business people, bureaucrats (okay, maybe not _all_ bureaucrats), team members, managers, shareholders, and interested passer-by. There are three primary mechanisms by which this occurs: engagement, trust-building and feedback-control. [UPDATED: added link to explanation of Commitment Velocity]

(more…)

Recently I’ve talked with a number of people who have a simple question: what do we do with teams that are constantly interrupted by urgent support requests for their time?

(more…)

Dave Nicolette posted a really interesting and insightful comment about the recent discussions on team commitment, flexibility and rigidity in agile methods. The focus of Dave’s article is on the idea of having an established and continuously available team that grows in its abilities. The more you interrupt the team with individual or one-off tasks, the longer it takes to move through the stages of team development. Thanks Dave for the good post.

Here are eight tips for making a great team room.

(more…)

Given the huge interest in the article by Dmitri Zimine about context switching, and despite a couple of good articles about how to determine iteration length, there has been no empirical method described, only reasoning processes. This article describes a simple method to quickly determine iteration length by experimental means.

(more…)

Recently, Dimitri Zimine wrote an excellent little story about context switching. Joel Spolsky writes in “From the ‘You Call this Agile’ Department“:

Dmitri is only looking at one side of the cost/benefit equation. He’s laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn’t even mentioned arguments for the other side: the important sale that will be lost.

Okay… I’ll bite.

(more…)

I have now trained over one hundred people in my Agile Project Managmenet / ScrumMaster Certification course. I’m starting to see and hear some of the results of this training. There are a couple specific “smells” that I have become aware of.

(more…)

On the agile-usability Yahoo! group, someone asked about tools to mitigate the consequences of having an off-shore team doing some of the work. I have strong feelings about this.

(more…)

Starting off on the right foot is just as important as it ever was. However, with Agile Work, this takes on a significantly different meaning than it does in other methods as the emphasis of what is “right” is also significantly different. This is a short guide on how to successfully launch a team using Agile Work.

(more…)

Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.

(more…)

It’s official. Someone has done a fully-controlled experiment to prove that groups are better at solving problems than even the best individuals working separately. For example, a group of three people, was better than the three best people working independently.

In agile development circles self-organizing teams are all the rage nowadays. And I often hear people bemoaning the “evil managers”. And no doubt in many circumstances and organizations there is real work to do here and real dysfunction to resolve. But I’m less concerned with the analysis of what’s wrong and more concerned with what can we do differently and better. IE: How can we develop the skills necessary to practice effective self-organization.

So what does it mean to be a participant in a “leaderful” group?

(more…)

In software development (and in many other types of projects), there is a typical non-agile approach to estimation of project size. This method starts with a high-level understanding of the work to be done, the requirements, and uses that to make an initial estimate of the project size. This estimate is often stated in units such as man-months. There is a very important piece missing here that makes this estimate completely useless… that makes it pure fantasy.

(more…)

On the Retrospectives Yahoo Group, Michael Webb posted a link to his article Eight Barriers to Effective Listening. This article provides practical advice on how to improve communication. Since one of the basic practices of Agile Work is to maximize communication, this article is essential reading!

(more…)