Ex Machina: Jack Graham's Blog

The Business Analyst's Handbook, by Howard Podeswa

I have to start out by confessing that The Business Analyst’s Handbook, by Howard Podeswa, might not have been the Business Analysis book for me. Software business analysis, like project management, is practiced in two ways these days: the documentation-heavy style necessitated by large organizations where hundreds of people touch a project, versus the looser style used by smaller, nimbler organizations. I mostly practice the latter, and as such, this book proposes a lot of BA deliverables that I’d never incorporate into my work.

That said, there’s much of use here, even if you’re doing analysis on a document-just-in-time Agile team. Podeswa and the colleagues on whose experience he draws know their trade, and while this book isn’t exactly fun subway reading, it does what it says on the tin. It’s an exhaustive catalog of BA best practices, suggesting whom you should consult at every stage of requirements gathering, whom you should invite to meetings, and what should go into the resulting documentation.

If you’re looking for a conversational introduction to the BA’s trade, run like hell  from this book. If you’re looking for a desk reference that you can flip open when you’ve got that nagging feeling you might have missed someone or something when setting up a work session, you might find it useful.

I say “might” only because of my main gripe with this book: awful organization. The information is useful, but ugly and hard to access. I can get useful but ugly off of the web (where at least I have the “Find” command to see me through).  A book ought to be better designed. The fault probably lies with the book’s publishers, Course Technology.  Specifically, much of the information in the book is presented in tables. This would be fine, if the tables were laid out in spreads together with the explanatory text so that you could easily tell what subject a given table covered, and cross reference between table and text. It would have cost them more page count to do this, as it would’ve created quite a bit of white space. Instead, it looks like someone just dumped a Word doc into inDesign with minimal flow control. For a $50 cover price, it’s fair to expect better layout.

Finally, although I may have given the impression above that I’m allergic to documentation-heavy analysis processes, what I’m really averse to is producing a document when it’s not needed. If you want a complete playbook of all the types of documents that might be useful, this book is great. It’s opened my eyes to some documents that I wouldn’t have thought to add to my process before, and given me names for some things that I was already doing on my own but didn’t realize there were standard terms for (like swimlanes). And if you love UML, you’ll be happy to see that many of the Handbook’s recommended deliverables are UML documents.

Overall a handy book, although I strongly recommend looking at a preview before you buy to see if the aforementioned layout problems drive you to distraction. Amazon’s discounted price ($28 at time of this writing) also works in the book’s favor.

The Potsdam Conference: Against all odds, we won World War II without Basecamp.

It was at hour 1.5 of the scrum that I began to suspect my virtual teammates of being asleep. Why was a scrum call taking an hour and a half?

Why the endless questions about topics already documented?

And seriously: was the bubbling noise on the one dev’s phone line just him finishing off a Big Gulp, or him hitting a bong? (My suspicion echoed the study of business professors Rockmann & Northcraft, who found that remote collaborators have difficulty building trust.)

All in all, I’ve decided that some skepticism regarding virtual teams is a healthy thing. Face time works. According to urbanist Edward Glaeser, that’s why we invented cities in the first place.

Cut to two weeks later. We flew people to Boston, locked everyone in a basement conference room, and spent a week having our own Potsdam Conference. Suddenly we all had to look each other in the eye each day. Suddenly, things were working.

This simple truth has gotten lost. A friend of mine worked in a model shop at a large handset producer where designers never left their desks, instead using bluetooth headsets to communicate — even with people sitting in the same room! I spent some time at a large Boston agency where the production manager two floors down looked startled every time I showed up in her doorway instead of calling or e-mailing.

At the same time, I’ve worked on virtual teams that performed very well.

The problem is cultural. If your organization isn’t ready for online collaboration, don’t use it. And don’t expect teams who’ve never met each other face to face to play well with each other. People lie more over e-mail, as one researcher found out.

Nowadays, it’s heresy to claim that online collaboration is a bad thing. The problem is that  organizations rush into it ill-prepared. But I found some rays of hope in this Standford Business post on time zone-spanning teams. Their suggestions boil down to:

• Build trust. Question to ask: does your team have a bond of trust, and if not, how can you build it? (If the answer is ropes courses & trust falls, try again).
• Have processes that correct for the limitations of online collaboration. Question to ask: do your workflows, meeting rules, and sign-off processes correct for missed non-verbal cues, large groups sitting together dominating conference calls with remote people, and the like?
• Foster adaptation instead of throwing workers willy-nilly into virtual teams. Question to ask: is your team sufficiently savvy with the collaboration tools to be used? Can you suggest conventions of use that keep people from being overwhelmed by the new mode of collaboration?

I’ve promised myself never to have another scrum call like the one I describe above. There’s no reason you should, either. Prep your team before you commit to virtual collaboration. And if that doesn’t work, pull the plug, and show up in someone’s office.

The Agile Samurai, Jonathan Rasmusson

Many are the books full of semi-useless sage device on how to manage software development. Few are those that, within a few chapters, empower you to call shenanigans on a buzzword-clad impostor. For the latter service, I’m most recently indebted to Rasmusson’s The Agile Samurai: How Agile Masters Deliver Great Software.

Agile, unfortunately, is a concept that’s been much abused by the aforesaid buzzword charlatans. It’s an idea that’s easy to pitch in an elevator but hard to do for real. And worse, it’s hip. No one wants to be a stuck-in-the-mud naysayer in tech circles (well, no one except for cranky old mainframe programmers — and they’re allowed).

The result is a lot of misinformation and misconception about what Agile really is, what type of projects it fits, and what kind of team you need to do it right. There’s also a basic failure out there to understand that you don’t use everything in Agile. It’s a toolkit, and some of its processes are best skipped in certain situations.

Rasmusson’s book applies the swift katana of justice to all this nonsense. Within a few chapters, I not only had a good grasp of what Agile is, but what it isn’t. He then spends the rest of the book on details of process and, most importantly, offering quick sketches of scenarios in which a given technique succeeded or failed.

As a business analyst, this book challenged everything I’d previously thought about how and when to document the results of my interviews with stakeholders. As a project manager, I walked away with a bunch of useful new tools (kanban boards & Agile-style burndown charts for the win!). As a sometime-coder, I learned some new concepts about good coding practice, which in turn has made me smarter about asking questions of the devs with whom I work.

I was a little suspicious when I picked up the book of the occasional cartoons, the large space given to some infographics, and the quirky sensei/student warrior dialogs that close each chapter. But at the end of the day, I’m a nerd; I love the semi-hokey samurai flavoring. Rather than making the book light on substance, they lighten it as a read, making it a quick book to get through over a series of lunch hours.

And so I will end with a hearty recommendation, and a quote from another samurai book, Musashi’s Go Rin No Sho (Book of Five Rings):

Know the smallest things and the biggest things, the shallowest things and the deepest things. As if it were a straight road mapped out on the ground … These things cannot be explained in detail. From one thing, know ten thousand things. When you attain the Way of strategy there will not be one thing you cannot see.

I realized today that it’s been several years now since that last time I worked on a major project that didn’t use Basecamp. This isn’t just because we’ve come to favor it where I work now. I’ve done a few side jobs in the games industry and found that my collaborators were already using Basecamp. Vendors I work with regularly suggest it, too. Some even look a little downcast when they find out they don’t get to initiate me into its many joys.

Still, there are people out there who still think Gantt charts painstakingly rendered in Microsoft Excel are the only way to do things. Old school project documentation has its place, to be sure, but it can’t touch some of the ways I’ve used Basecamp. A few examples of these uses will explain why I’m a huge fan of 37signals.

• E-mail Papertrail. “I said, and then the vendor said, and then I said…” …and then there’s a gap in the correspondence right where you thought the vendor had agreed a given feature was in scope. Oops. Even with modern e-mail clients, keeping track of all of the conversations that fly around during a project can be nigh impossible. My solution for a while now has been to have these conversations in Basecamp, and if they don’t start there, to move them there as soon as they look  important. Having important discussions in a threaded, searchable repository is much better than keeping them in e-mail, especially when you go looking for them two years later.
• Bug Tracker. For some projects, there’s no substitute for an industrial strength bug tracker like Bugzilla or Mantis, but sometimes you don’t need the level of detail provided by Bugzilla. It can even make the QA process more cumbersome. Basecamp can be a nice alternative. My approach is to create a new project specifically for tracking bugs, then create categories corresponding to bug status.
  For example, on a recent project where I was tracking issues in a large batch of e-mail campaigns, I created one category for “open” and another for “resolved.” I further divided them by the subject matter of the e-mails, and I ended up with something like this:
  • Finance e-mails/open issue
  • Finance e-mails/resolved
  • Call Center e-mails/open issue
  • Call Center e-mails/resolved
  • etc…

  I then opened a message thread in the relevant category each time a new bug needed to be addressed. The beauty of Basecamp in this role is that you can change the category of a message thread. So once I had an issue resolved, I just re-categorized the thread to the relevant “resolved” bucket.

• Face Book. The “People” feature in Basecamp does something awesomely simple that you don’t get from e-mail or business cards: it lets you put in your picture. I love this feature, and I wish everyone would use it. On big projects where one company or both might be quickly introducing large teams to each other, you’ll probably remember the people from the other side whose roles dovetail with yours. But it can be hard keeping track of everyone else, and it’s not as if people automatically exchange LinkedIn profiles. I’m good at remembering people, but I’m sure this feature has helped people remember me a few times.

Finally, I love 37signals’ commitment to keeping this product simple. If I need a Gantt chart, a list of resources with billable hours, or some other feature Basecamp lacks, it’s easy enough to supplement what it does with documents produced in other products. Meanwhile, the core app remains fast and easy to use.

Basecamp isn’t just a tool. I’d say it’s more like a secret weapon, but most smart people with big projects know about it by now… and that is all to the good.