3 Comments »

Dave Nicolette said:
Bill,
I find the questions in your poll more interesting than the answers, in a way. The first question presupposes that a methodology will make us succeed or fail. At least, it seems that way based on the phrasing. I think the choice of methodology depends on the problem to be solved and the conditions surrounding the project or program that is meant to solve it. Even when we choose an appropriate methodology for our purposes, it’s up to us to achieve success. We can’t credit the methodology for success or blame it for failure, any more than we can credit or blame a carpenter’s hammer for the quality of the cabinets he builds. A methodology is just a tool. If it’s the right tool for the job, then it’s up to the carpenter to make something with it. If it’s the wrong tool for the job, the carpenter will probably work around it rather than with it.
I’ve often heard/read people condemning this or that methodology because “it” failed in some context, when in fact they had to work around the methodology because it didn’t fit the problem in the first place. Thus, we have people condemning predictive processes because they were trying to use them on projects that had high uncertainty, and people condemning adaptive processes because they were trying to use them on projects that had significant governance requirements.
Does that sort of assessment really tell us anything about the strengths and weaknesses of a methodology? Can we tell much about it if we didn’t really use it? Can we tell whether respondents to the survey “really” used the methodology they claim to have used, just because they clicked a certain radio button on a form?
The second question is interesting in a similar sense. If my team chose an appropriate methodology for the context they were working in, and they used the methodology properly, and the project was deemed successful, then it was because the methodology as a whole fit the problem well, and not because of just one aspect of the methodology.
I was on a panel a couple of months ago and we were asked, “What is your favorite software development practice?” I replied, “Lunch.” The answer got some laughs, but the real point was that you can’t pick just one practice out of the middle of a methodology and say it’s going to bring you success out of context. What’s the “best aspect” of the carpenter’s favorite hammer? Is it the shape of the striking surface? The feel of the handle? The heft of the thing? The balance? It takes a hammer entire to drive a nail. The head alone or the handle alone won’t help you. In some methodologies (maybe all), it’s the interplay among multiple practices that adds value.
If I could change one thing about the way my team practices software development it would be that they stop looking for a methodology or a favorite set of practices that will bring them success every time without the need for critical thinking on their part.
- 24 January 2009 at 10:23 am
Bill Miller (author) said:
Dave,
I appreciate your taking the time to write a thoughtful and lengthy reply.
This may be a good time for me to explain the purpose for my poll and questionnaire: curiosity really. Since I write critically about the Agile practices, I’m curious to know the background and experiences of my readers. Further if they are practicing Agile, I have a genuine interest to know if their experiences with Agile are good, and if not, are their bad experiences similar to my critique.
There’s much I agree with in your response, and there is some things I disagree with.
I agree that the process alone will not determine success. Success is as much a function of the quality of people/team as it is a function of the methodology. Methodologies do contribute to success, and finally can contribute to failure.
The best example that I can give of your point is that of a professional football team. The game of football is a essentially a process. For the last place team, can you blame the process for their failure or was it the performance and quality of the players on the team that is responsible for success or failure?
In football, no one ever doubts the process because the process is the same for everyone; success and failure is always about performance, but in software we too often misplace blame on the process when what’s really at fault is the performance and quality of the team members and poor management decisions.
Here again is where software differs from football. The play calling is often blamed for the poor outcome of a game, but rarely does poor management decisions get the blame in software.
On the other hand, there are better and worse ways of doing things. And this is where the tool analogy for software process breaks down. Though your analogy of the hammer is similar to ones that I’ve made, it’s only valid to a point. The process is about how you use the hammer, not the hammer itself. There are better ways and worse ways of using a hammer and depending on which you use, your outcome will be different.
Improvements in manufacturing processes have undoubtedly contributed to better quality products, cost savings, time savings, and more reliable products in so many consumer products. So yes, there are better and worse ways to build software and depending on the methodology that you use, success or failure can be attributed to the process.
Yet, there are better tools that improve the quality of the work, and they make it such that less skilled individuals can have results comparable to more skilled craftsmen using less capable tools, so yes even the tools can contribute to success or failure.
I believe that for human intensive work like software, process is a manifestation of teamwork, and I don’t blame your team members for trying to improve their teamwork. The quality of teamwork either makes work a chore and frustrating or completely enjoyable. I find that dysfunctional teams are normally a consequence of managers who don’t have a good appreciation for process and that process is largely about teamwork.
Finally, I believe Agile is a misnomer as it implies to me that the process is solely and largely responsible for being quick and responsive. While process can contribute to agility, agility is best achieved by design and architecture decisions. If you want to be quicker and more agile, find ways to write less code, build architectures that are easily extensible, and build/use tools that enhance your productivity. Oh and make certain you build high quality software; nothing slows a development down more than building a release on top of low quality software.
- 24 January 2009 at 1:31 pm
Dave Nicolette said:
Bill,
You make excellent points about process, methodology, teamwork, and quality of management. I think we’re pretty much in agreement, except that my experiences in using agile methods have largely been positive, while yours apparently have not. Sorry to hear that. If you need help from a pragmatist who’s not a dogmatist, you know where to find me. Point taken about the hammer analogy, by the way.
The way we use the hammer is, of course, a matter of human factors. So I can’t say we’re on the same page about crediting or blaming the process itself – even if we define “process” to mean the way we use methodologies and other tools. It’s all about people. The first statement in the Agile Manifesto says so, but the authors of that document didn’t make it up; outcomes have always been the result of people and how they worked together to make things happen. When people have had a robust process to help them, they’ve had a better chance of success; but even then I wouldn’t credit the process as such with that success. I’d credit the people. When outcomes aren’t what we had hoped for, it’s tempting to blame something other than ourselves; better still if we can blame something that isn’t a person at all. A methodology won’t get its feelings hurt. The problem is that if that’s the way we respond to failure, we’ll never learn anything. What good is a nice, juicy failure if we don’t learn from it? Unfortunately, a lot of organizations are structured to punish failure rather than to use failures as a means to organizational learning and process improvement. Naturally, people sweep failures under the rug or redefine them as qualified successes.
I even agree that “agile” is a misnomer. Unfortunately, nobody asked me my opinion before choosing that particular word to describe the approach they were codifying. You’re not the first person to take the plain English meaning of the word and run all over the place with it, mistaking its broad and varied possible meanings for the narrow intent of those who applied it to software development. OTOH, I’m not sure they could have come up with a word that would have satisfied everyone, or that would have been intuitively understood by everyone. They were trying to package a set of concepts that had come from a variety of sources under a single heading with some sort of catchy name. The same sort of thing happened years earlier when a group of methodologists got together to learn what their approaches had in common and to craft a single methodology that included the best aspects of general industry experience in software development; they called theirs the Unified Process. The gathering at the Snowbird ski lodge in 2001 was just the same sort of event. Those guys were developers with an interest in improving the state of the art of the profession; they weren’t and still aren’t marketing types. Making up buzzwords isn’t their strong suit.
Even if it isn’t the perfect buzzword, the term “agile” has been useful as a sort of stake in the ground around which people with an interest in improving software development processes could gather and exchange ideas and experiences. A sort of rallying cry, you might say. To that extent, the agile movement has been very successful indeed.
Of course, it hasn’t changed mainstream software development processes significantly. In the best case, agile methods will become an additional tool in IT organizations’ toolkit, enabling them to address certain classes of problems more effectively than before. It isn’t there yet; despite all the discussion, pilot projects, user groups, conferences, books, websites and everything else, agile development hasn’t achieved much market penetration to date.
Interestingly, there is less and less agreement in the agile community about details as we learn about and embrace more and more ideas, tools, and methods to deliver value while minimizing waste. No doubt the ever-widening variety of methods only adds to the confusion for those who are outside the fray and curious. I’ve also noticed that practitioners are spread out across the spectrum from early to more-evolved approaches to development, and most of them call what they do “agile.” That, too, must be confusing to the curious.
Critics are quite right to point out that many agile practitioners get caught up in practices and lose sight of principles. They are also quite right to call out consultants who have latched onto the agile bandwagon just because the buzzword is popular at the moment, and who misrepresent the ideas and stumble over the practices, sometimes causing losses to their clients. Neither of those issues changes the fundamentals, nor changes the fact that many of us are using the agile approach with great success on project after project. Agile development definitely has a place in enterprise IT.
There is one point you make with which I must respectfully, yet strongly, disagree. I don’t see advances in tools actually making mediocre developers just as effective as more-qualified ones. To the contrary, tools that make it easy to generate a lot of sloppy code quickly tend to result in a lot of sloppy code getting into production quickly. It’s not a new debate. Grace Hopper thought COBOL would make it feasible for people who were intelligent, but not trained computer scientists, to produce useful programs. It didn’t. Remember the era of 4GLs? They didn’t, either. CASE tools? Ditto. Today we use sophisticated IDEs with some very nice built-in code completion features, unit testing support, profilers, debuggers, automated refactoring support…the works. Mediocre developers use them to generate sloppy code quickly. We’ve got more sloppy code in production today than every before. When a tool is a tool, it’s a time saver for people who already know what they’re doing; when a tool is a crutch…well, you know.
Anyway, great site. Keep up the good work.
Cheers,
Dave
- 24 January 2009 at 9:10 pm

Leave a comment!

EMAIL

Subscribe

Visitors

Tag Cloud