(Parts of this posting were adapted from an email written by my business partner, Dale Kiefling)
We recently had the disconcerting experience of having a client cancel our engagement because they’d felt that we weren’t being agile enough. In hindsight there were a number of reasons why this might have happened but I think the most important one was simply that we did not provide a clear overview of the engagement. This meant that the client was confused about the value of what we were doing. I myself am confused about how the situation arose. I thought we had been very clear but obviously that was not the case.
An excellent, experienced coach that I have had the priviledge of working with is giving a class in just a few days. He has spots left, and I highly recommend taking the class from him if you can schedule it. The details for his ScrumMaster training are here.
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?
A friend of mine, Bettina Grassmann, has written a very insightful short piece on consensus called “Consensus Killed the Cat“. I have a few additional comments to make to connect what she has written with Agile Work.
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.
Agile training including ScrumMaster Certification, Introduction to Agile Work and Adult Learning for Agile Coaches. Toronto, Edmonton, Calgary, Ottawa, Beijing. Reserve your spot on the schedule of public agile courses offered by Berteig Consulting Inc.
I recently described the Work Item List. The second type of artifact used in an Agile Work environment is the Task. At its most basic, a Task is a simple description of how to do some bit of work towards completing an item in the Work Item List. However, there are some important things to remember when using Tasks.
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.
My associate Deb Hartmann who writes at VitalBrew let me know about a set of twelve “innovation games” to play with your customers. I have never used them, but in reading through them, they appear to be compatible to an agile approach to working with customers.
The Agile Work Roles article has been updated with more detail about all three roles and some additional commentary and links. This is a useful article to share with people who have already been introduced to agile methods, particularly if you are having trouble with a command-and-control management style (by management or team members).
Agile Work requires only a very small number of simple “artifacts”. The most basic is the Work Queue. This is very similar to the Scrum Product Backlog but there are some differences too. The Work Queue is like a carefully managed To-Do list. This article details the use of the Work Queue.
In Blink : The Power of Thinking Without Thinking by Malcolm Gladwell, there is a chapter that describes a number of fascinating experiments. These experiments show how we can be influenced by very subtle cues in our environment. This is a very important lesson for us to apply in our work environments and in particular in our agile work.