Quote of the Day

...most people think startups are fast because they work harder and are more ambitious. The truth is that most of the speed difference comes from having far less dependencies (and few customers to upset if something screws up), so it’s just easier to get stuff done.

- Brandon Chu in RuthlessPrioritization

How to Tell the User’s Story

In How to Tell the User’s Story Christopher Butler makes a simple but astute point about technologists who want to focus solely on software:

Without user knowledge, we tend toward analytical approaches to information architecture planning and user interface design — structures that make sense to us and the way we think about the information we want to convey, but that don’t always make sense to our audience.

He also provides a solid solution:

To balance out that analytic thinking, we need to introduce narratives to our planning procedures. Specifically, we need to be thinking through every design decision based upon a need > experience > outcome narrative.
What does the user need?
What kind of experience does our solution create?
Does our solution work?

Quote of the Day

Design is about solving problems that humans have, not problems that products have - Mills Baker in Designer Duds: Losing Our Seat at the Table

Quote of the Day

"... the question of business value becomes stranger and more revealing the more one examines it." - Mark Schwartz in The Art of Business Value

Agile Software Requirements

Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise by Dean Leffingwell provides a detailed study of how to gather and manage requirements in an agile enterprise. It filled in a lot of blanks for me.

An agile enterprise is not easy. An enterprise may do agile but not be agile. That is, the enterprise may have teams that create user stories and have regular standups. But there is much, much more. This book provides for how to be agile.

The book does a good job of defining requirements at three different levels in an organization: portfolio, program and team. Themes to epics to features to stories to tasks. The book is clear and concise. I really liked the use of meta models to show hierarchy and relationships of the agile artifacts.

Quote of the Day

People don't want to buy a quarter-inch drill, they want a quarter-inch hole. - Theodore Levitt

Hiking and Software

Came across a gem of a blog post that compares software development and hiking in the Grand Canyon. Really. It's an enjoyable read even if you're not interested in software. Here's a taste:

The goal, the abilities of the organization, the apparent short distance to enticing and desirable “points of interest”, and the risks are all often misunderstood. All the available money, time, and effort have often been expended by the time the real work of coding/testing/deploying begins and we realize how difficult everything is and how far we’ve gone down a winding, narrow trail we can no longer get back up.

The post is a good reminder that goals, abilities, risks, etc. should be given due attention in any software project.