After over a dozen years of training and coaching in multiple Agile methods, we've seen how useful it is not to be attached to any one of them. Knowing a variety of methods helps you match the method to the need at hand. It also helps in its implementation. And it gives you the breadth of experience required to keep you from becoming dogmatic.

Many family members and friends celebrated Thanksgiving yesterday. We continued our tradition in our gatherings of individually saying what we are grateful for. We typically do this in the present tense – that is, what we are grateful for now. I wanted to take the opportunity to give thanks for about things people have done for me in the past in my professional area. The list is not complete, so please do not be offended if I left you out – I have tried to keep this somewhat concise.  read more »

I must say I was very pleasantly surprised at how good the Conference on Lean Enterprise Software and Systems, 2011 in Stockholm was. I thought it would be good: while last year's LESS conference was a bit academic for my tastes, LESS 2011 offered a great blend of good speakers, consultants, and participants. I looked forward to the Beyond Budgeting track and Steve Denning.

Note: This is not a normal blog from me, but really notes about a birds of a feature I organized at LESS 2011. There have been three blogs on it so far:

I heard this story years ago at a Stephen Covey time management seminar.

The instructor held up a big, open-mouthed jar. On the table were lots of rocks. He started picking up the rocks and carefully placed them in the jar until no more would fit. He then asked the attendees who thought the jar was full?

Most people raised their hands.

Velocity is the number of story-points completed during an iteration. It is the most common and natural metric for teams using iterations. Time-over-time, the team can measure its increase (or decrease) in its effectiveness in delivering releasable implementations of requirements. It is powerful and effective within a team.

It is not, however, effective between teams.

Payson Hall, a friend of mine who is in project management consulting, wrote to me recently about a huge system he was reviewing. The project was having difficulty in delivery. The client had paid big bucks for this system and it was about to enter acceptance testing.

To help non-technical people on the project understand what acceptance testing was, my friend explained it was like the final walkthrough of a building before the last check is signed. He said,

Progress in delivering business value needs to be tracked to give feedback to the Business, management, and team. There are many ways to perform tracking. One of the simplest and most transparent is the tracking board. There are many forms of tracking boards. In this blog, I show two common versions: a Kanban board and a Scrum board.

Suppose you have a story such as, "As the customer, I want to be able to opt-out to having my location tracked so that I will not get advertisements specific to where I currently am."

In both Kanban and Scrum, there is an emphasis on developing software in small increments of requirements (stories). However the different approaches to scheduling between iteration-based Scrum and iteration-less Kanban can cause different behaviors to emerge from teams. These behaviors do not exist on all teams, but have been observed on many. One cause is that with iteration-less development, metrics and estimates can impose less overhead for the same net result.

I have been doing Agile for over a decade. During this time, I have seen many different ways of thinking about what Agile is. One way is to think that there is only one kind of Agile and that there is a large collection of methods to choose from as you feel appropriate. Another way is to realize that there are many different mindsets in the Agile community and that these mindsets are what give rise to the different methods.