I was talking recently with a friend about separate retrospectives for sub-groups. They were worried about thing devolving into separate silos, with a retrospective for programmers, a retrospective for testers, a retrospective for analysts, …. I would be worried if that happened, too, but I can see value in separate retrospectives. How can we know when they’re appropriate and when they’re not? (Continued)
One of the most exhilarating moments in my coaching career was when I entered the client team room one Monday morning to find they were pulling the cards and tape off of their backlog corkboard, and arranging it in a different fashion. I knew then that they had taken charge of their own process. That team became one of the best I’ve coached.
One of the low points was when several people, including a business analyst, product owner proxy, and the program manager, individually said that they couldn’t alter the “user stories” to cut across multiple components of the system because they were already in the computerized planning tool (and Word documents) and it would be too much work. That team did not appear to be getting much value from their “Agile approach” and had significant integration risk that was being studiously ignored.
One of the most frequently asked questions on public mailing lists and forums devoted to Agile development is “What Agile Planning Tool should we use?” There is always a chorus of answers touting this or that computerized tool, usually without asking any questions about the context. Is there one best tool? (Continued)
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. (Continued)
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.
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.
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. (Continued)
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. (Continued)
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: (Continued)
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. (Continued)
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. (Continued)