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:

  • “Who is going to write the code?” I asked.
  • “I am…”
  • “OK, who checks things into source control?”
  • “Me, I guess, …”
  • “So what’s the problem, exactly?” I asked. “You have absolute control over the state of each and every bit in the final product. What else do you need? A tiara?”

How to be a program manager, Joel Spolsky

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:

  • get ignored, or
  • need plenty of updating on the way.

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 programmers, 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.