As I wander from project to project in my career as a software developer, I notice that, despite the remarkable progress we’ve made in technologies and technical approaches over the past decade, one area still seems to give us fits. We love our technology, we love writing code… but, the idea of living by a “process” gives us the “bad sushi” feeling. We’ve lived under the tyranny of “Process Overlords”, whose wisdom we clearly did not understand – especially since the overlords’ grand plans seldom seems to have resulted in something we could bring ourselves to call “a success”. So, we’ve been hurt before. I think we could use a hug now.
I won’t revisit the historical journey our industry has made through the “software process methodology” wasteland. Many of you are as painfully familiar with that story as am I. “Wasteland” – that seems harsh and probably an unfairly critical perspective. But, if the term got your attention, it served its purpose. To be clear here, I’m not saying that there have not been many brilliant and sometimes even effective ideas and techniques proposed and adopted by many people within the software industry. I personally borrow many of the techniques, tools and practices from various methodologies, such as Scrum, XP, RUP and others when I lead or otherwise have a say in guiding a project’s process. When applied in the right situation, most of the ideas embedded within these methodologies work! However, it still seems very clear to me that we tend to talk in terms of “how” and “what” we should do in order to execute or manage a software project. The Agile Manifesto seems to me to have been a first attempt to bring to our attention, among other things, the reality that 1) no one methodology can ever possibly fit the needs of every project and 2) that only thinking that aligns with principles, versus concrete, prescribed practices, has a decent chance of success in the long run.
When I think of the word “principle”, the next word that always pops into my mind is “why”. If I’m going to accept that something is a principle (which, by definition, means the idea applies in most, if not all, situations), I can only truly do so if I understand why it is indeed a principle. So, please allow me to attempt the amazing feat of explaining my thoughts on this subject of principles in a few, short words. I’ll subjectively (even though I often do pretend that I’m “objective”) label these ideas as “truths”:
Truth #1: Only when we take time to understand why something is important can we wisely prioritize.
Truth #2: When we wisely prioritize, we focus on the things that matter and we eliminate, or at least minimize, the need to give unnecessary things our precious time and attention.
Truth #3: Once we know which things don’t deserve our attention, we don’t need to figure out a plan for how to handle those undeserving things and can instead focus on those things that make us successful.
Truth #4: When we can narrow its “process” focus, our team’s members feel less overwhelmed and can focus on delivering useful software. Team members become less resistant to the idea of process, because it’s no longer the mysterious, ugly-as-your-mother-in-law (not YOUR mother-in-law of course, in case your spouse is also reading this), three-headed beast they’d feared – it’s a “light-weight”, and they understand why it’s necessary.
Only after we can understand the “why” is it wise to discuss “how to do” and “what to do”. Within the context of this discussion, “why” involves determining what major process areas we need to address based on past experience and what we believe is likely to happen if we ignore them. Only when the “why” is understood and communicated can the team become unified, confident and bought into the idea of a team process, Once people understand the reason something really needs their energy, most are much more open and accepting, even when they don’t necessarily like what they’re being asked to do. They also tend to feel less overwhelmed, because their focus has been dramatically narrowed. The significance of team buy-in, or at least acceptance, cannot be overemphasized. To be clear, I’m not advocating for unanimous team agreement on all things – which is impossible (and someone’s lying, if all team members always seem to agree with everything) – but that all members understand that there is some purpose, some perceived value, behind the process the team is being asked to follow.
Really, the main point (and maybe the only point) I want to make is this: if we want our teams to be successful, we need to start our conversation with what we believe to be the most important principles to pay attention to in software projects and use those principles as our true North. We must move our conversations, at least initially, away from “what and how?” to “what do we believe we have to pay attention to and why?”. We need to ask and answer the question of “why” certain factors make a major impact on projects. And we need to be courageous enough to refuse to give those areas for which we cannot clearly articulate a “why” any of our attention – or at the least, very little of it. That will allow us to give our full energy to those areas that have the biggest impact on the outcome of our projects. We’ll get around to what to do and how once we agree on why. Once we understand and agree on the “why”, I believe we’ll naturally and much more comfortably arrive at the mechanics of our processes. It’s usually the lack of team and stakeholder agreement and expectation setting on these core issues up front that stir up emotions and hold us hostage to recurring stresses on our projects. We know that people are much less likely to resist buying into things for which they understand the purpose. And yet, we continue often try to levy a prescribed process on teams and then act all confused when the people on those teams exhibit resistance. I offer that we keep the first tenet from the Agile Manifesto in mind constantly – “Individuals and interactions over processes and tools”.
To be clear, this isn’t just about getting people on board – it’s not just about about a “warm and fuzzy”. Asking “Why?” can keep us from spending time doing things that, in the end, really just don’t matter. If we can’t clearly articulate why we’re doing something, chances are there’s something much more valuable we could be spending our time doing. And, this just seems like a much more sane and less stressful approach to software projects. But, who knows, it may even help heal some of our past hurts. Kumbaya