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
Here’s another video interview recorded by Yvette Francino of SearchSoftwareQuality.com at the ADP/West 2011 Confierence. Read More
Also while in Las Vegas for the ADP/West Conference, Bob Payne and I sat in the Agile Philanthropy booth and recorded a podcast on Acceptance Test Driven Development and the 3 Amigos. This is the latest in a series of Tips and Advice podcasts that Bob and I have done.
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
In my previous post, Avoiding Iteration Zero, I suggested starting with “the one obvious thing that needs to be done? (Hint: it’s not ‘login.’)” As Jon Kern has recently mentioned, this same topic has come up elsewhere. I was also in that list discussion.
Jon is, of course, right in a narrow sense. You can start with login, if you want. You can also start with an Iteration Zero. (Or, an Iteration Minus One, as I’ve seen one organization do when their list of pre-planning outgrew one iteration.) I’ve observed that you can generally get better software, faster if you start somewhere else.
There are some very good reasons for this. Read More
Teams new to Agile often realize that they have a lot to do before they get their new development process at full speed. Looking at this big and unknown hill in front of them, many Agile teams choose to do an Iteration Zero (or Sprint Zero) to prepare before they start delivering regular increments of functionality. During this time, they may try to get their ducks in a row with
They try to get all the preliminaries out of the way so they can hit the ground running full speed in Iteration One. In my experience, they’re still not ready to go full speed. These things are rarely as complete as expected after one iteration, and often aren’t quite in tune with the actual needs of the project.
The list of features will likely not be complete, but the attempt to approach completeness will dump in lots of ideas that have been given little thought. Any attempt to project into the future still has no data about how fast things can be accomplished. The infrastructure may or may not be the best for supporting the project, but it is likely that the project will now conform to the infrastructure rather than the other way around. The choice of technologies will be made speculatively rather than driven by the needs of the project. While we may do OK, we’ll have made a lot of decisions with the least amount of information we’ll have in the project lifecycle.
And we’ll have burned an iteration without producing any working software that tests our decisions.
My advice is to borrow an idea from Lean and look at the situation from the output point of view. Ask yourself, “what would it take to start delivering?” Read More
Brian Marick has written a tantilizing post The Stance of Reaction. In it he says
At this point, Sr. Naveira has at least four reasonable choices. He can step forward, thereby “asking” Srta. Muzzopappa to move backwards. He can step backwards (typically reversing the sweep). He can turn toward her so that they’re facing, causing her to “collect” (bring her feet together). He can take no step at all, but turn his chest to the left, causing her to begin moving counterclockwise around him.
The important thing about Argentine tango (danced recreationally, though perhaps not in a performance like this) is that she does not know which choice he’ll make. She must be balanced in a stance—physical and mental—that allows her to react gracefully to any legitimate move.
I truly hope he’ll expand on this, and how he applies it to the business of software development. I have great admiration for Brian’s intellect and inventiveness. I suspect what he says will help me work on some half-baked ideas I have about effective TDD keeping the code in a state in which it’s prepared to go in any direction, and about Pair Programming being most effective when we work to increase the possibilities open to our partner (a la Improv acting).
So far, Brian seems to be describing the concept of Reaction by saying what it is not–that it is not a reduction to a model. His description of this dichotomy does not match my understanding of how we use models. Online conversation has not clarified my understanding of his description. I suspect that the difficulty stems from us looking at the situation using different models. The appropriate next step seems (to me) to clarify my own model of how models work and are useful to me. Read More
Michael Feathers has just written a post on The Carrying-Cost of Code: Taking Lean Seriously. He says,
No, to me, code is inventory. It is stuff lying around and it has substantial cost of ownership. It might do us good to consider what we can do to minimize it.
I’m not sure I can see the analogy of code that’s in production to inventory. Code that hasn’t shipped, yes.
But all code is a liability, I think. When code is in production, then it’s offset by the asset that is the functionality. Whether or not the net is positive is another question.
There’s no doubt to me that code, whether in production or not, has carrying costs that are larger than generally realized. Perhaps it’s a depreciating capital expense?
Carrying costs are larger than we think. There’s competitive advantage for companies that recognize this.
It’s something that takes up space. It takes maintenance. It takes attention. It does have a substantial cost of ownership–larger than we think.
The analogies may be failing me, but I think Michael’s sentiment is correct.
Everything should be made as simple as possible, but no simpler. — Albert Einstein
Dave Rooney recently bemoaned on Twitter about how complicated people make things, pointing in particular to a thread on the scrumdevelopment yahoogroup. It’s a thread that started with a question about a team wanting to adjust the Sprint Backlog in-sprint when something changed about their capacity to complete the work. From there it spawned a long discussion about various ways to estimate the work and commit to it.
To me, most of these approaches to estimation are more complicated than is necessary. Some go into detailed calculations that are far more complicated than what most teams do. I could tell you a really simple technique, but I suspect most teams aren’t ready for extreme simplicity, yet. Read More