Scrum revisionism

On one of the CTO mailing lists I am on, there was a thread on scrum and whether it was just another useless or harmful fad in software development. The seed of this conversation was a post by Michael Church https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/  which severely critiques scrum and agile methodologies. Some of his points was that agile infantilizes programmers and inhibits their creativity. Timeboxing, sprints also tend to focus on short term goals and deters long visions, and is insulting to senior programmers. 

This conversation led me to review my team's adoption of scrum and agile management. The first thought I had was whether we view agile as a method or as a framework.  Given our team's history, I would say we use it as a framework. Our business has a very horizontal organization more like a law firm, and Church's critique stems from agile being used as a top down management technique. Since we tend to work more as peers, we use agile as a framework to take our mutual long term vision and break it down to manageable pieces to make progress. In fact we have so much creativity going on, we need scrum in order to channel it and prioritize the fire hose of ideas. These are the benefits we are are seeing. Church sees benefits only to management in scrum's ability to track programmers work and hence see if they are slacking. I think Church's real critique is about management attitude and organizational cultures, rather than the Agile methods themselves.