Once upon a time I worked in a place that required design documents before any code was written. I won’t go into all of the pros and cons of that particular practice here. You have probably heard them all by now. What I want to do is describe an agile alternative that I offer to teams, based on personal experience as a team member.
Popularity: 8% [?]
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.
Popularity: 13% [?]
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.
Read more…
Popularity: 7% [?]
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.
Popularity: 7% [?]
At the wonderful Agile Coach Camp in Ann Arbor this weekend, I was introduced to Twitter. I have previously dismissed it as an idle pursuit for people with nothing else to do and therefore an infinite regression of banality. Several people claimed otherwise and encouraged us all to try it as a way to keep in touch en-masse. An example cited was one young woman who had a number of useful interactions with a famous person who would otherwise have been inaccessible to her, simply because she was “following” him.
When I am not at a customer site, I work at home. I have cats for office mates. I don’t get that osmotic communication that happens in team rooms and is one of the benefits of co-location. I am wondering if Twitter can get me part way there. I am going to give it a try.
My Twitter name is rwbrown. Send me a tweet.
Popularity: 8% [?]