Category Archives: Simplifying Business

Simplifying Business, Simplifying Software

Counter-Intuition: The Confounding Implications of Ticket-Count Stats

Ticket-count analytics should only be used for their intended purpose — managing the list of open tickets. The temptation to infer other implications in the way of employee performance, product quality, etc. must be avoided. In fact, even as a tool for managing the list of open tickets, we need to be careful.

Whenever presented with a metric that implies a certain conclusion, we need to look for confounds. (This goes for all metrics, not just ticket counts.) What other possible explanations could there be? If there aren’t any that come to mind, then the straight-forward explanation is probably correct. But, if there are potential confounds, then deeper study is required. Does a high bug count really mean that bugs are getting out of control, or does it merely mean that stakeholders are over-reporting improvement requests and new-feature requests as if they are “bugs,” either mistakenly or in an effort to game the system?

Using ticket closure-rate counts as a measure of employee performance is a particularly bad idea. The primary purpose of the bug-tracking tool is to be available to the developers as an honest representation of the state of the tickets lodged against the system. Overloading it with the goal of tracking employee performance is a conflict of interest, and Continue reading Counter-Intuition: The Confounding Implications of Ticket-Count Stats →

Simplifying Business, Simplifying Software

On Shortening Wait Times

According to The Laws of Simplicity by John Maeda, shortening wait times goes a long ways towards the appearance of simplicity. People hate to wait, and systems that make people wait seem more complicated than systems that don’t. So, for one thing, an engineer charged with improving the performance of a system would do well to first look at the places in the UI where the user is made to wait and optimize those areas, before moving on to areas where the user does not need to wait. Continue reading On Shortening Wait Times →

Getting Things Done (GTD), Simplifying Business, Simplifying Software

Brainstorming for One

I just went digging through some old blog posts of mine, and a found a few worth reposting. Here’s an excerpt of one from early 2004…

A colleague of mine gave a presentation yesterday about brainstorming techniques. For example, he talked about how an initial pool of ideas can be built up in the generation phase by pushing the boundaries, piggy-backing on the previous ideas, and inverting or negating the previous ideas.

I will never forget the first time I tried it. Continue reading Brainstorming for One →

Scrum, Simplifying Business, Simplifying Life

The Power of Self-Imposed, Extremely Tight Deadlines

Eight in Eight Band MembersNational Public Radio runs a show called “The Story.” Tonight’s story (listen here) was about a group of three well-known musicians (Amanda Palmer, Ben Folds of TV’s Sing-Off, and Damian Kulash of OK-Go), a famous writer/lyricist (Neil Gaiman) and a producer (Sean Slade) who decided to try an experiment this past April.  They wanted to see if it was possible to produce a music album of eight original songs in eight hours, completely from scratch.  They called the project, “Eight in Eight” and the album they produced is called “Nighty Night.”

The group didn’t quite meet their ambitious goal.  After 12 hours, they stopped with only six songs under their belts — an impressive feat, nonetheless.   Continue reading The Power of Self-Imposed, Extremely Tight Deadlines →

Scrum, Simplifying Business, Simplifying Software

An Agile Dependencies Chart

I’m offering up this diagram as “the world of Agile Software Development according to Craig.” Let me know what you think.

One of the principles of Agile development is known as “Simple, Emergent Design.” And one of the ways to know if you have achieved a simple design is if the entire system can be diagrammed on a single sheet of paper — no matter how involved and feature-filled the system becomes — by applying the proper level of abstraction. (Note: It’s not unreasonable for parts of the diagram to be black boxes representing sub-systems, each of which have their own single-sheet diagram.)

A while ago, I took it as a challenge to try to describe the world of Agile development, itself, using such a single-sheet diagram. Continue reading An Agile Dependencies Chart →

Book Reviews, Simplifying Business, Simplifying Software

Now Reading: “Continuous Delivery” by Humble and Farley

My local study group has selected our next book: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble and David Farley. This one picks up where a previous book in the series, Continuous Integration: Improving Software Quality and Reducing Risk, leaves off by venturing outside the developer’s realm and tying together other parts of the organization.

I’m expecting this book to become a well-worn, dog-eared resident of my “Software Bibles” bookshelf. (Can you still say “well-worn” and “dog-eared” in the Kindle age?)

Scrum, Simplifying Business, Simplifying Software

Simplifying User Requirements

It’s often said that one of the virtues (and challenges) of an organization adopting an agile methodology is that it will highlight existing dysfunctions. (The challenge being not to shoot the messenger.) One of the dysfunctions that typically, quickly surfaces is how user requirements can get overly complicated. In an environment that relies on written specifications that are “thrown over the wall” it’s the natural tendency of everyone involved to be as thorough as they can be. And who can blame them? In one respect, it’s their job to think of every contingency and bring all of their experience to bear. Working in a vacuum, it’s only natural to want to err on the side of caution.

Unfortunately, this all too often means that a requirement statement will take on a life of its own. As it evolves and gets fleshed out, the original reason or impetus for the requirement becomes clouded. It is barely retained through implication, if at all.

Allow me to illustrate… Continue reading Simplifying User Requirements →

Simplifying Business

Delegation Tip: To Each His Own Aha!

“Change favors the prepared mind – but it can capsize the inept.” – Ronald Gross

Classic management texts say that people confronted with change go through a natural progression: Denial, Resistance, Exploration, and Commitment. Supposedly, employees must pass through all four phases to cope with change.  An oft-quoted statistic says only 12-15% of employees respond positively and constructively to change, so management needs to conduct special seminars to help others get through it.  All of that always seemed a bit too touchy-feely to me.

I prefer to consider this change curve, first introduced to me by Jeff McKenna.  I find that it gives me a much more useful understanding of the mechanics of change.
Change curve illustration

Any change involves a transition period of loss and chaos before the benefits of the new way begin to take hold.  Eventually, though, Continue reading Delegation Tip: To Each His Own Aha! →