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.
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.
A few nights ago, I was having a conversation with my father, Garry Berteig, who is also an agile coach. He had an interesting insight based on a recent experience in Beijing: unity is a precondition to assistance.
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.
Given my interest in applying agile methods outside of software new product development, I’ve been often uncomfortable with the term “Product Owner”. My problem is two-fold: it’s too specific a term (referring to product development), and it fails to denote the responsibilities except in the most generic fashion. In other words, I think that it is both too specific, and at the same time, not specific enough. Updated the Agile Work cheat sheets to reflect this new terminology.
I discovered that the agile methods that I know well (XP, Scrum, Lean) have no word or term for an important part of their process!
I provided a link in a previous entry to an article about eight barriers to effective listening. Well, I was recently talking with someone about this and he pointed out a very important ninth barrier to effective listening.
I recently completed reading An Introduction to General Systems Thinking
Mike Dwyer has written up a very nice analogy between the simplicity of the Scrum method and the simplicity of the waltz.
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?
In Jean Tabaka’s new book, “Collaboration Explained : Facilitation Skills for Software Project Leaders
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.
Berteig Consulting Inc. has published a whitepaper about some of the relationships between Lean and Agile. The paper is based on three prior entries here on Agile Advice relating to Queuing Theory, Empirical Process Control and Self-Organizing Teams.
Here’s a good article about the Toyota Production System (TPS). Agile work takes many of the ideas here and adapts them to a non-manufacturing situation. There’s an interesting comment about the “5 Whys”….