B-Dub's Blog

2006-06-29T08:32:00.001-07:00

Day 3: Breakout sessions.

Today was a death march. 5 sessions over 2 miles of hotel.

Session One: Retrospective’s Keynote.

I love it when I am pleasantly surprised. I had no idea what this book was going to be about, other than it was about retrospectives. It turned out this group refers to lesson’s learned as ‘retrospectives’. I loved some of his techniques, and I can assure everyone, there will be a tech night on this. I will be buying the book from Amazon when I get back.

SIDE NOTE: They have a “bookstore” here, and all the speakers that have books are there. The lady was insulted when I asked about what the discount was. All the books are full price. I took the opportunity to chat with the author of the retrospectives book, but he was shocked I refused to buy it. I figure I can get it cheaper at Amazon, and if not, so be it. But, I think he was offended that I would not buy it here. I told him he was going to get his cut from the book no matter where I buy it. That disarmed him and he agreed.

Session Two: Agile Productivity Metrics

This could have been a great session, but it turned into a sales pitch for SLIM.

The concept is, create some hard data to prove or disprove the benefits of Agile when it comes to better, faster, cheaper.

Bottom line, the SLIM database does not have much agile to benchmark off of, but does have 20 years of “traditional” projects. The early data is agile is better, faster, cheaper, but I think they are using too few data points. All they are ranking off of is:

Hours spent
Lines of Code
Number of defects
Number of resources used

It was some good detail, but unless you buy SLIM, you cannot recreate any of this analysis.

Session Three: Risk Management on Agile Projects

This was a good session. In a nutshell, yes, we should still do Risk and Issue tracking on agile projects, but how? This company puts them on the wall next to the feature cards. Their wall is divided into three sections (actually four)

Velocity Tracking (they called it the “burn” chart)
Features
Obstacles
Risks

If someone has an obstacle or a risk during the standup, it goes on a new card and onto the wall. Someone is assigned it to work, and updates are given daily, just like the features.

We may need to look at using this.

Session Four: Fishing for requirements on Agile Projects

This was the most disappointing session so far. As soon as the speaker said, “SQE changed my title, I have no idea what fishing is”, my stomach dropped.

Basically, the session dealt with choosing the level of formality you need before each project, to determine the number of artifacts you need to produce. She used radar charts to create visuals of how light or how heavy the process needs to be on that project. She also creates this “artifact density” chart to show the same data.

It was not bad information, and we could take some of this away to use when we are doing proposals to gauge how much more or less effort we need for disco and design, but it was not was I was expecting.

Session 5: Common Mistakes in Scheduling

If session 4 was disappointing, this was downright dreadful. It was not PM 101 but more like PM 010. I have not seen something so basic at a conference ever.

I was talking to the conference chair about the process of becoming a speaker, and I got the whole, it is tough (200 requests, 40 spots), blah blah speech. It cannot be that tough if this guy got through. Brutal.

Session 6: I was not looking forward to this, this was the “Patterns” keynote. However, it was not on design patterns, but behavior patterns. The lady who wrote the book applied patterns to behavior and change.

I may need to buy the book(she did not share any of her patterns, just the theory behind it) since change management in the client environment is a huge hurdle we always need to cross.

It was a great, but LONG day, followed by the cocktail party/networking event.

I met a great guy from South Wales. He said he could not wait to go back and tell everyone in America there are slot machines everywhere, you can walk anywhere with a beer, they give you free beer if you are playing the slots, and you can smoke everywhere.

A guy who works for Target credit cards and myself had to break the bad news to him. This is not America, it is Vegas, and there is a really big difference.

2006-06-29T08:32:00.000-07:00

Day 2: Use Cases for Agile Development

I’ll preface this with the fact the session was great. It was taught by Alistair Cockburn (yes, the guy who wrote the book on use cases).

The content specific to use cases was great, but his overall attitude on design, requirements gathering, and development really turned the crowd and nearly caused a riot. Lucky for me, there were two other guys who were “that guy”. I could stay quiet.

I did learn some alternative ways to use Agile based on this. On his project, they do not do feature cards. Rather, they assign whole use cased during iteration, then just assign out each line of the use case. Instead of dots, they use highlighters.

He preached a tighter, lighter use case. One that is shells out detail anytime it seems like it may get bogged down. For instance, if you have a one sentence business rule, put it in the use case.

For example: “User selects two, and no more than four classes”

If the business rules are more intense, you should hyperlink out of the UC to a new doc, and move on.

I think we do this well already, but I will probably do a tech night to run through his format and tracking, He ranks use cases with levels as “kite”, “cloud”, “sea”, “fish”, and “Clam”. Based on the level, you should see how much detail you should have:

You should have 1 kite use case, no more than 1-3 cloud, 80% sea, 20% fish, and 0% clam. He calls things like “user moves mouse” to be a clam level case and to be avoided at all costs.

Alistair covered an alternate method a friend of his uses. I think it important to note, but I don’t want to see anyone at quick use it. Essentially, you sit with your user and bang out all your user stories/features. You schedule and code the stories. Then, you formulate your use cases at the end based on the stories you coded.

His theory is, if you do use cases first, the customer may not have you code something, invalidating that use case and causing a re-write. I think you would miss more in this mode, but it works for him.

After we got the basics of Alistair’s philosophy on use cases, we delved a bit into his experience. Through luck or hand picked clients, he works exclusively with co-located teams in war rooms. Therefore, besides the use cases, he essentially forgoes all other documentation. He conceded that someone does need to architect the system, and there may be some documentation driven out of that, but everything else should be verbally communicated, not written down. Even complex business rules. He thinks you should give them via videotape since it is faster and cheaper to verbalize them vs. writing them down. This is where he lost the crowd. He conceded that distributed teams and off-shoring cannot use his methods, but said we should all use his way if we could. No paper, and all requirements communicated verbally around a campfire.

To each their own.

2006-06-29T08:09:00.000-07:00

Las Vegas does not suffer Mother Nature very well.

About 10 or 11 years ago when I made my first journey to Vegas, it was during monsoon season. One night, almost 3 inches of rain fell in about 20 minutes. The strip turned into a river. The only way we got back to the hotel was via the SUV taxi’s, and then the water came to the door. We had no power for 2 days, the roof of the Palace station collapsed, and caught fire. Some bum got flushed into the desert by the washouts, a real fun time not on any brochure.

So what does that have to do with my trip, well, we had one HELL of a storm Tuesday night. It looked like a weird horror movie with this black-as-night-cloud roll toward the hotel. If I was in Ohio, I might have gone to the basement.

Bottom line, the entire hotel lost power for a couple of hours, even the casino. The poor schmucks at the slots had to stay there so they could get their money out, and there was a mad scramble by security to cover the chips at all the tables.

I sat in my room and watched the wind slowly destroy the stage they had set up in the pool.

The worst part of all was the internet access was out all Tuesday night and all day yesterday. The hard line access came up last night, but I was on my way to Penn and Teller, so no post.

Today, we have wifi, (Yeah!!!)

I guess silly things like the fire alarms and air conditioning take precedence over the wi-fi. We endured 4 hours of alarm testing during sessions yesterday, and no AC. It was a tad stuffy. I found it inconvenient, but there was a number of folks using VoIP to call back to Europe and they were really put out. I thought I was in a New York crack house with all the people cradling their laptops, rocking, sweating, and begging anyone for a Verizon card. I thought it a tad bad manners for all the crackberry folks to mock them though.

2006-06-27T08:43:00.000-07:00

Sorry for the tardiness of the post, but the late flight, early class combo caught up with me.

After a couple hours at the tables (damn the Pai Gow god’s) and 6 beers, I was done.

So, without further ado, here is my synopsis of the class yesterday,

After the first hour and a half, the class had nothing to do with becoming a trusted advisor to senior management and all to do with justifying one’s job as a tester.

While I harvested a wealth of testing knowledge, tricks, tips, metrics, etc. it was not what I expected at all. I think most of us in the session were very disappointed.

The speaker was from the UK. He was good, but kept dropping in references that made no connection with a mainly US audience (40 degrees outside, liters, tourist spots in the UK). Plus, I loved how he pronounced beta testing “beeta testing”. That was brilliant.

I am kind of surprised I did not get kicked out. I was the only person who spoke up and contributed anything during the session. After he DRILLED project managers, he asked later on if any of us were PM’s. I said yes, and thanked him for kicking us under a bus. He laughed at that one, but during the estimation portion of the lecture things turned. He presented this “new and exciting” estimation technique he received from some guy in Denmark. It was PERT, and the formulas were wrong. After I tried to help him correct them, he said I had to be wrong, and the formula was for demonstration purposes, blah blah, we need to move on.

I am sure the guy today has my picture and was warned. Although, I trekked all the way over here chatting with him (I didn’t know it was him, so good thing I didn’t say anything stupid).

Now, for some un-conference related items.

I figured I would have no transportation beefs with this place. The conference and hotel are all in one place. However, they threw me a curveball. I wander to the “event center” to check in and grab some breakfast. Get my schedule (or shedjewel as the guy yesterday said 18000 times). I need to go to room H in the “convention center”. I am told to go down the escalator, turn left, and through the doors. This sounds OK, but, there is a 50 yard expanse between the hotel and the convention center. It is all fun and games until they may be schlep through 109 degree temps to get to the “convention center”. Today’s instructor was complaining when we walked over. I think his term was “bush league”.

The plane ride was uneventful, but had a very odd moment. When we took off they asked everyone to put the shades down on the windows so the movie watchers would have a better view. Cruising over AZ, the pilot asked everyone on the left side of the plane to get up and move to the right side, then asked us on the right side to pull our shades down. We were right over the wild fires in Sonoma. That was the strangest thing I have ever seen. 32000 feet up, and you could see the fire exploding and rising in columns. The whole area that had been burned looked like a red lake that was pulsing. I have heard people say forest fires have a life of their own, I see why now. It was dusk, so there was still some daylight, as soon as we passed the fire we entered the smoke cloud, this literally turned day-to-night. Plus, it extended much higher than we were, if we were at 32K feet, this had to go into the 40’s.

2006-06-26T10:17:00.000-07:00

We’re at the first break of the “Becoming a trusted advisor” session.

Nothing earth shattering, but there has been some good information.

We got a booklet with all the slides, which is a bonus. I hate conferences that don’t give you the slide decks.

We are supposed to dive in a little deeper going forward.

2006-06-25T16:30:00.000-07:00

As I sweat my butt off in Port Columbus airport waiting for my flight (can’t they afford AC here?), I thought I should take the time to respond to a few questions posed over the last couple days. 1) Who is James and why should I care, and 2) What is SQE, and what tracks are you taking.

James Bender is a co-worker who has crossed the curmudgeon barrier earlier than any known man. His thoughts and musing provide some background to what I am going to write about in the coming week, to view is ramblings, read his blog: http://benders-blog.blogspot.com/

James is also a world renown food nazi. I’ll give him credit, through diet and exercise he has shed the equivalent of an NFL linebacker, but we still get to poke fun at his self-imposed diet requirements.

James thinks that without him, I would have nothing to write about. He is partly right, I would still have something to talk about, just not as much. Next time you see him, thank him for helping a brother out.

On a totally, unrelated “Bender” note, the cartoon network is bringing back one of my favorite shows, Futurama. It is only 13 episodes, but I would like to think my tivoing it nightly on adult swim had something to do with it.

Now, SQE, the software quality engineering group. The best I can tell, they are a west coast think tank/tree huggery dedicated to helping people improve their development techniques. They focus on project management, measurement, metrics, design, and architecture. The conference is focused on “Learning how to beat the odds on your next software development project”. Nice theme for Vegas.

All around, I am looking forward to this conference, and I hope to post items as I move along. The hotel does have wi-fi, assuming they have the bandwidth, look for blow-by-blow action.

Here is the list of tracks I will be taking:

Monday: Becoming a trusted advisor to Senior Management. This is an “all about Brian” session. I hope I can learn how to communicate better with those that control the $$ and power.

Tuesday: Use cases for agile and traditional development. Stay tuned, this is likely to be coming to a Tech Night near you.

Wed: Morning “Keynote”: Agile Productivity Metrics
Track 1: Risk Management on agile projects
Track 2: Fishing for requirements on agile projects
Track 3: Common scheduling mistakes
Afternoon “Keynote”: Patterns, influence, and stone age legacies. I have NO idea what
this will entail; it is a “keynote” session, so there are no other
options.
Thursday: Morning “Keynote”: The complete developer. Sounds like a good time to brush
up on minesweeper
Track 1: Agile development and its impact on productivity
Track 2: Smoke tests to signal test readiness
Track 3: Managing distributed teams
Track 4: A Bug’s Life
Afternoon “Keynote”: Don’t settle for good software, make great software

Stay tuned.

2006-06-19T10:39:00.000-07:00

The count down begins.....7 days until SQE.