Skip to main content

"agile" "backlash"

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.

Comments

Popular posts from this blog

Reviewing "Context Driven Approach to Automation in Testing"

I recently had occasion to read the "Context Driven Approach to Automation in Testing". As a professional software tester with extensive experience in test automation at the user interface (both UI and API) for the last decade or more for organizations such as Thoughtworks, Wikipedia, Salesforce, and others, I found it a nostalgic mixture of FUD (Fear, Uncertainty, Doubt), propaganda, ignorance and obfuscation. 

It was weirdly nostalgic for me: take away the obfuscatory modern propaganda terminology and it could be an artifact directly out of the test automation landscape circa 1998 when vendors, in the absence of any competition, foisted broken tools like WinRunner and SilkTest on gullible customers, when Open Source was exotic, when the World Wide Web was novel. Times have changed since 1998, but the CDT approach to test automation has not changed with it. I'd like to point out the deficiencies in this document as a warning to people who might be tempted to take it se…

Watir is What You Use Instead When Local Conditions Make Automated Browser Testing Otherwise Difficult.

I spent last weekend in Toronto talking to Titus Fortner, Jeff "Cheezy" Morgan, Bret Pettichord, and a number of other experts involved with the Watir project. There are a few things you should know:

The primary audience and target user group for Watir is people who use programming languages other than Ruby, and also people who do little or no programming at all. Let's say that again:

The most important audience for Watir is not Ruby programmers 
Let's talk about "local conditions":

it may be that the language in which you work does not support Selenium
I have been involved with Watir since the very beginning, but I started using modern Watir with the Wikimedia Foundation to test Wikipedia software. The main language of Wikipedia is PHP, in which Selenium is not fully supported, and in which automated testing in general is difficult. Watir/Ruby was a great choice to do browser testing.  At the time we started the project, there were no selenium bindings for …

Open letter to the Association for Software Testing

To the Association for Software Testing:

Considering the discussion in the software testing community with regard to my blog post "Test is a Ghetto", I ask the Board of the AST  to release a statement regarding the relationship of the AST with Keith Klain and Per Scholas, particularly in regard to the lawsuit for fraud filed by Doran Jones (PDF download link) .

The AST has a Code of Ethics  and I also ask the AST Board to release a public statement on whether the AST would consider creating an Ethics Committee similar to, or as a part of the recently created Committee on Standards and Professional Practices.

The yearly election for the Board of the AST happens in just a few weeks, and I hope that the candidates for the Board and the voting members of the Association for Software Testing will consider these requests with the gravity they deserve.