The Challenge Of The Empty Page

A lot went on today, providing me with several juicy-ripe blogging topics, right there at the tips of my fingers. Occasionally it's tough to think of something to write about here - though I try diligently to post at least once a day, and have been doing so for over a year - but today's challenge is to decide between too many!

I didn't have a particularly enjoyable half hour with the six Grade 9 students who came into the office for the annual "Take Your Kid To Work" Day. Why was I spending thirty minutes with them? Because I was asked to, as the Agile Manager, and that's probably all you need to know in order to fill in the blanks on that particular episode!

I bought the boss' Christmas gift today (I always aim to have my Christmas shopping done by November 25th each year, and... tick tock!) but of course if I revealed what it was here, there's about a 1% chance he might read about it, and a 99% chance that someone else would read it and proceed to tell him. So mum's the word on that, for now.

The latest in what currently seems like an endless series of Story Point workshops happened this afternoon. (On the same day as the Grade 9 Adventure... what was I thinking? If you figure that one out, please let me know!) Tomorrow I'll spend the day writing up the notes from it (among other things) but a few really interesting things occurred. Since I may end up blogging about them on the work site, I probably shouldn't make extra work for myself by talking about it here. Aw, screw it, it's only typing!

First, we had the question asked early in the session, "Why can't we adopt a uniform Story Point size across all teams?" This has been inquired into so many times since we started using Story Points that I've lost count. It's a reasonable question, especially if you're not reading and thinking about this stuff a lot, so I always do my best to answer it patiently and carefully. It helps that I can quote Agile expert Mike Cohn, who warns against the use of a "Gold Standard" for Story Points. But my bottom line is always that teams won't accept size units that they haven't had some part in establishing themselves. That's what I've read; that's what I've seen. So I always say that, get some doubtful looks, and then grudging compliance (or at least, no further overt pressing of the issue). What makes this a funny story, though, is what transpired later in the session.

To make today's session more "intermediate" than the "intro" version I'd done months ago, the format was changed such that a pre-existing backlog of Story Pointed features and bugs already exist, and the groups are initially just Story Pointing a small number of new items, using the backlog sizes as their guide. This allows them to only spend 40 - 50 minutes building up a few items instead of 90 - 120 minutes sizing a much larger set, and also gives them experience akin to what someone who's added to an existing Feature Team deals with: learning the existing Story Point sizes. What surprised me was just how quickly, and how vocally, one of the two groups (made up mostly of Program Managers) objected to the previous Story Point values in their backlog! They came right out and said, "We think some of those backlog Story Point sizes are wrong! How can we use them as a base if they're wrong?" And these were some of the same people who, an hour or so earlier, had asked why we can't just adopt one uniform set of Story Points and force every team to use them! The irony was almost too much for me!

Noteworthy event number two involved a scenario in which the two of us leading the session, and playing the Product Owner part, mirrored some recent events and applied mock pressure to our groups to bring their schedules in (find a way to deliver the same features in less time). This is sometimes the national pastime in our world, it seems, and so it made sense to simulate that atmosphere for this collection of management and non-management types. Within minutes, in a scene that reminded me of that well-documented psychology experiment where mild-mannered folks were set up in a phony prison and those playing the guards became merciless tormentors, one of our two groups of participants lunged straight toward the "what if we reduce our quality?" angle. I would've done a spit-take if I'd had a drink handy! It must be almost reflexive, the urge to say "we can get things done sooner if we don't worry about quality." When I asked for an actual example, from the past year or two, of us taking that approach and having it result in us achieving our goal, the closest I got was an instance where manual testing was done instead of setting up automated tests. I can buy that (cheaper in the short run) but that's not really what the group in the session meant by "lowering the quality." They were clearly indicating that they'd simply do less testing and hand over their features earlier (meaning the customers would find most of their bugs).

Yes, it was quite the day. I learned some stuff, and didn't kill anyone. At least I don't think I did. It was a bit of a blur, after all!

(Oh, and at least one of the regular visitors to this blog was in that workshop with me, so he should feel more than welcome to correct any misrepresentations I've made here, or to add his own observations. I can hardly wait!)