More and more, I see advertisements and hear people asking for a Coach to come for a period of time and help their organization on a full-time basis. They seem to assume that it’s necessary to Coach the team 5 days a week, every week. This makes little sense to me.
Teams need time to acclimate to new knowledge. They need to try it on their own, making decisions without immediate help. Otherwise they come to depend on the coach making the decisions, and they don’t learn how to make them, themselves. I’ve seen this happen when I’ve been working too steadily with one team.
It’s also important to limit the presentation of new information to the rate at which it can be absorbed. Time the team spends practicing without the presence of the coach is an important part of this absorption. Without such “soak time,” the team will get lost in the details, trying to climb the proficiency ladder without learning to practice the simple things fluently.
If you try to go faster than you can, you’ll only end up going slower.
I’ve heard stories where organizations have “tried Agile” and the results were so bad that they’ll never make that mistake again. In some of these stories the blame is laid at the feet of bad coaches. In some it’s blamed on lack of coaching. In some, the blame is placed on clients who aren’t ready for Agile . If blame is to be lodged, then any of these will do.
The more interesting question, to my mind, is how can we achieve a better result. Read More
I’ve just spent the past week at Junior Sailing Camp, helping kids circa age 10 become better sailors. At this age, they’ve learned many of the basic concepts: that pushing the tiller to starboard turns the boat to port, that they need to pull the sail in when going upwind, and let it out when going down. Yet they often struggle to get the boat going in varied conditions. They steer too vigorously in light air or choppy waters, killing the delicate momentum they’ve achieved. They position the sail inefficiently–sufficient for a moderate breeze, but insufficient for zephyrs. And in heavier air, the wrong sail trim may result in an impromptu capsize drill.
Much of my coaching depends on helping them observe these varied conditions and how the results of their actions are affected by them. Their current skills work fine when the conditions match the way they practice them. When conditions change, the same actions fail. Without keen observation, the cause of that failure is a puzzle.
I’m teaching them to see the wind. Read More
At the SQE Agile Development Practices (ADP/West) Conference last week in Las Vegas, Yvette Francino interviewed me on the topic of cultural change. Here is the video of that interview. Read More
Brian Marick challenged me for an expression of joyful change, especially related to software development, based on the teachings of Virginia Satir. As discussed in my previous post, he’s come to associate the combination of “Virginia Satir” and “change” with pain and the following:
…blaming… …placating… …anger… …guilt… …stress… …resistance… …denying… …avoiding… …blocking… …deny… …avoid… …anxiousness… …vulnerability… …fear…
This post is, in part, to demonstrate to him that the work of Virginia Satir is not focused on the negative. Mostly it’s to share, and rejoice in, the freedom we have to reach our goals. Read More
Ron Jeffries has written a nice article on some of the effects, both positive and negative, of the Certified Scrum Master (CSM) program. On the positive side, he notes that it does interest people in training. I’m less optimistic that the training they receive will result in many improved projects. The CSM training teaches people how to follow the Scrum process, and tries to give them a little boost in courage for dealing with the inevitable impediments. Is that the difference between a troubled project and an improved one? Read More
A while back, I wrote 3 Legs to Standing Up an Agile Project from the perspective of an Agile team just getting started. Lately, I’ve been thinking about the same sort of thing, but from the perspective of a coach or an executive that wants to transform the organization. At first glance, this seems no different. Further reflection, however, reveals that this is less about “how to work in an Agile fashion” and more about “how to introduce change in the way people work.” The earlier post was a description what an Agile project needs. This one is a recipe for creating what an Agile project needs. Read More
Yesterday was a day of mistakes. Not so much making mistakes, but talking about them. It started with Bret Pettichord’s tweet
Agile requires the courage to make mistakes in front of others and the maturity to admit them when they happen.
Much of the time, the test-driven development yahoogroup is pretty quiet, but it has recently awakened from winter hibernation. The question “Is it OK to add code to a class only to improve its testability?” stirred up a wide-ranging discussion that brought in the topic of what constitutes good design. “Uncle Bob” Martin drew a bold line in the sand with his comment,
One reasonable definition of good design is testability. It is hard to imagine a software system that is both testable and poorly designed. It is also hard to imagine a software system that is well designed but also untestable.
I greatly sympathize with this statement, though I wouldn’t go quite that far. I don’t think it is so hard to imagine code that is testable, but poorly designed. For a trivial counter-case, there could be rampant duplication of testable code. I would call that poorly designed, but it doesn’t affect it’s testability. Therefore I would soften Uncle Bob’s definition to “One reasonable component of the definition of good design is testability.”
To me, the notion of “testable code” is the same thing that “testable circuit” was back when I worked on a custom integrated circuit. Mostly, that depends on the ability to put the circuit or code into a known state, exercise it, and see the interactions with its collaborators and its resulting state. Read More