Sometimes an agile team is innundated (or maybe just slightly distracted) by requests for individuals on the team to do work for people or groups outside the team’s official stakeholders. This can happen, for example, in a corporate culture that promotes the exchange of favors. This past weekend at our Agile Coach’s gathering, Deborah Hartmann shared her method of detecting, exposing and discouraging this unofficial work.
The coach’s gathering last weekend also got me thinking about the ethics of Agile Work and coaching. Is it okay to use agile methods for destructive purposes?
Great, looooong article about a massive software project failure. Over $100 million down the tubes. Could Agile have saved it?
This past weekend, I was honored to host a small gathering of Agile coaches at my home. Our conversation varied over many topics and I’ll be covering some of them in the upcoming days. The first I would like to cover came from a comment that Christian Gruber made. In the Agile Software Manifesto there is the statement that we value “working software over comprehensive documentation” and in the Agile Axioms we say “we are creators”. These two statements are closely related.
Deborah Hartmann and Robin Dymond have written an excellent paper “Appropriate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value” [pdf]. I strongly recommend this as critical reading for any organization adopting Agile Work methods. The paper provides a basic framework for the safe use of appropriate metrics: metrics that will help the health of the organization, not hinder it.
Yesterday I co-facilitated a meeting with another Agile coach. Near the end of the meeting, one of the participants made a comment to the effect that I probably didn’t imagine when I was growing up that I would be a meeting facilitator. Strangely enough, in a way I did!
A good friend of mine and a fellow coach, Michael Hamman, has a very nice website with an interesting, challenging and engaging manifesto. Please visit his site: http://www.ecosystemae.com/. Michael focuses on organizational development and how people work in organizations. As a person he is both sensitive and intelligent and can see deeply into both what is good and what ails an organization or a team or simply, a fellow human being.
In Jean Tabaka’s new book, “Collaboration Explained : Facilitation Skills for Software Project Leaders“, she describes several methods of collaboratively prioritizing a list of items (for example a project’s work item list). The methods she suggests are excellent, and I would strongly recommend the book. However, there are a couple variations and additional methods that I have used successfully that I would like to share.
Another great selection of blog articles related to agile at the Carnival of the Agilists.
Software projects have a really bad record. Here’s a part of that bad record: on average, 45% of features delivered are never used! This is yet another reason that Agile methods shine: do the highest value work first and stop when you’ve got enough. Can’t do that with waterfall projects!
Over the course of the past month or so, I have added many new references to the Agile Advice Recommended Materials page. Thanks to people who have suggested links and books! If you want to suggest additional resources that you think are excellent, please let me know in the comments. I’m going to start tracking who suggested what so that I can give due credit!
Every once in a while the del.icio.us tag for Agile turns up something really interesting. This evening, I found this article about the ongoing use of the term “Agile”. The article is brief and a little weak, but it brings up a concern that is always niggling in the back of my mind. Interestingly enough, a good friend of mine, Christian Gruber, emailed me another web page of similar import…
A recent discussion on the Scrum Development list (Start of Discussion) provides a good follow up to my parting words in The Art of Obstacle Removal about agile practices themselves becoming obstacles. I have excerpted a small amount of the discussion and added my own comments here.
One of the best ways to go faster is to remove the things that slow you down. This “obstacle removal” is an integral part of many agile methods including Scrum and Lean. Sometimes it is obvious where an obstacle is. There are a few small things that can be done easily to go faster. But to get going really fast, we need to have a deeper understanding of obstacles… and the Art of Obstacle Removal.