The Agile Manifesto was published more than a decade ago in 2001. Since then, the industry has sometimes morphed the message of what it means to be Agile. Sometimes confusing or merging it with Lean development, Scrum and Kanban manufacturing (which all add great things to the mix). Though with any real truism, the wisdom in it still rings through today.
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,we value the items on the left more”
Manifesto for Agile Software Development https://agilemanifesto.org/
For me at a top level, these four statements can sum up nicely as: We focus on providing value to customers, over perfecting what we do or need internally to create this value. And while our execution is important, it should always be in support of delivering this value.
This is probably why people merge Agile with Lean, because they both at their core focus on delivering value to the customer as the top priority.
Lofty sentiments, but how do we make it work. I’ve always said that I live in the valley, not on a mountaintop.
Most of us have experienced the negative impacts of overworked or outdated processes, ineffective tools, inadequate knowledge transfer, crippling contracts and non-achievable plans. As well as too much focus inwards, with corporate silos who communicate poorly and yet spend time in endless meetings.
At the risk of sounding trite, I’ll use another cliché: I’ve always been able to fly high when I know I have a strong net to catch me if I fall. So while the items on the right are valued more, we do need to make sure that they are balanced with items on the left that support us. For me that is the measure of the thing.
I’ve been in the enviable position where I’ve been in charge of implementing software that has had a real impact on the people who are going to use it. As technical people we are in truth tool makers, which is why the first statement is so important for us. When we introduce a new tool into a business, it can often disrupt the current processes or can highlight inefficiencies. Processes often have to change as a result of the introduction of the new tool. With the processes up-ended, the people have to change how they use it to do business – and doing business is actually just interacting with others over common goals. So, while we are implementing software, we are often actually implementing change. If we keep our focus on the people and how they will use the tool we are introducing, then we will reach the higher goal.
Having managed major escalations, it’s amazing how much documentation and time gets created over a major fault. Impact analysis, root cause determination, emails… Yes, getting the thing done and right in the first place is the most important. Because getting it wrong, is a work and cost generator in itself. At the same time, I’m sure we can all relate to having gone into environments where you almost needed CSI skills to figure out how or why a thing is done. There needs to be enough of a documentation trail to support what is happening and to save your company from knowledge walking out the door if you lose your good people.
Moving away from a business example, I sometimes think every young couple with romantic ideas of love should engage in the process of agreeing a pre-nup. Not because the marriage might fail, but because having to agree and collaborate on terms is a great exercise in learning what is important to the other person, what they value and what they would do in the case of a problem. Contracts are important, but they should be collaborations and negotiations.
Often, when I’ve been involved in contract negation, it’s been when we are agreeing the terms of acceptance. It’s how you decide a thing is actually done and you can receive payment – and how you handle the straggling snag list that might be left behind. One of the more interesting times, was right after the dot.com scandals related to revenue recognition. I was often rolling out bleeding edge software to companies that wanted to be first to market with a feature or app. So they wanted to be able to make the decision to possibly go live with something buggy to make their go-to-market goals, but still hold us accountable to fix things as a priority. We needed acceptance to recognize revenue, so we had a clause that said if you go live we will deem it accepted. It was only fair that if the customer was making money from it (using it for their customers) that we should as well. So the collaboration occurred in how we contractually described how we would work together, in that grey period after go-live, so that each party achieved their business goals. Hammering it out first, rather than as escalations at the critical go-live time was essential to our project collaboration in the long run.
The last point is too obvious. Project management is like navigating a sailboat; you get to the destination through tacking, a series of course corrections. Not by sailing straight into the wind. You don’t abandon having plans, you just need rules of engagement around it. To be agile, is to be able to adapt quickly when new information arises or goals change. Change will happen, and being equipped with a mechanism to respond to change is essential.
So that’s the net from my perspective. Yes we consider the things on the right as important; we just value the things on the left more. The cleaner and sharper the things on the right are and the greater they are anchored on helping the things on the left, the more they actually recede into the background in terms of importance and allow us to focus on the higher goals.
What is your perspective?
Originally published on LinkedIn Pulse on June 25, 2015
