Agile vs Agile (slight rant)

Having done some form of Agile Project Management and development since the late 90’s, I’ve been through the hype of xP and the project management methodologies (scrum, scrum but, kanban…). I’ve seen things which have yielded amazing results and stuff which had poor results. I’m inspired to write this little rant due to frustration with what I see being practiced and called Agile.

In February of 2001, the big heads in software development agreed on 12 Principles and 4 values regarding software development. It can be found at . Though I don’t agree with the pragmatism of following every single one of the principles in every project environment, I’ve found this document to be truly beautiful in its simplicity, accessibility and wisdom. Over the last 14 years, I’ve often referred to the document as a check when I hear clients, team members, or blow hards yelling things which feel suspiciously hierarchical and or “waterfally”. I check the manifesto as though I were referring to the constitution, to see if what I’m hearing is consistent with the principles and values asserted in the Agile Manifesto.

I know it’s too late to keep this short. But in the interest of not turning this into a tome, I’m going to bulletize the things which piss me off and don’t seem to be consistent with the spirit and content of this lovely, lovely document called the Agile Manifesto:

The existence of project management tools, claiming to be agile, which arm hierarchical clients or project managers (who are not necessarily evil but have been brought up in a micromanagement, process centric world) with a million knobs allowing measurement of things which are used to terrorize team members. A simple example would be hours spent on tasks
Emphasis on process over people and results. The wrong team members and bad leadership will not be saved by a great process, agile or not. The spirit of agile is about the minimum but sufficient process to deliver successful outcomes for the customer. Yet project managers, bad scrum masters etc distract the producers of the result with unnecessary data calls and complaints about not following unnecessary process (the TPS report incorrectly filled out)
Where are the business people? So many projects calling themselves agile don’t have real business people as part of the team and then don’t understand why the priorities aren’t correct and the user experience of the software is surprisingly unsatisfying

Agility is about getting the customer teamed up with the right technical leadership and producers of working software, and removing the dumb stuff preventing great people from doing great things. It’s about simplicity. Please read and reread the document.

Relevant Insights

Recent Case Studies

No results found.