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 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 finally got 9.5. BBEdit with autocomplete is like having ninjas for backup.