Agile User Experience Development
I’m always on the lookout for where I need to be heading with my practice, and the idea of Agile User Experience Development is now on the short list.
I’ve been on teams with some fairly good usability/user experience people over the years, and they love the waterfall. Identify all the users, develop all the personas, and then make a complete set of wireframes and subject them to some level of user testing before doing a whole lot else. The result can be months of calendar time and up to 20% of the project budget gone, and you still don’t have any working code, and therefore the accompanying established team velocity that lets you hold the ever-present launch-date wolves at bay and keep the project from turning into a Death March. Read more of this article »
Deniability and Software–Ouch!
I’ve long told my customers that big waterfall software specs are more like insurance policies than blueprints, especially when I hear the phrase “sign-off” more than once a week. They are part of Covey the Younger’s Trust Tax.
But in Deniability, Seth Godin puts it better that I ever could. “At some point, that effort [anticipatory CYA] becomes so great you never actually ship anything, which of course is the very best protection against failure.”
Ouch!
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 »
