Coalescence of Swirling Chaos

I detect a pattern of group behavior. No doubt it is already described elsewhere and has a fancy name. Self-organization, perhaps. The pattern first revealed itself to me at Agile2008 in a workshop on release planning. It came at that closing moment when everyone is invited to offer a lesson learned. Somehow I felt a need to state something aloud as if that was a necessary element of getting my money’s worth. So I thought about it, trying to find something that no one else had already said. The pattern emerged.

  (more…)

Collaborative Endeavors

Collaboration is fundamental to successful agile projects. A team of people working together toward a shared goal will create a different product than a group of individuals working alone on parallel assignments to be integrated later. Collaboration supplies automatic load balancing, constant discussion and generation of new ideas and communication on the status of the work. A goal for successful agile practice is to foster collaboration in the team. There is much in the literature about how to do this, nicely summed up in Jean Tabaka’s great book,Collaboration Explained.

(more…)

No Time to Unit Test

While reading Scott Bain’s great book Emergent Design, I was reminded of a story. It took place a couple of years ago inside a very tall building in a very large city. I was giving an early version of my Test Driven Development workshop. There were about 25 developers to entertain. I asked the standard calibration questions:

–    How many of you are doing TDD now? Answer: none
–    How many of you do unit testing? Answer: none
–    How many of you know what unit testing is? Answer: some
–    Of those of you who know what it is, do you think it is a good idea? Answer: yes
–    Why, then, do you not do it? Answer: we don’t have time

It was not an unusual set of answers, of course. I have had that same dialog with more than one group.

(more…)

Agile Documentation

When talking audiences who are new to agile software development, we often claim that there is an erroneous belief that agile teams eschew documentation. I was going to put it differently at first, but I have always wanted to use the word “eschew”. It is one of those words that appear in print much more often than in speech. Maybe because it sounds like a sneeze? If you have to look it up like I usually do, I will save you the trouble this time. Eschew means to avoid.
(more…)

How to be a Better Agile Coach

This is the substance of the lightning talk I gave at the Agile Coach Camp, for what it is worth. I put it together as a way to summarize my personal goals for the conference.

Pretty much all of us became agile coaches by accident. None of us went to school to learn how. There are no such schools. Some of us were more deliberate about choosing this career path than others, but it was largely circumstantial for most of us as this new field emerged. And, so far, there are no public training opportunities for agile coaches. 

Two of the cornerstones of Agile software development are continuous improvement for teams and constant feedback at many levels to stay on track. In this spirit, should we coaches also desire feedback on our efforts and seek to improve our own performance? I think so. Sure, we get better with each day of practice and we learn as we go, but are their ways to be more deliberate about it? Here are some to consider. 

(more…)