Who is…
Yesterday, Yves Hanoulle published his interview of me as part of his Who Is series. It was a good opportunity for a little introspection about myself and my career. Read More
Category: Individuals and Interactions
Sad Statements
I hope this will be done by then.
These are sad and scary words to me. When I hear them in the context of a software development project, I associate them with a project unlikely to meet expectations. Further, it’s likely that there is no good indicator of what can be delivered when. With no hard evidence to tell them what’s possible, and to judge the effects of changes they try, people fall back on a strategy of hope. They no longer feel in control of the situation.
We’ve done our part.
This signals the underlying hopelessness. When you can’t make things come out the way you want, when you can’t even predict how they will come out, one natural response is to give up. Often the cultural expectations don’t allow saying “this project is in trouble.” The person who does so is the person who will attract all the scrutiny. Without the clear data to back up the perception of trouble, why stick your neck out? Others should be noticing the same thing; let them call attention to it. And when things don’t work out as “hoped,” if weve “done our part,” then someone else will get the blame.
You can’t solve a problem that no one wants to see. Instead, we’ve found an acceptable way to fail.
Calling All Coaches and Mentors
If you coach Agile teams, if you mentor your peers in better software development practices and processes, or if you are just learning to do these things, the Agile India Coaching and Mentoring stage needs your help. Please propose sessions about your work and your experiences.
Home, again, from Agile 2011
It’s been a wonderful, busy week in Salt Lake City at the Agile 2011 Conference. It was great to see so many friends and to make new ones. I had an incredible number of fascinating conversations.
This weekend I was saddened, though not surprised, by the number of tweets with complaints about the conference, often tweeted by people who didn’t go. To paraphrase Yogi Berra
Nobody goes to the Agile Conference anymore. It’s too crowded. Read More
Specialized Skills
Whether we’re talking about revolutionary new web services, IT systems to automate internal procedures, or products to sell in boxes, there are many different sorts of things that need to be done. We need to envision the product, decide what’s required to be done, design it, build it, make sure it works, and put it into production where we can reap the benefits. Except in the smallest of circumstances, doing all of these things requires the work of multiple people. And, given that we need multiple people, and that we need a variety of skills, it’s natural that some people specialize in some thing and others specialize in different things.
But we can take that specialization too far. And if we over-specialize, then we do these different things in isolation. Read More
Process Metrics
My good friend Jack Ganssle commented over at EETimes (also available on the TechOnline India site, with different comments) about my recent post on process standards. In it, Jack cautions against relying on “a strong feeling that ‘things are better.'” He recommends using measurements to bring it back to the realm of engineering.
Bob Pease, analog engineer at National Semiconductor and writer at EDN Magazine, used to say, “when something seems funny, measure the amount of funny.” That’s easier done in the engineering domain than the people domain, of course.
These two simple guidelines will help: Read More
Process Standards
There’s been a long discussion on one of the mailing lists about software development process standards. Someone quoted Robert Glass from his essay “A New Way of Looking at Software Productivity” in Software Conflict 2.0: The Art and Science of Software Engineering
Data show that good people do various software tasks 7 to 28 times better than others… Could we, for example, find out what the good people do? And once we found out, could we transfer that technology to others?
Now, I haven’t read this paper, so it’s quite possible that it’s taken out of context. But it was introduced to me with the question
This sounds like the goal we are trying to do, to discover the most effective way to do something and then enable others to work the same way. Does anybody disagree with this as the goal?
That sounds so logical, doesn’t it. Read More
Video Interview: On Cultural Change
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
On Models
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
Simplicity and Perspective
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