Done-ness, Denial, and Golf

Totally Test-driven Scrum Delivers Better Objectivity In Measuring Real Progress - Agile Software Process Improvement

Progress is measured entirely in terms of story points collected for tests passed. There is no "A for Effort" in my way of doing things. It's either testably delivered or it's not.

The analogy I use - and, yes, it's a golfing analogy - is to differentiate by measuring the completeness of a hole by whether or not the players took the shots they planned to vs. whether or not the ball actually finished up in the hole.

Jason Gorman puts his finger squarely on one of the keys to software development success. Performing tasks only matters if they result in complete and correct work product.

Jason's golf metaphor conveniently illustrates a couple of related antipatterns, "close enough" and "pick it up after 10 strokes."

In "close enough," someone makes a decision that whatever is currently implemented seems pretty done, so the developer should move on and try to get something else implemented. This is like finding yourself on the green putting for double bogey, and deciding to stop and move on to the next tee. You cover all 18 holes in 4 hours, but you can't post a score because you haven't really played the round.

In "pick it up after 10" the team concedes its inability to bring a feature to testable completion. Just like a course policy to keep people moving around the course, the software team decides that they have spent all the time they can on a feature and must move on. Like the 10-stroke golf hole, they've used more time than they expected and didn't achieve the required result, but they figure they've done all the can in the time allowed. If the customer is lucky, the 10th stroke will be on the green close to the hole. If not, the 10th stroke will fail to clear the edge of the bunker and trickle back into the sand.

I am still learning about Agile methods, but I have to believe the Agile team would have a couple of responses. "Close enough" is essentially a quality issue; the team thinks it's implemented something acceptable even if not what was asked for or agreed to. If the product owner accepts the close enough solution, just like in the cartoons the hole can slide over under the ball so it can drop in. Voila! No longer close enough, the feature is now done.

"Pick it up after 10" seems like a reasonable strategy on the surface. It's the golf equivalent of timeboxing. Teams get into trouble only if they mark the feature done and check it off the list. Seems to me the Agile team might talk it over with the customer and decide they're only go to play the front nine today. Playing the hole to completion will mean they can't finish the back nine, and the customer just can't accept the ball-in-the-bunker solution. Teams create problems for themselves when they pick it up and move on to the next hole, card a 10, and don't tell anyone about the feature's unfinished business.

Closely related to "pick up after 10" is the mulligan. In some respects mulligans are necessary, even a mark of good practice, in software development. You learn from the failed attempt, and try again. Just as in golf, though, mulligans don't show up on the score card. The proud player strides off the 18th green tallying up his 90-something score, but everyone in the group knows Mr. Mulligan couldn't have broken 100. On software projects there's a lot more at stake than who buys the first round. Unreported mulligans eat up time, and worse, keep the team from assessing its own likely performance on future efforts. Mulligans often lead inevitably to "close enough" and "10-stroke limit" situations.

Ah, golf. You can fool yourself if you like, but the rattle of the ball in the cup is what the game is all about.

Read more...

Betting on Scrum

It's been a year since my ScrumMaster training - time to renew my Scrum Alliance membership. Time to consider the value of membership. Time to consider my place in the Agile community. Time to decide if, as an experience designer, I can find a place in that community!

First, what did I gain for my original investment of $1300 out of pocket and a couple of vacation days?

• I discovered Jeff Patton's excellent work. He offers one of the best collections of experience design resources I've found at his site, AgileProductDesign.com. The discussion list he moderates on agile usability attracts leaders in both fields.
• I'm happy to work in a framework that values empathy and story in addition to analysis and research.
  
• I like working with and learning from engineers. I'm glad I get to talk with them more.
• I'm passionate about enabling real people to do real things, and with tools that come easily to hand and leave them happy. Seems like lots of Agile engineers are, too. I like that.

I've found some things less congenial.

• I'm tired of "how many agilists can dance on the head of a pin" discussions. Who's really doing Agile? What methods are really Agile? Can you be an Agile practitioner if you don't produce code? Which Agile guru speaks with the most authentic voice? Can you trace your Agile sensei's pedigree through an unbroken chain of master and student to the founders? Are you still Agile if you learned from someone else? What does the Manifesto mean and whose interpretation is Agile?
• The Agile world does not seem to be a comfortable place for user experience practitioners, still less for business analysts. I have been stunned by the number and intensity of insulting, patronizing, and downright hostile opinions I have seen expressed. Manifesto values like respect have at times been glaringly absent.
• Scrum is a hard practice to evangelize. Managing a product backlog or scrum backlog seems to require discipline at least as great, if not greater, as does "traditional" project planning. It's more structure than people who don't like project management overhead want, and people who have to pass regulatory audits are afraid it's not enough.

The software world has never been without its religious wars, and you can't please all the people all the time. Experience designers, product people, and engineers eventually will find their places under the Agile umbrella.

And somewhere there's a dogma-free Web app team full of people passionate about enabling people to express their personal and professional power through software - and room for one more like them.

At least, I just bet $50 on the possibility!

Read more...

The new manager is a designer

Since My ScrumMaster training, as an experience designer and manager I've been thinking a lot about the value of those roles. At first I was tempted to think that Scrum meant organizational managers are obsolete. How could they, after all, do anything but obstruct the Agile organization? Well, Agile is onto something there - but if so, it's to expose most companies' failure to value and develop an effective management practice.

I've decided that every manager's job is to create an effective organization. If a manager isn't working today to help the whole organization work smarter with better results than it did yesterday, that manager's company is not deploying its headcount for highest business value.

My first stint as a department manager gave me an established team of programmer/analysts and help desk analysts. As it happened, the company relied on me most to manage projects and tasks the department's members were working on. To the people who reported to me I was an interrupt-managing interface to the rest of the organization.

Something didn't seem right. What of serving a team that is effective and satisfied, proud of their accomplishments and continually learning and growing? What of moving beyond caretaking or task management to finding new ways to add value? It seemed that outside of the budget and annual reviews (to which most employees and managers paid lip service) department management seemed to exist mainly to relieve the administrative burden of higher-level managers.

I went on to do my tour of duty as a consultant. I watched project managers create and shepherd projects that delivered value-generating products. I watched product managers deploy that product to realize its power in the marketplace.

In a seemingly unrelated activity, I've been designing a BPM application in which reporting relationships and organizational structure can be used for various process management purposes. In the the world of workflow, organizational units become active delivery mechanisms of essential resources.

Now all the pieces came together. Project managers deliver products via projects. Product managers deliver revenue via products. And organizational managers deliver effective human systems for deploying expertise, coordination, authority, and responsibility. To do so, managers have to design experiences and interactions.

As it happens, I've been seeing quite a lot of discussion pointing to this very conclusion. Next month Richard Buchanan will speak on management as design in his presentation The Four Orders of Design at the Design Management Institute annual conference.

I'm both a designer and a manager; expect this topic to become one of the main themes here.

Read more...

A recent trainee's comments on the Scott Ambler vs. CSM debate

Last week I completed the Scrum Alliance's Certified ScrumMaster training. Coincidentally, Scott Ambler's sidebar "Bringing Ethics to Scrum Certification" had appeared just a couple of weeks earlier (Coming Soon: Agile Certification, 8 Jun 2007). I had opportunity to read Ambler's article between my training days 1 and 2. I find myself thinking that if the 2-day course were called "Scrum Alliance-Certified Training in How to Be a ScrumMaster" the ethics issue - to whatever extent there is one - would shrink dramatically.

First, let me say I agree with Ambler that any professional certification worthy of the name should have some real teeth, with real professional development and demonstrated experience requirements as well as an exam. If a certifying body endorses an individual as competent, that body should have reason to do so. And - to whatever extent it might happen - it's just not OK for trainees or vendors to present attendance at a class as in any way equivalent to the achievement of a professional designation like the PMP.

That said, I found the training useful and I would take it again. I didn't expect to receive a professional designation. I expected only that someone who knows what he is talking about would transmit accurate and useful Scrum knowledge. I also did not expect to become a master of Scrum through taking the 2-day course. Rather, I expected to have the understanding necessary to perform the duties of the ScrumMaster role on a real-world project. At the start of our training that's what our trainer said we could expect, and I believe it's what he delivered. I list the Certified ScrumMaster training in my resume and online profiles along with other professional development and training experiences, where I hope readers will understand it as evidence both of my commitment to ongoing professional development and to Agile - a commitment I've backed with $1200 and 16 hours of vacation time.

Read more...