Useful? Abuser Stories

I have been thinking about the usefulness of something like a user story but from the opposite direction. I've decided to call this an Abuser Story.

An Abuser Story would not help describe what the user wants, but what the user can't stand about the product.

Something like this:

  As Jim I want to stab my eyes out
  when I go to update my items
  because I can't understand from the current list if they reflect reality

The idea struck me after reflecting on an email I sent to some colleagues who are working on an internal accounting system I use a lot. I expressed to them my hatred of the current state of one part of the product, literally putting "I want to stab my eyes out" in the first sentence of my email.

With an iterative approach we only do what has value and we travel light, but isn't it possible this approach can leave pockets of pain? My question to the world is this: Would characterizing that pain explicitly provide any value over leaping immediately to some user story that would attempt to resolve the pain?

In my case the email I sent actually offered two new features of the system that I thought would solve the problem. They were first to be able to sort data and second to split a single list into three logical lists (current, planned, and future). Then some interesting things happened:

• One of my colleagues suggested I use three containers instead of one container in order to group my items.
• I responded that I would try that, but I still wanted to sort the items.
• The other colleague like my idea of grouping and went to implement it.

Did the context of my abuser story help here? It certainly spurred me to author the note; did it cause my colleagues to behave or respond differently? And does that difference have value enough to bother with writing more Abuser Stories?

I'm not sure, but I think I will start looking at the products I use on a daily basis and collect some of these kinds of stories to get more data.

Oh, and I'm happy to entertain a better name than Abuser Story... but I like how similar Abuser sounds to User :)

Losing my Agile

I'm a big fan of Agile software development. I love pair programming. I feel uncomfortable writing new code without first having a failing test. The continuous integration server is like the brother I never had. And I feed on the buzz of a lively and collaborative team room filled with big charts, card walls, pairing stations, and customers guiding my every move.

But why does this way of working -- a way that frustrates or even infuriates many others -- strike such a chord of harmony with me. Am I special? Gifted in some way or another?

And I answer: Nope. Not gifted.

I have an idea though. This realization washed over me slowly while I was sitting at Sunday Mass.

It's my faith.

Agile software development is easy, meaningful, and real for me because it harmonizes with my faith and, in turn, the way I try to live my life each day.

Below are a few ways I've seen this congruence manifest itself:

Iterative

Each iteration produces something useful, and later iterations build on the work of previous iterations to produce a better result.

As a Catholic leaving the church each week after Holy Mass I am releasing a new version of me; each week's version aims to be a bit better than the previous.

Constant Improvement

Teams will change process, tools, and practice in order to get better.

A priest's homily each week will usually include an invitation to make some change in my life in order to be more Christ-like; in order to be a better person.

Respect of the Past

As software craftsmen we carry with us an understanding of our origins. The first breath of our founding document reminds us that we are "uncovering better ways of developing software". It is not the only way; it is not the way we all must tread; it is a discovery of an improvement. Healthy discussion continues today among our thought-leaders on the appropriate mix or influence that XP, Scrum, Lean, Kanban and others have on how we develop software.

The Catholic Church enjoys a bit longer history than Agile software development. But that history is speckled with both dark and bright spots. Right now -- Easter season -- we tend to look back to remember and appreciate where that ancestral journey has taken us. And this history fuels the deep philosophical and theological dialogue that will drive us forward. 

Value Oriented

The measure of our work is based on the value it provides to our customer. What good is a perfect product nobody uses?

In my faith I focus each day on who I am right now and who I intend to become. The measure of my life is summed up in the person I am right now not in isolation but in relation to all those with whom I live, work, play, and relate.

Retrospective

At the end of each development iteration we stop to reflect on what happened with an intense focus on improvement. We systematically root out inefficiency and waste.

Likewise at Holy Mass I reflect on my own faults, identifying the places where I hurt myself or others and the times I chose to turn away from my commitments to God. And through grace afforded me by the Holy Spirit I work (or am challenged by those around me) to eliminate the temptations that lead me away from following God.

----

But that's not all! In my next post I'll lay out a few more intersections -- larger leaps perhaps -- between my faith and how I choose to work in software, and I'll try to clarify why this was an interesting insight for me.

Do you find balance by working in a way that is in-tune with who you are or what you believe? Or do you segment belief systems between work and non-work without struggle or conflict? Either way I'd love your feedback, so leave a comment below.