Labels, standardization, and missing the point

The problem with putting a label on something is that it becomes all too tempting to commoditize anything that uses the label, to standardize until everything in that label can be turned into a checklist or piece of software. My first real experience with this was with Knowledge Management. So much promise when I first came across the concept and started practicing it in the late ’90s, it wasn’t long (early ’00s) before KM was mostly synonymous with document/content/information management. An inherently complex endeavor well suited to navigating uncertainty was turned into an attempt to capture knowledge as if it were some static thing, to turn every situation into something that can be solved with a past best practice.

I also saw this in my personal life, as I learned more and more about autism and the lives of autistic people. As the parent of an autistic son, I had a lot to learn. The most important lesson I learned was, “If you’ve met one autistic person, you’ve met one autistic person.” And yet, it seemed as if everyone was trying to make me believe that all autistic children were the same, that the “cause” of their autism was the same, and that if I would only do [insert some craziness here] then they would no longer be autistic, or they would be better able to cope, or whatever. Ooh, look, there’s a label, let’s come up with a way to standardize that and get people to use (aka buy) our method to do something with it. Though there may have been some sincere interest in help parents help their kids, mostly it seemed to be about profiting from the situation without worrying about actually understanding the situation.

More recently I’ve been learning about Agile. When I read the original Agile Manifesto I couldn’t help thinking, “Exactly.” This is how I’ve approached most things throughout my career, even though I’m not a developer and don’t work in an “agile shop”. But then I dig deeper and realize that Agile is apparently no different from that early experience with KM. A great idea corrupted by people interested not in the ideas themselves, but in somehow profiting from those ideas. Methodologies and frameworks and do it this way exactly you can’t mix and match because if you do then it is not [insert framework]. And oh by the way you need to take this certification course and take the test because if you don’t then no one will hire you.

OK OK, probably a bit harsh.

All is not lost when it comes to Agile, at least from this beginner’s mind. (I’ve kind of given up on KM.) Ideas such as Modern AgileAgility Scales, and others give me hope that I’m not the only one that thinks this might be the case. I don’t know nearly enough about all of the hundreds (thousands?) of frameworks out there to say that I can use any of them, but I do understand and apply an agile mindset.

I’m still working through these ideas. Would love to hear your thoughts.

Advertisements

Dear PMs, It’s time to Rethink Agile at Enterprise Startups

Eisenhower knew that any plan crafted before battle would be obsolete at first contact with the enemy. In his work, Kavazovic wants to be this realistic too. “Translating this into tech: no long-term plan or product vision survives contact with the user in the product-design sense. That’s why agile methodology is specifically designed to create user experiences that work,” he says. “It’s absolutely suboptimal to design a particular product all the way down to years’ worth of features, make that the blueprint, and build it out.” Inevitably, sticking to a rigid long-term plan without a mechanism to iterate on user feedback would result in features users don’t want, costly re-dos and potentially total product failure.

Source – Dear PMs, It’s time to Rethink Agile at Enterprise Startups