4 ms·
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
by couchand 12y ago
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.
- father_of_two 12y ago"permanent PIP" -- didn't got this part, can you explain? that couldn't stand doing group projects in school Hm, how did you found that about me? :-)
- couchand 12y agoI'm assuming the author meant Performance Improvement Plan, which is business-speak for "we're going to fire you in a month."
- calibraxis 12y agoI agree devs carry many dysfunctions. But big-A Agile is a management school with its own dysfunctions. It diverges from small-a agile, which is basically a set of principles to help critique yourself with. When you hire a manager (or "Scrum Master" whatever), they must convince top management to give them a job. Which is why Scrum Masters brag about their bosses "believing in" Agile, like a bishop happy that the king loves god. Then they impose some system which requires their highly visible involvement. (That said, the Agile described in this article diverges from my personal experience.)
- outsidetheparty 12y ago>Agile development is about making connections to your team members: individuals and interactions over process and tools. 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.
- ddoolin 12y agoAgreed. I'd like to see some solid experiences that counter the author's claims being used in the wild that fit where he says it doesn't work well (anything other than small, short projects). Nearly everyone is taking the "it's not us, it's you!" approach. A lot of things work well in theory. That doesn't really make them good ideas if they can almost-never be implemented properly.
- Nizumzen 12y agoYeah. Communism is great in theory as well. It doesn't work though.
- geometricalgebr 12y agoThat's literally the first line of the agile manifesto. If that isn't agile, then agile is completely meaningless.
- fsloth 12y ago"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." That's a fantastic quote, thanks.
- walterbell 12y agoYou may like Philip Armour's Five Orders of Ignorance, http://www-plan.cs.colorado.edu/diwan/3308-07/p17-armour.pdf http://www-plan.cs.colorado.edu/diwan/3308-07/p17-armour.pdf "0th Order Ignorance: Lack of Ignorance. I have 0OI when I (probably) know something. 1st Order Ignorance: Lack of Knowledge. I have 1OI when I don't know something. With 1OI we have the question in a well-factored form. 2nd Order Ignorance: Lack of Awareness. I have 2OI when I don't know that I don't know something. 3rd Order Ignorance: Lack of Process. I have 3OI when I don't know a suitably efficient way to find out I don't know that I don't know something. 4th Order Ignorance: Meta-ignorance. I have 4OI when I don't know about the Five Orders of Ignorance. "