Jonathan Kohl has a wonderful essay about the zeitgeist as it relates to A/a/gile software development.
Maybe it's because I only started making a living with software in my 30s (after being a bass player, librarian, and bartender); maybe it's because when I started, I was working on venerable systems (US 911 data-validation systems written in COBOL and C) created and maintained by smart, engaged people, but things like this don't make any sense to me:
"...companies being torn apart from within as factions rage against each other, grappling for methodology dominance..."
"...berated for not knowing the Agile lingo, and being belittled as "waterfall", and "backward" when they would ask innocent questions."
Jonathan assures me that this sort of thing goes on. Craziness.
I have to leave this business aside, though, because, while it's interesting, it doesn't affect the price of eggs in China. The meat of Jonathan's essay (for me) is here:
"...any skilled team can make a process work for them and do good work, and any team lacking in skill is going to fail no matter what process they are using."
Skill of course is critically important. (The Economist had an article a couple of weeks ago pointing out that even while companies are outsourcing function to India and China, they are desperate for talent, and will hire talented employees anywhere in the world they find them.)
Other *human* attributes are also critically important. Here are some favorites:
The ability to change your mind:
What happens if someone comes to you and says "you should be doing your work *this* way". What if they're right? I was on a project at ThoughtWorks where we'd been going along feeling a little bogged down. A new developer joined the project and said exactly that: and everyone agreed, from the architect with the Ph.D. to the testers to the customers. If you can't change your mind, you are an evolutionary dead end.
Rhetoric:
Can you change someone else's mind? I have a perfomance-test project where I sure hope I can. The framework I inherited is hard to use. I'm pretty sure I have a better alternative. I've coded about 70% of my alternative. Now I have to make my case. Wish me luck.
Listening:
What are the people on the project saying? What do they need? How is it going? What's working, what's not working? Do you have any idea? If you don't know what's happening with the people, then you don't know what's happening with the project.
Big Vision:
One system I worked on was developed before the advent of relational databases. I worked on a project to convert a gigantic, life-critical database from flat files to SQL. We could not have done it without the vision of a Vice President who *knew* that we needed to have this information in a modern database. His vision was absolutely critical to the project, and he oversaw the project from beginning to end.
We've been saying it for 20 years, but it bears repeating:
THERE IS NO SILVER BULLET.
There is skill; there is talent; there is communication; there is vision; there is engagement; there is interest; and then there are methods and methodologies and processes from which to choose, or not. Those processes that emphasize
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
seem like they are more likely to succeed in most cases.
But there is also history. Here is a post-agilist confession: when thing go seriously pear-shaped for me, I always reach for one of two ideas to pull things back on track: either the V-model of software development; or the IEEE 829 spec. I hear the agile vigilantes coming for me as I type this. Luckily I live in the middle of nowhere.
First of all, my favorite formulation of the V-model of software development resembles Brian Marick's deconstruction more than the classic formula. You just can't go too far wrong by
saying what you're going to build, and validating that it is correct;
designing what you've said, and validating the design;
building what you've designed, and validating the building;
and testing what you've built.
Whether that cycle happens in a week or a month or a year is a matter of choice for the people doing the work.
I think it's stupid of the IEEE to use their copyright on the 829 spec to generate income. Frankly, the last time I needed the 829 spec, I bootlegged it off of a Russian site. No, there are no copies of the 829 spec on any drive on any computer to which I have access, so please don't sue me.
There is this idea in English literature of the 5-paragraph essay, and it translates nicely to software development. This idea is embodied in the V-model and in the 829 spec.
Tell the people what you are going to do.
Do what you said you would do, in an orderly manner.
Tell the people what you just did.
From this rises most of literature, most of culture, most of collaboration...
...and the best of software.
Maybe it's because I only started making a living with software in my 30s (after being a bass player, librarian, and bartender); maybe it's because when I started, I was working on venerable systems (US 911 data-validation systems written in COBOL and C) created and maintained by smart, engaged people, but things like this don't make any sense to me:
"...companies being torn apart from within as factions rage against each other, grappling for methodology dominance..."
"...berated for not knowing the Agile lingo, and being belittled as "waterfall", and "backward" when they would ask innocent questions."
Jonathan assures me that this sort of thing goes on. Craziness.
I have to leave this business aside, though, because, while it's interesting, it doesn't affect the price of eggs in China. The meat of Jonathan's essay (for me) is here:
"...any skilled team can make a process work for them and do good work, and any team lacking in skill is going to fail no matter what process they are using."
Skill of course is critically important. (The Economist had an article a couple of weeks ago pointing out that even while companies are outsourcing function to India and China, they are desperate for talent, and will hire talented employees anywhere in the world they find them.)
Other *human* attributes are also critically important. Here are some favorites:
The ability to change your mind:
What happens if someone comes to you and says "you should be doing your work *this* way". What if they're right? I was on a project at ThoughtWorks where we'd been going along feeling a little bogged down. A new developer joined the project and said exactly that: and everyone agreed, from the architect with the Ph.D. to the testers to the customers. If you can't change your mind, you are an evolutionary dead end.
Rhetoric:
Can you change someone else's mind? I have a perfomance-test project where I sure hope I can. The framework I inherited is hard to use. I'm pretty sure I have a better alternative. I've coded about 70% of my alternative. Now I have to make my case. Wish me luck.
Listening:
What are the people on the project saying? What do they need? How is it going? What's working, what's not working? Do you have any idea? If you don't know what's happening with the people, then you don't know what's happening with the project.
Big Vision:
One system I worked on was developed before the advent of relational databases. I worked on a project to convert a gigantic, life-critical database from flat files to SQL. We could not have done it without the vision of a Vice President who *knew* that we needed to have this information in a modern database. His vision was absolutely critical to the project, and he oversaw the project from beginning to end.
We've been saying it for 20 years, but it bears repeating:
THERE IS NO SILVER BULLET.
There is skill; there is talent; there is communication; there is vision; there is engagement; there is interest; and then there are methods and methodologies and processes from which to choose, or not. Those processes that emphasize
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
seem like they are more likely to succeed in most cases.
But there is also history. Here is a post-agilist confession: when thing go seriously pear-shaped for me, I always reach for one of two ideas to pull things back on track: either the V-model of software development; or the IEEE 829 spec. I hear the agile vigilantes coming for me as I type this. Luckily I live in the middle of nowhere.
First of all, my favorite formulation of the V-model of software development resembles Brian Marick's deconstruction more than the classic formula. You just can't go too far wrong by
saying what you're going to build, and validating that it is correct;
designing what you've said, and validating the design;
building what you've designed, and validating the building;
and testing what you've built.
Whether that cycle happens in a week or a month or a year is a matter of choice for the people doing the work.
I think it's stupid of the IEEE to use their copyright on the 829 spec to generate income. Frankly, the last time I needed the 829 spec, I bootlegged it off of a Russian site. No, there are no copies of the 829 spec on any drive on any computer to which I have access, so please don't sue me.
There is this idea in English literature of the 5-paragraph essay, and it translates nicely to software development. This idea is embodied in the V-model and in the 829 spec.
Tell the people what you are going to do.
Do what you said you would do, in an orderly manner.
Tell the people what you just did.
From this rises most of literature, most of culture, most of collaboration...
...and the best of software.