Audacious Salon 2018

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. (Continued)

Hmmm… What does that mean?

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. (Continued)

Agile for Humans podcast

Ryan Ripley has posted the second Agile for Humans podcast where he, Amitai Schlair, and I discuss the life of a consultant, how to make retrospectives valuable, and the place of managers in an Agile organization.

Changing Behavior by Asking the Right Questions

My article, Agile Adoption: Changing Behavior by Asking the Right Questions, has been published over on ProjectManagement.com (free registration required). It talks about when managers want change, but don’t want to squeeze the Agile out by force.

Ways of expressing estimates

The way we express our estimates color both the way we think about the thing being estimated and the way our estimates are heard. (Continued)

Pair Programming Lessons from Improv

Thanks to Tim Ottinger for reminding me of Arlo Belshee’s post, “Is Pair Programming for Me?” Go read Arlo’s post, as it’s insightful and has more useful content than most articles on pairing. I’m just going to springboard off of one skill that Arlo mentioned being important to learn.

How to avoid “paragraphing” when talking. Learning to speak in half-sentences, leaving room for the other to take the idea in an unexpected direction.

A few years back, I took a course in “Beginning Improv Acting.” (Continued)

Another Two Sides to Estimation

There are many ways to look at the issue of estimation. Everyone in the business of software development has had experience with wanting estimates, being asked for estimates, or both. That experience frames how they look at the issue. A considerable share of those experiences have been painful. I dare say that everyone in the business has had some painful experiences around estimation, and the painful ones seem to stick in our memory more vividly than the benign ones.

What makes these experiences so painful? Again, the causes are legion. One frequent contributor is well illustrated by a story my older brother taught me as a child.

(Continued)

Definition of Ready

Many time, in the middle of developing a user story, the programmer discovers a question about how it’s intended to work. Or the tester, when looking at the functionality that’s been developed, questions if it’s really supposed to work that way. I once worked with a team that too-often found that, when the programmer picked up the card, there were questions that hadn’t been thought out. The team created a new column on the sprint board, “Needs Analysis,” to the left of “Ready for Development,” for these cards that had been planned without being well understood. (Continued)

Tracking velocity

It’s very common for organizations to track the velocity of the Agile teams over time. This is quite a reasonable datapoint to plot. Combined with other data, it might give you some insights when you look back, and insights based on data are typically more useful than insights based on opinion. Remember, though, to keep in mind what the data is, and what it is not. (Continued)

Getting so much better all the time!

I’ve got to admit it’s getting better (Better)
It’s a little better all the time (It can’t get no worse)
— Beatles

Why do we expect productivity to increase? This goal seems to be a common expectation for management-driven Agile adoptions. Productivity is like motherhood and apple pie; who wouldn’t want more? (Continued)