Start with the Agile Manifesto
There are generally two groups of actors in a software development project: development teams and the client. (It’s rare to see a credit union whose decision-makers are also the coders, so bear with me here.) To do “agile” correctly, both sides need to get on the same page on what that means for the project. The original Agile Manifesto remains the right place to start.
Manifesto for Agile Software Development
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.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
Copyright 2001, the above authors - this declaration may be freely copied in any form, but only in its entirety through this notice.
I recently digested a post by Benjamin Estes at digital marketing agency Moz that points out:
Notice anything strange? This isn’t about project management. It’s about culture. In fact, “Agile” development teams use many different project management styles—like Scrum or Kanban.
Instead, the manifesto promotes four cultural biases. Being “Agile” means allowing these biases to be major influences in decision making. In everyday life “bias” is often a negative word. It suggests a lack of objectivity. However, being opinionated about the choices you make is the essence of company culture. And it turns out that some cultures are more effective than others. Changing project management styles isn’t enough. Organizations that try to “be Agile” through changing project management styles, without considering culture, may be dissatisfied with the results.
Admittedly, I’ve never done this before on a project, but why not put this on the table at the first meeting of each software development endeavor?
If development and decision-makers aren’t aligned in either embracing or rejecting the priorities as outlined in the manifesto, both sides may bang their heads against walls as code comes together.
Let’s be clear about one thing. I say we should be on the same page about embracing or rejecting agile on a project.
Also, Matt recently shared with me a counterpoint article, discussing Agile being trashed by an outspoken developer at a conference in late 2014. It’s a fun read if you get into these things. My favorite snippet (emphasis mine):
The talk [bashing Agile] has been debunked by technical architect Nic Ferrier, formerly at ThoughtWorks, a software development company which uses Agile techniques. “It’s not Agile that sucks, and [is] dragging programmers down. It’s the inability of programmers and business people to understand each other,” he said.