George Dinwiddie’s blog

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)

An article in USA Today (December 12, 2012) about highway projects in New York has the sub-head, “Design errors, planning lapses drove up costs more than 14%.” Among the things listed that “drove up costs” are

• More asphalt than projected due to a math error
• More temporary concrete dividers than planned, as plans called for only half what was needed
• Unanticipated excavation costs.

It’s true that no one likes for costs to exceed estimates, (Continued)

On Twitter, Alfonso Guerra (@Huperniketes) asked me, “Okay, tell me how [software] quality will improve by prog[rammer]s taking more resp[onsibility] for quality?” My response is longer than 140 characters, so I’m replying here.

For background, my involvement in the conversation started when he caught my eye with

The problem with the Software Craftsmanship movement is its attempt to create a race of superprogrammers who can save [software] from bad [project management].

Well, I don’t know anyone promoting Software Craftsmanship who thinks that. (Continued)

When I first discovered Extreme Programming a decade ago, I was a software developer wanting to produce the best, and best fitting, software that I could. In those days, it seems that most Agile adoptions were from the bottom up.

Now I find a lot of Agile adoptions are from the top (or, at least, middle) down. Managers have heard about the improved results that companies are achieving using Agile development, and they want some of that for their organizations. That’s not surprising, and it should result in both better results for the organization and better work life for the employees.

Unfortunately, it doesn’t always work out that way. What is it that goes wrong with these top-down Agile transitions? More importantly, how can a well-meaning manager conduct a successful Agile transition? (Continued)

I recently wrote on The Importance of Precise Estimates.  This is a related topic.

Mark Levison called my attention to an article by Michael Hugos subtitled ‘Agile projects require more planning and coordinating than waterfall projects‘ on CIO.com.  In this article he advocates answering the question, “Has the scope of any project task changed?” at every daily standup.  He uses this information to update a detailed Gantt chart to provide to senior management.  In Michael’s words,

It also gives senior managers who are not on the project (but who are still ultimately responsible for what happens) the information they need to feel comfortable. And that saves project team members from being distracted by endless management questions and misplaced advice (and nothing kills agility faster than endless management questions and misplaced advice…).

Michael, in LOLspeak, “Ur doin it wrong.” (Continued)