Recently, I came across a model I had not known before: Organismic Integration Theory (OIT). I read about it on Sal Freudenberg’s blog, which is much easier to digest than scholarly articles on the subject.
Recently there have been numerous discussions online about the difficulty of convincing people to try unfamiliar software development techniques that technical coaches and mentors consider useful. The same discussions have been taking place for many years, with no progress. Why is there no answer?
A recent Twitter discussion inspired me to re-think a few things about how to effect meaningful change at the organizational level and the team level. (Funny how Twitter seems to serve that sort of purpose, which may be above and beyond the usage pattern its creators envisioned initially. But I digress.)
During the first few years I worked in the general area of process improvement, I functioned mainly as an “agile” coach at the team level. Through those experiences I tried to understand how each method or practice worked mechanically as well as applying the “agile” values and principles on the cultural dimension, and started to learn how psychology and organizational sociology play into software development practices and delivery methods.
It didn’t take long for me to realize that the way an individual development team goes about its work actually has relatively little impact on the effectiveness of the end-to-end delivery process. I continued to look for the key leverage points in organizations that might yield the greatest positive effect for process improvement. I often found myself venturing far afield from the teams I had been engaged to coach, because time and time again I discovered that the real problems with delivery lay well outside the team’s jurisdiction.
Thor’s hammer was called Mjölnir. Cool name for a problem-solving device.
I completely understand why you have become disenchanted with word "Agile", but I am sticking with it for now. For the majority it’s still at least a starting point to have a pragmatic conversation about product development (not just software).
I wonder about that. Is the word really a starting point for pragmatic conversation? Different people have had different experiences with that. My experience has been that people already have some pretty firm ideas about the implications of the word, "agile." A recurring pattern is that a change agent goes into an organization and happily proclaims, "Oh, boy! We’re going Agile!" To his/her surprise, the people in the organization do not react to the proposition joyfully. The word "agile" connotes Happy Things to the change agent. What does it connote to other people? Why are they not happy to hear it?
Ron Jeffries’ classic article, We Tried Baseball and It Didn’t Work, suggests an answer.
An opportunity for improvement came up recently on a coaching engagement that reminded me of the book, Switch: How to Change Things When Change Is Hard, by Chip and Dan Heath. The authors found that in a wide range of circumstances, people had approached very challenging changes in a similar way; basically, by finding the bits that were working well and using them as the basis for further improvement.
Sometimes the bits that are working well don’t look all that great at first glance. One of the stories the authors of Switch share is that of Jerry Sternin, who was charged with improving the nutrition of children in Vietnam. Rather than approaching the problem as a large-scale infrastructure problem, as had been done up to that point with poor results, Sternin went to a single village to learn how children were fed.
He noticed that some children were well nourished. Setting aside those who had Party connections, and therefore access to better food, he investigated how the well-nourished children were fed. He found their mothers mixed additional sources of nutrients into their rice, including wild plants, small shrimp and insects that could be found without cost. To a Westerner like me, mixing insects into my rice sounds rather nasty; but sometimes opportunities don’t come at you waving their arms and shouting, "Hey! I’m an opportunity!"
I consider test-driven development (TDD) to be a basic software development technique. I’ve used it in a wide range of circumstances for different types of applications in different domains based on different languages and tools. I coach people in using the technique, I run workshops at conferences on it, and I offer a two-day training class on it.
My only regret is that I didn’t learn about TDD earlier in my career. All those years doing things the hard way…time lost forever. Oh, well.
I use TDD and I like it, but I never try to “convince” anyone that they should use it, or even that it works well. I never suggest that TDD is a “goal” for an individual or for a team. TDD might help you achieve some other goal, but it isn’t a goal in itself. It’s just a technique.
And, let’s face it, nearly all the code in production today, worldwide, was developed without TDD. Nearly all the code under development right now is being developed without TDD. Clearly, programmers can get along without it.
Continue reading The right kind of lazy
This is a re-issue of a post from my old blog dating from December 17, 2006. It is a review of a session I attended at XP Days Germany 2006. I think it is still relevant today.
One of the most interesting sessions I attended at XP Days Germany was Developer Awareness, given by Shamsuddin Butt. Butt has a dual background in software development and psychology, which gives him a unique perspective on issues of organizational culture change, team dynamics, individual performance, and coaching.
In this session, Butt applied concepts from Timothy Gallwey’s book The Inner Game of Tennis to the question of individual and team performance in software development. In the book, Gallwey describes the “inner game” within a player between his/her Self 1, who is judgmental and controlling, and Self 2, who can realize the individual’s potential for high performance if only Self 1 would get out of his/her way. The basic idea is to feel what you’re doing and just let yourself do it, rather than trying to monitor, control, and criticize yourself from an internally-imposed third-party viewpoint.
Continue reading Get out of your own way!
Here is a somewhat exaggerated and sanitized description of a situation I encountered on a coaching engagement.
The stated problem was that the software development teams in a certain department were taking too long to deliver and the results tended to have more defects than was deemed acceptable.
Continue reading A strategy for lopsided teams
Change agents and coaches often ask me how to overcome resistance. The coach wants a team to adopt a practice or technique that he/she “knows” is good. Why won’t the team members consider his/her suggestions? It’s possible that they just don’t see any pressing need to change the way they work.
It turns out that experienced professionals aren’t slumped in their offices in a puddle of their own drool, dazed and defeated, surrounded by the smouldering remains of failed projects, hoping a savior will appear and teach them a magic trick that will make them better at their jobs. Notwithstanding industry studies that highlight general problems in software delivery, development teams aren’t “failing” left and right. Software development organizations do deliver results. Few of them deliver results as effectively as they could do, but they aren’t necessarily aware of this, or they don’t see it as especially important because it isn’t causing them any real headaches. People have settled into a comfort zone where they are respected, they feel successful, and they are well paid. When a change agent comes charging at them with golden hammer in hand as if they were in need of rescue, insisting that they change the way they think about and approach their work, why should they listen? The truth is they shouldn’t listen. They’re doing exactly the right thing when they “resist.”
Continue reading Beware the golden hammer
When we function in the role of coach, our primary goal is to bring the client to the point of self-sufficiency with respect to some aspect of their work. Whether we are engaged as a technical coach or process coach, we want the client to internalize some set of values and practices that are presently unfamiliar to them, to shift their mindset in some way, and then to carry the new approach or new skills forward independently. We want to make ourselves unnecessary.
The same can be true when we are engaged as management consultants. In that role, our function is usually to advise and consent. We will be one source of information among several, or many. We may not be privileged to know all the details of the decisions the client needs to make. We are only asked to apply our best professional judgment to the situations the client wants us to address. The advise and consent function is different from the coaching function.
Continue reading Warning signs of client dependency