Uncharted Waters

Aug 24 2016   5:26PM GMT

Music City Agile and PAST

Justin Rohrman Justin Rohrman Profile: Justin Rohrman


I attended and spoke at the first run of Music City Agile last Wednesday. Music City Agile is a one day conference themed around, your guessed it, agile software development. A sister conference, Music City Code ran the following Thursday, Friday and Saturday. Jim Benson ran the opening keynote on Post-Agile Stress Disorder (PAST). Jim presented what seems to be a more common theme: consultants arrive at a new gig and present a set of tools and process that will fix every problem. Once that consultant leaves, the tools stick and the process mostly washes away. New consultants arrive at a regular pace and present their preferred tools and process. This happens over and over again.

All in all this was a very well run conference. I’d like to talk through a little of my experience with what Jim described in his keynote.

One of the last companies I was employed full time at had an almost identical pattern to what Jim described. Instead of new consultants, we had a revolving door that would pump new leadership into the organization every 6 months. The last VP of development during my tenure had some experience working in agile, but not enough to give him the words to describe what he wanted from us. He made up for that by reading any agile reference book he could find, and inundating the development team with his vision of scrum, kanban, sprint flow, and grooming meetings. Potentially productive meetings were consistently shanghaied by that manager.

This is a sour memory for me, but I am confident other people have had similar experiences of managers intervening on perfectly functioning teams.

music city agile

I suspect the problem is legibility, how easy it is for someone to understand what is happening in a group of people when they are an outsider. Agile presents a set of principles, but no specific way to spin them into action. Every development team takes the principles, implements them in slightly different ways, and creates little microcosms of culture and process. Managers that aren’t engaged with the teams on a daily basis, the type that are required to gather data to funnel up to other decision makers see these groups as black boxes.

You already know this part of the song. Managers, bad managers at least, that don’t understand what is happening end up bulldozing what is already happening to make room for their own personal brand. Not because it is better, or because what is happening already is bad, but because they understand it better than what is already there and can describe it to their managers. Managers that don’t know how to inspire change hire consultants to make it happen for them.

The development world wants to make agile fit large organizations with detached, disengaged managers. Frameworks (and the consulting sold along with it) like SAFe are testament to that. SAFe is an attempt to add standardization to process that was designed to rebel against unnecessary and premature standardization.

Agile is like chess. At a superficial level, things are very simple. Just a few pieces, and a few ways to move those pieces. When we get into the game though, and involve people, things are very complicated. Post-Agile Stress Disorder is one way to describe the problems people are having. Thanks to Jim for the interesting Music City Agile keynote, and thanks to everyone that made the conference happen. See you all next year.

1  Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • PACK44
    IMHO/FWIW Agile SW Development is one of the most over-hyped, over represented and over-promised "tool" or "process" ever to hit (and beset) high tech and software development. Drank the forced cool-aid (Rev Jones style), got the training, talked the talk and wrote the user stories and ran the scrums on our monthly agile pacing cycle. In the end, nobody could say with ANY degree of confidence what the exact committed code drop release "schedule" or "functionality/feature set" or bug discover/fix curves were. Just gave engineers a lot of wiggle room and/or nagging frustrations -- especially when dealing with upper management and "the field sales team." And before you dismiss this as coming from some "disenchanted accidental Agile convert" or mismanaged/misunderstood Agile adoption/integration effort, dig this -- our company was actually pretty "successful" with it and had lots of good Agile champions, disciples and roll-out efforts/results for product development and sustainability. But in the end, lots of SW (especially by new start-ups) gets shipped under "Agile Development" that is no better than beta code -- sometimes alpha/proto code -- that gets sold and promised to customers who are actually expecting 'more' in terms of features, regression testing, QA and reliability. So I really liked your post WRT post agile stress. Not saying it's a bad thing at all. Just all too often often hyped as "the second coming" for software development. Besides, there's a lot to be said for those well-defined market, product and functional requirements documents...again, IMHO. In the end, those "consultants" and "Purveyors of the Agile change culture" experts made (are making) heaps of $$$s on this...and write lots of books.
    60 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: