Agile? Yeah, we do Kanban. We’ve got our user stories, backlog and deliver iteratively. All good. Except that that’s not what Agile is. Not at all. It’s not the planning poker, story points nor squadrons of Scrum Masters. It’s the spirit.
Whenever the name Agile pops-up, invariably follows the “manifesto”. The 4 principles that you and I have seen over and over again and know by heart. Or do we? We definitively should because they are the Agile. They’re a way of approaching software development, while Kanban, Scrum, XP and all the others are just tools built to serve these very principles.
By declaring to be Agile software developers, we commit to value:
Individuals and interactions over processes and tools
Joel Spolsky has a fun recall of a conversation with a programmer:
It’s people, who make the software that works wonders. No process or tool ever produced anything on its own. It’s the combined power of all the team’s brains that spawns code and turns dreams into reality. It’s in the casual conversations that new ideas are born. It’s in the war rooms that they’re developed.
Processes are only there to get repeatable tasks off people’s mind. If you find yourself repeating the same steps over and over again, for instance when releasing code to a live environment, write a checklist, so you don’t have to rediscover the wheel every time.
Better yet, write a script to automate the the tasks. Tools are there to support programmers so that mundane work takes less time and more brainpower can be used for creative work. Neither tools nor processes should limit people in any way.
That’s why Agile development methodologies are often very open bags of best practices, rather than hands-on manuals. They’re meant for people to digest and adapt to their needs.
Working software over comprehensive documentation
We can always tell whether we like the software we work with. Whether it meets our needs and expectations. But we can’t reliably say whether we will like the software based on specifications. We can’t even properly express our thoughts in writing. It’s insane to expect a programmer to understand our intentions based their flawed description. While the natural reaction is to produce even more documents, it only ensures that they either:
An Agile team demonstrates small portions of fully working software to collect feedback and stick it right into the development process. The team delivers all layers that make up a particular feature, because then and only then does the result have business value. Only then can it be measured as a completed step towards the ultimate goal. And that goal is never the software itself but always solving real-world problems. That is why requirements are described as user stories, so that everyone involved stays focused on the business impact of their work.
Customer collaboration over contract negotiation
Everyone involved in producing a piece of software plays on the same team. The customer wants a product that will meet his needs and the developer wants to make the customer happy by delivering one. Any conflicts inside the team are nothing but a waste of energy, that should be used elsewhere.
There is no space for complaining about incompetent customers, lazy programmes, stupid managers and those a**holes that are “too stupid to get it.” Every person is probably pretty smart and reasonable, or else she wouldn’t have her job in the first place. Communication issues must be distinguished from emotionally charged judgments.
Agile teams keep their customers close. Perhaps not “on” the team and in the office daily, but staying in touch often, asking questions, clarifying issues as they pop up, and regularly demonstrating progress.
Contracts are created merely to protect their signees. When projects work well, everyone may as well forget that they exist.
Responding to change over following a plan
“Another layout change? They’ve got to be kidding.” is the attitude most programmers present towards modification in project scope. “Why can’t they make up their minds?” I already argued that that is not possible. Everything about a project may change at any moment, because the reality around us changes and because our minds change once we face reality. Accept it, embrace it.
A plan is still necessary so that everyone knows where the project’s heading and can make credible commitments about it. Therefore, in the words of general Eisenhower “plans are nothing; planning is everything.”
Agile teams keep their plans light and flexible, so that adjustments don’t require hours of fixing dependencies (I’m looking at you, Microsoft Project). Changes are expected to pop up until the last minutes of the schedule, so everyone treats them as regular, daily business.
Customers are happy, being free to produce new ideas and see them implemented. In the end they will still receive something of true value.
So, are you an Agile software developer? Stop talking about user stories and Kanban. Start talking about business and people.
You cannot build a team merely by replacing “me” for “we” in communication. You won’t get there either by placing people in one room and giving them a common name. A team is much more than a group of individuals sharing the same space and some characteristics. What binds a team is spirit, not labels.
A leader’s role in team building is defining and distributing work in such a way, that naturally requires team cooperation to achieve goals. Ideally, failure to cooperate should result in failure of the whole team. Remember the movie “300“? Leonidas explains to the deformed Ephialtes how Spartans fight: as a single, impenetrable unit. Arm to arm, fighting the same enemy, protecting each other. That is team spirit.