George Dinwiddie’s blog

Documentation! It’s what we do.

People approaching Agile software development for the first time often ask about what documents are required.  When I ask developers what annoys them most about other peoples’ code, I frequently get the answer that it’s not documented well.  And I can’t tell you how many times I’ve heard people express the opinion that Agile software development is undisciplined because you “don’t do any documentation.”

Why is documentation so important to us? (Continued)

This article on InfoQ bothers me.  It seems to draw only from Dave Nicolette’s blog post and the subsequent comments.  Dave’s post is similar, in my mind, to a trip report that someone might give to an organization after a class or conference.  He goes into some detail about what happened at the first ever Certified Scrum Developer course, and muses about what he learned.  The bulk of the comments are an interchange between Dave and Tobias Mayer where, it appears to me, Tobias doesn’t think that the course comes up to the standard of the CSM course.  This is, of course, based on Dave’s description, as Tobias wasn’t present at the course.

The InfoQ article mentions me by name, but doesn’t mention other participants other than Dave.  It also misquotes Dave [now edited without any indication of doing so], and implies that the learnings that Dave got out of our retrospective conversation after the course was a list agreed upon by both of us.  There was apparently no fact checking done on this article.  Certainly no one spoke with Ron Jeffries or with me about it.  I find the article misleading enough that I need to respond.

I had planned to write about the course, but this isn’t the article I’d planned. (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)

A while back, I wrote 3 Legs to Standing Up an Agile Project from the perspective of an Agile team just getting started.  Lately, I’ve been thinking about the same sort of thing, but from the perspective of a coach or an executive that wants to transform the organization.  At first glance, this seems no different. Further reflection, however, reveals that this is less about “how to work in an Agile fashion” and more about “how to introduce change in the way people work.”  The earlier post was a description what an Agile project needs.  This one is a recipe for creating what an Agile project needs. (Continued)

Some of the smartest people I know are ranting that certification doesn’t prove the person is worthy.  Well, of course it doesn’t.  No certification does that.

It only says you’ve met the requirements for the certificate.

Of course, they really know that.  So I don’t know why they’re making such a fuss.

A number of them have made public statements that they discriminate against people who hold certifications.  That really saddens me. (Continued)

On Twitter, my good friend Mike Sutton said, “CSD is a misnomer. The value of existing Certifications needs to be justified before new ones are released.”

Many of the terms we use are misnomers.  For example, “acceptance testing” is a misnomer because it doesn’t indicate acceptance if the tests pasts–it indicates lack of acceptance if the tests fail.

What is the misnomer in the phrase “certified scrum developer?”  (Continued)

A recent post on the scrumdevelopment yahoogroup got me thinking about the age-old problems of distributed software development.  The author of the post described having a Product Owner in California, developers in CA, TX, NC, & India, and QA in India.  (No mention if all of the workers in India were in the same place.)  I’m not picking on this individual.  I’ve heard similar stories many times.

It reminded me of something I’d read in Martin Fowler’s book, Patterns of Enterprise Architecture.  On page 88, figure 7.1 shows a common but distressing architectural design of distributed objects.  In the diagram, the components for Invoice, Customer, Order, and Delivery are each deployed to separate machines.  Why do it this way? (Continued)

Everybody wants to get full value for their money.  I can pinch a penny as hard as the next guy, maybe harder.  But I’ve learned in many ways and many contexts, the very things I do to get more for my money, often result in actually getting less.  How can this happen? (Continued)

Jim Shore has posted a response to the reactions about his previous post on Acceptance Testing in which he defends the way he and the teams he coaches are working.  About the same time, Lisa Crispin posted her thoughts on the topic.

As Lisa says,

I can’t tell you the one right way to test and develop software….  The one right way for your team to code and test will continually evolve over the years. In fact, I’m sorry to tell you that you’ll never find the one right way; it’s a moving target, but you’ll get closer and closer to it.

This is an incredibly important point!  There may be many “wrong” ways—wrong in that they fail to achieve your objectives—but there is no “right way.”  So I’m happy that Jim and his teams are able to achieve the results they want.  I’m not saying they’re doing it wrong. (Continued)

Recently, Jim Shore wrote about The Problems With Acceptance Testing.  I like Jim, and respect him a lot.  Because of my respect for his opinions, I found it quite discouraging that he said, “I no longer use [automated acceptance testing] or recommend it.”  Gojko Adzic has posted his response to Jim.  This is mine.

Certainly when something’s not giving you the results you want, it’s time to make a change.  That change can be to drop the practice that’s not working for you.  It can also be changing the way you go about the practice, or changing what you want to accomplish.  Or, instead of changing, maybe the word “refining” is a better fit. (Continued)