Comments on Agile Manifesto

https://www.spiraltrain.nl/agile-development/

It’s been 14 years since a group of software developers put their heads together and came up with a manifesto that took the IT world by storm. We asked Agile Manifesto co-author Brian Marick what remains of the original ideas today.

It all started with a group of “17 naive, middle-aged white guys,” Dave Thomas once recalled. Sharing a belief in responsiveness, in customer collaboration and in “better ways of developing”, these few programmers penned the Manifesto for Agile Software Development, which, for better or worse, would become one of most hyped programming concepts IT had ever seen. To refresh our memories:

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer 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.
(from the Agile Manifesto)

But for all their good intentions, there was a gap between the what of the Agile Manifesto and the how of Agile practices. And in this gap, countless industry entrepreneurs saw one question – how can I monetise this?

In recent months, we have witnessed a growing amount of disillusionment, with many influential thinkers questioning the relevance and wellbeing of Agile, while some claim business value should come before manifestos. Although he couldn’t comment on what Agile will mean in 10 years time, Agile Manifesto co-author Brian Marick told us he believes Agile still matters today.

JAXenter: Do you believe the Agile Manifesto still applies today as much as it did in 2001?

Brian Marick: To the extent that you take “we are uncovering” seriously, yes.

Of the four values, I think “individuals and interactions over processes and tools” is often used as a club to rule out discussions of processes and tools. Which is too bad.  In 2001, individuals and interactions were lower in status than processes and tools. In 2015, the reverse is true – at least among the people who, because they are good at individuals and interactions, have the most sway in most organizations. But it turns out that tools and (informal, tacit) processes are really important.

Does it annoy you that the word ‘Agile’ is being used so loosely?

It did for a while, but not any more. People who are taking organizational change seriously can find out the difference pretty easily. People looking for a quick fix were always going to be fleeced by someone anyway.

What do you think needs to change in the Agile movement?

In the beginning, Agile was a rare fusion of the social and the technical. I often quoted Pete McBreen, who said “the Agile methodologies are methodologies created by people who like to program”. (That wasn’t strictly true, but those people had a much larger influence than in previous methodologies.)

Since then, the programmers have largely decamped from Agile. That’s led to a gap in the conversation. As someone (who wanted to remain anonymous) once wrote me:

“I’ve also been tired for years of software people who seem embarrassed to admit that, at some point in the proceedings, someone competent has to write some damn code.”

Those people are doing the work the Agile “movement” should be doing, except in places like language-specific venues (Ruby, for example), open source, or the Software Craftsmanship conferences. What’s left behind too often falls into generic management teaching of the “a good manager can manage anything” sort and/or variants of things Jerry Weinberg popularized in a very different technological environment (which I disagree with because I don’t think culture is independent of technology).

As a result, for example, the emphasis on face-to-face collaboration has left Agile with little to say to the ever-larger number of people who work remotely (beyond “you shouldn’t exist”).

(A reminder of) The Twelve Principles of Agile software

Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

(via agilemanifesto.org)