Agile 2018 has come to an end. Once again, virtually all of my time was spent in the Audacious Salon, where I was a track chair. Once again, it was an immersive and powerful experience for me.
It’s time, perhaps past time, for me to describe the salon to the world. To describe how it came to be, the intent, the evolution, and the magic I’ve seen flourish.
This description is, of course, the viewpoint of one man. Undoubtedly I’m biased. Understandably, others will have different viewpoints based on different hopes and wishes, different experiences, and different knowledge. I invite you to share these differences in the comments, even if your viewpoint seems negative toward the concept. Perhaps particularly if you have some complaint, doubt, or fear about the Salon. I, or we, can learn most from a diversity of opinion from diverse people. Read More
On numerous occasions I’ve observed long-time members of the Agile community complain about misinterpretations of what Agile means, and how it performed. Frequently this is precipitated by yet another blog post about how terrible Agile is, and how it damaged the life of the blogger. Sometimes it’s triggered by a new pronouncement of THE way to practice Agile software development, often in ways that are hardly recognizable as Agile. Or THE way to practice software development is declared post-Agile as if Agile is now obsolete and ready to be tossed in the trash bin. Read More
The number one problem I see at clients is that there is no time to learn. Without time to reflect on how things are working, we don’t notice the things that we’re accustomed to not working very well. Without time to research what others are doing, we can’t make informed choices about things we might want to try. Without time to try experiments, we can’t find out if a different approach will work better for us, or not. Without time to try multiple experiments, we can’t evaluate what works for us over a broad range of situations rather than latching onto the first idea that appears to work at all.
To a large degree, Agile software development IS learning. We try things mindfully, watch the results we get, reflect on why we get those results, and adjust. We do that at multiple levels of granularity, from choosing what products to develop to writing code that works reliably.
It takes time, but it pays off over time. To keep doing the same things in the same way suggests that we know everything there is to know about it, and there are no improvements left to make. That we are already at top speed. That we can only do worse than we are right now. I find that highly unlikely.
There is always more to learn. There are ways to learn better ways to learn.
Adding a new team member to an existing team always introduces challenges. The introduction changes the makeup of the team, and if the team had jelled, it has to do so, again, with the new member.
Also, the new member has to learn about the team and its work. There are many tacit assumptions held within a team. It’s impossible to document them all and, even if you could, both reading such a document and keeping it up to date are daunting herculean tasks.
So how do you maximize the integration of a new team member with a minimum amount of work? Read More
Diana Larsen first told me about the Where Are Your Keys language learning game that Willem Larsen and Evan Gardner were playing in early 2009. I was initially intrigued, but when I experienced it with Willem later that same year, I became enthusiastic. My interest lay not in learning languages, but in applying the same techniques and framework to teaching Agile techniques. I immediately began thinking how to make that application, and I’ve been thinking along those lines ever since.
Thus, it was with tremendous expectations when I saw that Diana and Jim Shore had published Your Path through Agile Fluency on Martin Fowler’s website. Having read it, I’m both greatly encouraged and slightly disappointed. Read More
Recently, I was attending a sailing seminar on racing small keelboats. As the lecturer talked about the crew requirements for winning races, I noted a lot of similarities with effective software development teams. Both situations require a small group of people to work in coordinated concert to achieve a common goal. No one on the team succeeds alone–they all reach the finish line together. There is a mix of specialized skills and general work that almost anyone can do. And there is a constant need for improvement, coupled with a desire to go fast. Read More
I write this post from Loveland Colorado, the current location of Consultants Camp. This is an international gathering of consultants who share information and lessons with each other. It’s part of my practice of self-improvement.
I invest a lot in my own professional development every year. I attend conferences such as this one. I read. I converse with colleagues.
My career has spanned a number of decades, and I expect to continue to do so indefinitely. I gave a talk at XPDay Manhattan in 2007 on Sustainable Career where I explored this topic. To do so, you not only need to continue learning, you need to learn things that have a long half-life. Learning specific technologies may be valuable, but those technologies quickly become obsolete. Be sure to also learn things with lasting value, such as the principles behind specific techniques.
You need for your career to last a lifetime. Invest in yourself.
When I was a kid, I decided to invent a new kind of battery. I had a pretty good idea of what was required, having cut open my share of batteries and even built them with a lemon, copper, and zinc. It’s just a matter of two metals (or one metal plus carbon) and a corrosive liquid. How hard could it be to create the battery of the future?
I mentioned my aspirations to my father, who was a chemistry professor. “What do you know about valence?” he asked.
He proceeded to explain about electron clouds and the tendency of atoms to fill or empty their outer ring of electrons.
“So the valence of oxygen is 2.”
“Yes, except when it’s 1 or 4 or 6 or some other value. It’s not always simple.”
I’ve been thinking about that conversation since the end of the Agile 2011 Conference. Read More
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.
Recently a friend asked about the definition of the title, “Agile Coach.” Googling “agile coach” informs me that there are about 205,000 pages with that term. Obviously the term is in widespread use.
I don’t typically call myself an Agile Coach, though I’ll use that term informally if it’s the term used by those with whom I’m having a conversation. Instead, I call myself a Software Development Coach. To me, the goal is developing software more effectively, not becoming Agile. Agile processes and practices happen to be excellent tools for effective software development, but lousy goals in themselves. Or so it seems to me.
This morning, I got a call from a recruiter looking for an Agile Coach for a client. They were a bit unhappy when I gave them my daily rate. “The client has a budget and will never pay that much.” When I asked what rate they were expecting, they said $50/hour, all inclusive.
I made more than that a decade ago as a contract programmer. I cannot imagine finding a competent experienced coach for that rate. I’m sure that you can find a body to sit at a desk, though. Is there value in that?
This low rate, and the fact that cost is a primary factor, but value isn’t even mentioned, makes me wonder about what this role of “Agile Coach” has come to mean to organizations looking to hire them. Read More