Agile Work requires a team to take work items from a prioritized list, break those items into small tasks and then execute those tasks inside of the timebox of an iteration. When first trying agile, many teams have trouble with the task breakdown done in the iteration planning meeting. Here are some hints and tips for making this critical part of the agile process more effective.
Mary and I worked together for a short time almost two years ago now. When we worked together I was impressed by her honesty, insight and wisdom. Here is a brief on-line interview she has done. It is focused on software development, but many of the ideas she discusses can be easily translated into other types of work.
Another interesting link for the morning: Appropriate Process. This is a small group of UK-based consultants who describe a clear and reasonable idea: use only as much process as is appropriate. They have a manifesto and set of values that are compatible / based upon the Agile Software Manifesto and the Extreme Programming Values.
Well, this is interesting: Holacracy. It is a web site describing some aspects of an organizational system that sounds like a slightly modified Scrum of Scrums, with some electoral ideas thrown in, and a philosophy remarkably like the Agile Axioms. There are some very interesting ideas there.
The fall schedule for Agile Project Management / ScrumMaster Certification courses has been posted on the Berteig Consulting web site. If you register through Agile Advice before Sept. 15th, you will receive a 15% discount on the course fee (this discount will be reflected on the course information display). The Beijing course is not available at a discounted price.
Last December, I wrote about a nice simulation exercise that can be done in a small group to demonstrate the difference between waterfall, lean and agile approches to work. I have now run this exercise approximately 40 times and I would like to share the results.
Yesterday, an important and interesting story passed through the scrumdevelopment yahoo group. It seems that a team was experiencing substantial pain using Scrum. This story shows an interesting and effective method of addressing that pain during a retrospective. Pete Deemer, who is Chief Product Officer of Yahoo!â€™s 700-person Research and Development organization based in Bangalore, India, tells the story:
Siddharta Govindaraj has written a brief and useful reference article on the Five Pitfalls of Agile Adoption. One of his recommendations for avoiding these pitfalls is to address organizational culture. I strongly recommend the book The Corporate Culture Survival Guide by Edgar H. Schein. Chapter four of this book provides a simple and practical method of assessing corporate culture which I have used in consulting enagements to excellent effect.
Interesting theoretical article called Does Process Matter? It’s an interesting article in that it provides some thinking about levels of process: individual, team, project and enterprise. In the conclusion, the author claims:
Now that I have described a way to think about team size and process levels, I can assert that the Agile community at the [Agile 2006] conference is mainly looking at the team-level process, even though many of the thought leaders claim otherwise. As I noted at the beginning, smaller organizations growing into enterprise organizations must change their processes, with the realization that Agile methods may not suffice at the enterprise or project levels.
I heartily disagree!
There are still spots available in this two-day course occuring on the 24th and 25th in the Toronto area. Details and registration information can be found on the Berteig Consulting Inc. agile course listings.
In researching some material for a course I am delivering, I came across this great reference web page about setting up a team room. The article includes links to a good number of industry and academic studies. Update: also, check out my previous article about optimizing a team room.
Most of the teams and organizations I coach are working on using agile methods to improve their software development approach. Somewhere along the way, someone has realized that there must be a better way… either better than chaos, or better than bureaucracy. Over the years that I have been practicing agile methods, I have come to believe that quality is not negotiable.