I just read through this article about Requirements Management in an Agile World. It’s a pretty brief article (just the one page), so there isn’t too much there. Have a read, and then come back here and tell us all: what is wrong with this article?
Here is a great article on InfoQ about team size and productivity. The basic idea is that a small team, supported by excellent tools and techniques will always do better than a large team. One aspect of this that isn’t mentioned in the article, but which figures prominently in “The Mythical Man-Month” is the idea of communication overhead. It is impossible to house a large team in a team room and therefore communication cycle times, effectiveness and frequency also become a substantial factor.
This is a nice little encapsulation of the Scrum process and the daily Scrum meeting: http://www.effectivemeetings.com/teams/teamwork/scrum.asp. It is described in completely non-technical language and the example used is that of a marketing team. Basically, what is described is the Agile Skeleton plus the daily status meeting without any of the other project management aspects of Scrum.
This is a great presentation on the importance of trust: http://www.agile2007.org/agile2007/downloads/presentations/Larsen_613_613.pdf. I love this sort of thing since it is, to me, so important to building effective teams. I often prefer to talk about truthfulness since that is the attribute or capacity that people need to develop, but the result of truthfulness is trust, so in many ways they are one and the same.
Sanjiv Augustine, agile coach and consultant at LitheSpeed, has a great blog: LitheBlog. Focus on agile project management topics. Good writing and good reading!
One of the Certified Scrum Trainers, Chris Sterling from SolutionsIQ, recently posted a good set of links on Agile Contracts. Hopefully these links will help you understand how to “sell”, set up and execute on agile contracts. Here are the links:
FaceBook is an extremely popular social networking site. It is also becoming an effective community collaboration site. The agile community is gradually starting to see the value of this environment. Here are four groups related to agile practices:
Agile and Lean Development Community (589 members)
Agile Project Management (218 members)
Extreme Programming (16 members)
Scrum (7 members)
Well, it’s officially launched: The Agile Professor - Creating an Agile Learning Environment for Classrooms and Schools. This blog, authored primarily by my father, Garry Berteig, is an exploration of the use of agile methods to organize learning environments such as schools, classrooms, seminars, workshops, etc. The material in this blog will include Garry’s experiences over the past two and a half years of experimenting with agile methods in an educational context as well as a record of his continuing exploration of this topic. I might chime in from time to time too 
I’m fascinated by the idea of applying agile methods outside of software… be it to business management, family and household, or, as I and my father have been exploring over the last two and a half years… agile classroom management. Here’s how I do it in my Agile Project Management / ScrumMaster Certification courses:
Having just finished a substantial series of articles on the Benefits of Agile, I thought it might be good to let you all know about some other ideas about these benefits. I don’t agree with everyone who has written on this topic, but of course, you can judge for yourself!
In the ScrumMaster training, I include a diagram that has a simple idea: to map the areas of complexity in a problem based on two dimensions: Agreement and Certainty. This diagram is an adaptation of the diagram by Ralph Stacey found in this article called Aides for Complexity by Brenda Zimmerman. This diagram or model can be used to help us understand where and how agile methods can be applied.
Christopher Avery, who has written a book about teams called “Teamwork is an Individual Skill”, has a good reference page on his web site about teams. From his FAQ, here is his definition of “team”:
A team is a group of people whose personal outcomes are obviously linked to a collective outcome — such as a successful project — and who work together to maximize collective and individual outcomes. “Team” also refers to the quality of group relationships that allows ordinary individuals to achieve extraordinary results together — such as a project that surpasses its goals.
Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the “Learning Circle” Reflection/Learning/Planning/Action steps.