I Assume That I'll Never Complete My Work, And I Plan Accordingly
What I'm about to say is nothing new - I've discussed working under constraints many times in the past. But, after my post on the deleterious effects of working at full utilization, I had a moment of insight that allowed me to coalesce some feelings into more meaningful thoughts. I realized that part of what makes me (and my team) so effective is that we "embrace the angel of death". Because the very existence of our team is in constant jeopardy, we have to assume that we won't have time to finish our work; and, we plan our feature development accordingly.
In The Four Agreements, Don Miguel Ruiz talks about embracing the Angel of Death as a means to attain personal freedom:
The final way to attain personal freedom is to prepare ourselves for the initiation of the dead, to take death itself as our teacher. What the angel of death can teach us is how to be truly alive. We become aware that we can die at any moment; we have just the present to be alive. The truth is that we don't know if we are going to die tomorrow.
When we accept the fact that we can die at any moment, it allows us to live in the present; and, to make choices that we know we will be happy with. It's the bromide, "Live every day as if it were your last"; only, it sounds much classier as Toltec wisdom.
On my team - the Rainbow Team - death is a constant companion. Many people at my company don't understand why my team exists. They don't understand why we try to innovate for our customers. If they could snap their fingers and have their way, my team would cease to be.
I have to operate under the assumption that my team may not exist tomorrow.
Part of my team's charter is to handle a high volume of interrupt-driven work. Something, it seems, is always on fire; and, it's my team's responsibility to put that fire out. Which means dropping whatever I'm doing and switching into emergency mode.
I have to operate under the assumption that my priorities might shift tomorrow.
As my team becomes more resource-constrained, and my teammates are reallocated onto other tasks, the relative load on any one individual increases. And just as a circuit breaker pops open in an effort to prevent larger, catastrophic failure, so too must we short-circuit our work in order to maintain forward momentum.
I have to operate under the assumption that my current load may be shed tomorrow.
Because tomorrow isn't certain for my team and our priorities, we are forced to look at our work and to figure out not only how to build it iteratively; but, to iterate in such a fashion that every step along the way adds unique value. Because, every step that we take may be our last. And, if that step isn't adding customer value, then it was nothing but time wasted.
This forces us to ask the question, if we had to deploy something today, what could we deploy that would add value to our customers? And then, we do that thing. And then we repeat this dance the next day. And the day after that. And, every day, whether we feel good about it or not, we deploy a little value for our customers.
As Ryan Singer points out in Shape Up, even if we don't love each incremental step, we can take comfort in the process:
It helps to shift the point of comparison. Instead of comparing up against the ideal, compare down to baseline - the current reality for customers. How do customers solve this problem today, without this feature? What's the frustrating workaround that this feature eliminates? How much longer should customers put up with something that doesn't work or wait for a solution because we aren't sure if design A might be better than design B?
Seeing that our work so far is better than the current alternatives makes us feel better about the progress we've made. This motivates us to make calls on the things that are slowing us down. It's less about us and more about value for the customer. It's the difference between "never good enough" and "better than what they have now." We can say "Okay, this isn't perfect, but it definitely works and customers will feel like this is a big improvement for them." (Shape Up, Page 105)
It's not a perfect system. My team doesn't have the luxury of employing a "long term strategy"; so, there must always be a healthy tension between getting work done today and investing in a better tomorrow. That said, even if we did have more time and resources, I believe there is a lot of value in how my team operates. I wouldn't want to give up our approach; rather, I'd want to layer-on more strategy.
Reader Comments
Great insights, especially as a build out from your previous post! It is telling, I think, that your insight here led you to re-invent Scrum, or Agile at least. One of the keys to Agile that often gets forgotten is that the focus must always be on Next Highest Value.
And, yes, everything that is Done should be a deployable increment, because if it doesn't get into the hands of users, no matter how good the feature is, it has No Value.
Scrum is also based on the underlying assumption that a product is never "finished" and it's work is never done until the last user logs out and the server is shut down. Which also, I think, is just a variation of your point that "we won't have time to finish our work".
@Jason,
A while back, I was listening to an interview with David Heinemeier Hansson (DHH), of Basecamp (and ranting) fame. And, he said something that really struck a chord in me - he was talking about how all three version of Basecamp are backwards compatible and that even to this day (at the time of the interview), a user could choose to back to the old version. He talked about maintaining "legacy software" is the cost of building a legacy. And, that just hit me right in the feels! I think we are often too quick to forget what it is that got us here.
As far as the Scrum stuff, I know what you mean. I was actually listening to another podcast interview (I don't do much else with my life) with one of the signers of the original Agile Manifesto, and he was saying that one thing people seem to forget most of the time is the evolutionary nature of agile development. Small, incremental changes made and delivered over time. Then, re-evaluating, evolving, continuing to build. He was saying that this is really the core part that makes agile work.
@Ben,
Yes, DHH has always taken that approach to 37Signals and now Basecamp products, and it is a remarkable legacy, frankly. But it definitely takes planning and commitment, and that can be hard to find these days, especially on the "business" side of many organizations, which is too bad.
It's one of the reasons I like feature-flagging, which I know you've blogged about before: it doesn't necessarily have to matter to me as an architect or a developer if I "leave old stuff in there" as long as users (or admins) can easily manage the settings and users still want things the old way.
Again, as long as there's Value, then Agile tells us we shouldn't spend time tearing it out! we should continue to focus on Next Best, unless there's a damn fine reason to kill stuff off behind us.