More Book Reviews

Continuing with more reviews I’m horribly overdue on…

Agile Coaching by Rachel Davies and Liz Sedley. Published by Pragmatic Press, ISBN 1934356433.

I’m amazed that this book covers so may critical topics so well and in such a short length! It’s a terrific book that can help guide you to building highly effective teams regardless of whether you’re a professional coach or team lead.

The book is formatted in four major sections (Coaching Basics, Planning as a Team, Caring About Quality, and Listening to Feedback), each with a few chapters around areas fundamental to good teams. The chapters are comprised of short sections working through details on things like good user stories, hijacked standup meetings, or defining what “Done” means.

I love the concise, easy-to-read style of the authors, and the content in the book is extremely helpful. They hit all the obvious topics, but they also lay out common tough issues like driving change in your organization, keeping meetings effective, and helping resolve team issues of culture and respect. Coaching’s easy when everything’s easy – but the real world requires great coaches to deal with tough problems and this book’s a tremendous help in that aspect.

I also love the authors focusing on issues that are so core to my own notions of great software teams: effective team environments, concise and simple user stories, listening to your teams, and fostering scads of communication. It was also great seeing an entire section of three chapters devoted to software quality, but then I may be a bit biased in that direction…

This book gave me a number of highly useful insights and made me re-think some approaches to common problems I see. It’s a great addition to my bookshelf.

Agile Retrospectives by Esther Derby and Diana Larsen. Published by Pragmatic Press, ISBN 0977616649.

I’ve been a firm believer in retrospectives for a number of years. I’ve used them on many projects in my last two jobs and the benefits have been tremendous. This book is a great help for me in tuning up and improving how retrospectives work.

The writing is extremely concise, well-done, and in a great tone. The authors cover the basics of retrospectives (Set the Stage, Gather Data, Generate Insights, Decide What to Do, and Close the Retrospective), but then head off into a number of other critical topics.

I really enjoyed the authors not shying away from dealing with potentially tough emotional parts of retrospectives. You’ll find short, extremely helpful tips on dealing with the occasional shouters, criers, stompers-off, etc. Retrospectives can be intense, and too many books skip over the unfortunate reality that on occasion you may have some drama to work through. Derby and Larsen don’t shy away; they’re practical in their advice.

Agile Retrospectives also emphasizes teams need to find a retrospective formula that works for them. They offer up a number of different approaches (fishbones, brainstorming, etc.) and lay out situations where those are helpful. (The section on fishbones was particularly helpful to me.) They also have a section on how to run longer post-release or post-project retrospectives – a horse of a completely different color.

Overall this has been a tremendously useful book, and I’ll continue to pull it off my shelf to brush up.

Increase A Disk’s Size in a VMWare VM

I occasionally need a larger disk in one of my VMWare VMs, and I always forget how to do it. I’m writing this post to save myself time the next time I need to do it!

Problem: You need a larger disk in one of your VMWare VMs.

Solution: Expand the disk first in VMWare, then inside the guest OS use Disk Management to extend the disk. (Of course this is somewhat centric to Windows 200*, Vista, or Windows 7 guest OSes. Steps 1-4 apply are the same regardless of your guest OS.)

Note: You can’t extend volumes in VMWare if the VM has any snapshots.

1. Shut down the guest OS.
2. Delete any snapshots of the system (VMWare | VM | Snapshots | Snapshot Manager | Delete)
3. From the VM’s settings screen, select the disk you need to resize, then use Utilities | Expand

   

4. Select the new disk size, click OK and go get lunch. It’s not a fast operation. (Impatient? Grips, dude. Think of what’s going on and listen to some Kenny while you do some yoga breathing exercises.)

   

5. Start up the guest OS, log on, and start server manager, then select Storage | Disk Management.
6. Notice the partition you just expanded now shows extra available space. Right click the drive and select Extend.

   

7. Walk through the wizard and confirm everything looks as it should

   

8. Bask in the joy that you don’t have to fool around with building a new VM with a larger hard disk.

Deleting Browser Cookies with Fiddler

Problem: Internet Explorer 8 won’t clear out authentication credentials and keeps signing you on to a site with a set of undesired creds. In this instance, you’ve likely told Internet Explorer to remember a user’s logon creds for a site with Windows authentication turned on. You want to log on to that same site with different user credentials, but you can’t get IE to bring back up the user logon dialog. Clearing out all browser data (Tools | Internet Options | Browsing History | Delete | check all boxes, clear Preserve favorite website data) doesn’t solve the issue.

Solution: Use Fiddler to delete the browser’s cookie header. Start Fiddler and use Tools | Automatic Breakpoints | Before Request. Open IE and navigate to the bothersome site. Click on the last entry in the sessions pane, then right click on the Authorization cookie in the right Headers pane and select Remove Header.

Flip back to IE and clear out all browser data again (Tools | Internet Options | Browsing History | Delete | check all boxes, clear Preserve favorite website data) .

Now switch back to Fiddler and click Run to Completion in the lower left pane.

At this point you should be presented with the familiar login dialog.

Fixing Blogger’s Bad Formatting of Code Snippets

Problem: Your code snippet fomatting in Blogger looks like poo – extra line breaks “helpfully” injected by Blogger leave your snippets with more whitespace than a third grader’s resume.

Solution: From a forum post by Daniel Carrarini on MSDN: Go to your Blogger’s control panel and select Settings | Formatting. Then change Convert Line Breaks from Yes to No.

Voila!

Quick Script for Building .sln Files With Configurations

Repeatedly typing out msbuild command lines with configuration switches (release, debug) and clean/regular, FTL.

Here’s a quick Ruby script to let you specify –d, –r, –c for debug, release, and clean, respectively. –d and –r are mutually exclusive, but you need one.

Oh! the joy of optparse. Dunno how many times I’ve written a command line parser for just this sort of use case. Love how well this works OOB.

require 'optparse'

def process_command_args

    $options = {}

    opts = OptionParser.new 

    opts.banner = "Usage: build [options]"

    opts.on( "-r", "--release", "release configuration" ) do

        $options[:releaseconfig] = true

    end

    opts.on( "-d", "--debug", "debug config" ) do

        $options[:debugconfig] = true

    end

    opts.on( "-c", "--clean", "clean build" ) do

        $options[:clean] = true

    end

    opts.on("-h", "--help", "Display this screen") do

        puts opts

        exit

    end

    opts.parse(ARGV)    

    if ($options[:releaseconfig].nil? && $options[:debugconfig].nil?)

        puts "Red pill or blue, your choice. Try -d or -r.ac"

        puts opts

        exit

    end

    if ($options[:releaseconfig] && $options[:debugconfig])

        puts "Make up your mind: release OR debug, not both"

        puts opts

        exit

    end

end

def do_the_work

    if $options[:releaseconfig]

        $config= "release"         

    end

    if $options[:debugconfig]

        $config = "debug"         

    end

    $sln = Dir.glob("*.sln")

    if ($sln.length > 1)

        puts "More than one .sln file here. Can't figure it out, bailing."

        exit

    end

    $command = "msbuild " + $sln[0] + " /p:configuration=" + $config 

    if $options[:clean]

        $command += " /t:clean"

    end

    system($command)

end

process_command_args()

do_the_work()

Beware “the Meeting Guy”

If you want an effective project team, then you need to ensure everyone on the team is able to make the right things happen. This is especially important on projects which are in critical phases or are suffering through a painful spot with your clients/stakeholders. You can’t get through tough spots in a project if members of that team have to constantly run back to their supervisory chain to get approval for every decision, or if they can’t help you get roadblocks out of the way.

Sometimes it’s apparent that a member of the team was put there for no other reason than to have a token presence at the table. That member has no authority to make decisions and is unable to commit to anything because they’re constantly having to go elsewhere to get approval for fundamental actions. There’s a great term used to describe these people: “The Meeting Guy.” (Or “The Meeting Gal” if you prefer.)

I’ve run in to this a couple times in my career, and it’s never pleasant. You need someone to bust through impediments, and instead you’re saddled with someone who never delivers on anything because they can’t make anything happen. The Meeting Guy may be a wonderful, happy person, but at the end of the day they’re an impediment to the success of your project.

Having The Meeting Guy on your team is frustrating because your project’s progress suffers. Worse yet, this may be a dangerous sign of a lack of commitment from your client or stakeholder: they may not care enough about the project to fully support it. The worst of all situations might have someone seeking to actively sabotage the effort by saddling the project with a Meeting Guy – thankfully a situation I’ve never run in to.

Identifying the Meeting Guy

Sometimes it’s obvious right away if The Meeting Guy is on your team; other times it may take a few iterations/releases/weeks or an outright crisis to unmask the person. Daily standups are the biggest help in determining if you’re saddled with a Meeting Guy. Is someone on the team regularly missing commitments with reasons like “I’m waiting on <x> to give me approval for <y>,” or “We’re blocked on that while I coordinate with <z>?” Potential Meeting Guy.

Note that I said “regularly.” Stuff happens, and not everyone can get every roadblock instantly out of the way. Meeting Guys/Gals are repeat offenders.

Dealing with the Meeting Guy

There are no easy answers when you’re stuck with The Meeting Guy. You have to get communication flowing to find out what the real issue is – because The Meeting Guy is a symptom, not a root cause.

You need to have a frank, open  discussion with your project’s stakeholders and potentially with the project’s executive sponsors. Take a breath and leave your frustrations behind. Approach the conversation from the business value aspect: “We’re not able to deliver the amount of value we should be because we’re not able to get through roadblocks in a timely fashion. Having the right people committed to the team will help us deliver more quickly.”

What’s the Root Cause?

You also need to step back and re-evaluate the need for the project. If stakeholders and sponsors won’t get the right people at the table, is there actually a real need for the project? Perhaps the business environment has changed and the project isn’t as high a priority any more. That’s not an easy topic to bring up with the people responsible for the project, but it’s a hard question that you need to get answered. Again, approach it from the business value aspect: “If the business situation’s changed so much, maybe we should stop this project and figure out a better place to spend our time and effort. What other cool things can we do for the business?”

Never, ever approach these conversations with a demanding mindset or tone. Yes, you need to clearly identify impediments and risks, but you can’t slip over in to metaphorical hostage taking or blackmail!

These are tough conversations to have with the people and organizations responsible for the project, but you must have them. Something is preventing you from delivering the best business value to the client/organization/stakeholders. Find the root cause, solve it, and focus on helping your organization/clients get the best value for their money!