| This article cements in my mind the issue: devs tend to take away from agile what they expect to find, rather than taking the time to understand the motivations and whole scope of activities. Historically, most software development methodologies are excessively top-down, so people somehow still expect that from agile. Most devs are the sort that couldn't stand doing group projects in school, so the idea of organizing with teammates to produce something bigger and better than I could on my own is totally foreign. If you don't explicitly name your development methodology, you still have one: you're practicing something called ad-hoc development. Unless you and your entire team are superheroes, there's an awful lot of knowledge being leaked away. Here's the secret: software development isn't really about making computers work, it's about organizing knowledge. If your process focuses more on making the computers work than your institutional knowledge you're making a critical mistake. Don't confuse some company's crappy engineering practices for agile just because they call them that. Stand ups are short. Period. If it feels like a "permanent PIP" your team could use some improvement. If it feels like a surveillance state it's probably not a very good implementation of agile. Agile development is about making connections to your team members: individuals and interactions over process and tools. It sounds like the author's experience (as well as many other devs') is unfortunately in an organization that doesn't pay heed to that very first, most important agile principle. |
See, this kind of vague, fuzzy feel-good description is exactly why it seems to me that the one thing everyone seems to agree on about Agile is that everyone else is doing it incorrectly.