Agile for Business Analysts

I finally got around to conducting a half day of training for some local colleagues who bear the title “Business Analyst,” and whose organizations (and in some cases careers) had been shaken up by the arrival of the Agile Methods (most commonly Scrum) in the Early Majority. There were only four of us all together, so it was delightfully conversational.

Here’s what the whiteboard looked like when we were done. (Click for a full-size view).

Whiteboard after a 3-h presentation about Agile methods by Robert Merrill and Q&A with three Business Analysts

We started out by describing our own encounters with various Agile practices and knowledge of Agile methods in general.

I explained my concept of the Load-Bearing Walls, and shared my opinion that the ignorance, or politically-forced disregard, of these is going to lead to the failure of many Agile initiatives in Early-Majority adopters.

This led to a discussion of the concept of technical debt, and how it presents itself to the non-technical parts of the organization. Automated testing is the key to technical debt management on an Agile project, and can be a point of resistance. On the business side, I’ve sometimes successfully countered the assertion that it’s “extra work” by likening it to double-entry bookkeeping. Read more of this article »

If you’re always late, a faster car won’t help

Q: Why were they late for the meeting?

A: They didn’t leave soon enough.

But…they got stopped by a train, and they remembered that they needed to pick up a loaf of bread, and…they have a slow car!

Details like speed limits and the police aside, what do the car, and the bread, and the train have to do with it? The trip took 25 minutes, five of it spent waiting for the train, and five of it in the convenience store, and fifteen of it driving. They left 20 minutes before the meeting, and they were five minutes late.

Well, they didn’t plan on the train or the bread.

Do they ever plan on the train or the bread? Read more of this article »