Backlog Baggage

I’d like to suggest a radical strategy for backlog management.  The strategy is simple, whenever you review an item and opt not to consider it for active work, destroy it.  Yes, you heard me, set fire to the blighter!

This might seem a little extreme at first glance, but I think the logic behind it is pretty straight forward.  First, by keeping it, you are implicitly saying that anything new that you will learn as you work is less important than the thing you just said no to.  Secondly, by keeping it, you are also implicitly saying that you have no feedback mechanism whereby the item could come back to you without constantly collecting and reviewing it <insert Gollum sounds here>.  And don’t get me started with the cost of maintaining all that baggage if you opt to keep it.  Believe me, I understand that we love our precious items…  I do.  But a backlog item just doesn’t have value unless it’s being worked on meaningfully right now.

With the year end looming, this might be a good time to simply grab all that baggage in your backlog and toss it out.  Trusting that if any item was really important, it will come back to you quite naturally in good time.

Creating a Culture of Learning

“I know one thing: that I know nothing.” – Socrates

For Agile teams to meaningfully embrace change, they should also embrace a culture of learning. This idea is not unique to Agile, Lean also explicitly makes mention to the importance of learning by making it one of its’ principles.

So what can we do to create a culture of learning on our teams?

I would suggest that while it’s important to encourage learning and to create learning opportunities on the team, doing so may not be enough to truly embrace a culture of learning.

For this to happen, we first must first create the capacity for learning on the team. This means honouring the time and energy that it takes to set aside our own agendas and then divert this time and energy to learning. It also means allowing ourselves to acknowledge and dare to speak three simple words: “I don’t know.”  This can be tricky because we don’t often reward or encourage a culture of “I don’t know” in our work and personal lives. It’s unlikely that Socrates would have climbed high up the corporate ladder with his approach of “I know nothing”.

So if you are seeking to create a culture of learning on your team consider…

…do you ever hear team mates asking for help?

…is it ok for the team to acknowledge what they don’t know?

…do we honour learning on the team in the same way we do “solutions” and “results”?

The key here is to be able to accept what we don’t know and then move on to “what do we need to do to learn?” while being comfortable with the reality that we may never have perfect answers.  However, by not acknowledging what we don’t know, we risk buying into answers that don’t deliver value.

Agile for UXers

This weekend I was privileged to attend Canada’s largest non-profit UX conference, UXcamp in Ottawa. Quite a few themes emerged during the conference, but two resonated deeply with me… process and team.

Several presenters either directly or indirectly talked about the importance of applying UX principles to internal processes and teams. In addition to this, on more than one occasion, “big A agile” was explicitly mentioned and quickly dismissed… it seemed to me (perception alert!!) that many presenters wanted to distance their ideas from being in any way “big A agile”.

So I wanted to take a moment to offer up a quick overview of Agile for curious UXers out there. To begin with, I want to share how deeply committed I am to the idea that we (UXers and Agilists) are focused on the same goal of delivering high quality valuable solutions to our users.

First thing that I would like to share is that the heart of Agile isn’t process. Agile came to life with its first incarnation in XP or Extreme Programming… and if you dig a little into XP, you’ll come face-to-face with its values: feedback, communication, simplicity, courage and respect.

The next thing that I would draw attention to is the Agile Manifesto itself. Several leaders in the Agile community came together in order to define Agile’s four values: “Individuals and Interactions”, “Customer Collaboration”, “Working Software” and “Responding to Change”. These values apply to the software solution as much as the team itself. In support of this, the Manifesto also describes 12 principles that help define “how to be Agile”. The majority of these principles are focused on team.

Now, this isn’t to say that there aren’t plenty of “practices and implementations” out there calling themselves “Agile”… but I would strongly question any practice that calls itself Agile that does not honour the values and principles of the Agile Manifesto or the origins of Agile in XP values. As UXers, you are in a unique position to see this on your teams… I would encourage you to help your “big A agile” teams reconnect with their core values.

In Defence of Waterfall…

I recently put together a whiteboard presentation that gives an overview of 6 different software development methodologies (Waterfall, XP, Scrum, Agile Manifesto, Lean and Kanban). I started with the grand-daddy of all the methods… Waterfall.

I’m glad that I did… because doing so reaffirmed for me that Waterfall, like most software methodologies, is often misunderstood.

I want to be clear. The whole document maintenance nightmare, lack of customer feedback, hard core linear process of Waterfall is indeed still part of Waterfall. But viewing it in the historical context of the 1970s, I came to realize some of the honourable goals behind the Waterfall process. As a developer, I had to imagine a time where writing and compiling code could be extremely time consuming and costly to do. Suddenly, trying to sort out as many details before writing a single line of code started to make sense.

So when you look at a particular software development methodology, it may be worth taking into account what motivated it’s creators within their historical context. Doing so can allow you to let go of the parts that don’t necessarily fit within your own context and perhaps extract what is still meaningful for you.

Coming back to Waterfall, I extracted a few things that I think are still relevant to me today. Software development requires discipline in order to be effective and (however tempting it may be to do so) we should be careful not to skip steps in order to speed ahead. That being said, which steps are meaningful to you… well… that all depends on your context.