Recently, the stellar community of Ottawa Agilists gathered to share stories about Agile regrets and success. The first session was hosted as a “fail faire” and the second session was hosted as its’ counterpart… a “success faire”. As an outcome, we attempted to gather the “lessons learned” and “secrets of success” for each event respectively.
Having hosted both these sessions, it was interesting to me how much harder it was to root out the source of success over the lessons learned. In part, this came from the participants themselves… story tellers were more apt to share directly what was the cause of a failure. Success stories were related in more detail about “what happened” rather than “what exactly made this work”.
This got me thinking… why don’t we pin point the source of success with the same attention and effort we do causes of failures?
Could be that we don’t analyze success with the same interest because… well, it worked… what is there to analyze further? Sure, I get it.
However, just like not all steps undertaken when we make a mistake are necessarily causes of our failure, not all steps that were undertaken when we succeed necessarily meaningfully lead to our success.
And just like we identify root causes of mistakes so that we don’t repeat them, we should seek out the root causes of success… so that we can repeat them.
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.
Lately, I’ve been thinking a good deal about how Agile teams are able to deliver value. I believe that a common trait shared by teams who skillfully deliver value is a shared vision centered around compassion for their users.
Teams who consistently can design, implement and test to deliver frequent and highly valuable products to their customers are connected to their users. Not just in the sense that they are able to interact and communicate with them, but in the sense that they clearly understand the user’s problems.
Understanding their problems means that everyone on the team…
…can clearly articulate the problem their work is attempting to solve. The whole team understands the rationale behind the solution they are implementing.
…understands the value of solving this problem. They understand why they are solving one problem over another.
…can identify with this problem and is empowered to do something about it. The team has a “two brains are better than one” approach to problem solving in general.
These compassionate teams understand that everyone on the team is working hard to solve these important problems for their users. It is this shared compassion that gives their work a sense of purpose and urgency. It is the fuel that keeps them focused every day.