Thanks for commenting. What I do agree to is that how far into the future you look is always dependent on circumstances, but at the same time, you can’t ignore the future entirely. To better understand where I’m coming from on that, you may want to visit this article that I wrote where I present my view on the trade offs between short term and long term more Reflection: Weighing The Future.

/Bill

What I would not compromise on are innovative projects that maintain your competitive edge. These are what will position you to lead.

When attending university, I recollect an English professor connecting the dots from the dominate attitudes, fears, values, and culture of the day to the arts, literature, science, and politics. She was able to connect them all with a common thread.

Nothing happens in a vaccuum, and since then, I’ve looked more broadly to understand the motivations in our daily lives. Everything is all connected when you look closely enough.

New attitudes, fears, values, and politics emerge in crisis, so we are likely to see new obsessions as we are forced to survive this crisis. Hopefully we shake that bad ones and focus on more valuable ones…Let’s hope.

What is an appropriate governance structure? Not sure :-), we need to talk more about this, for sure.

Thanks for commenting, and we do need to relook at the role of companies in society.

What we are seeing in this global economic crisis is that we all have a stake in these companies even if we aren’t the shareholders nor employees. Consequently, it means companies have a much larger responsibility than they’ve currently considered.

What does it mean to be a domestic company today when the world is a stakeholder? Can a multi-national with origins in let’s say the United States subordinate every other national interest to the USA when in many cases the company employs more people outside the US and a majority of its shareholders are outside the US?

In many ways these multi-nationals are “super” government entities that transcend political boundaries.

What kind of governance structure is appropriate in this brave new world?

We have to rethink what a company means, and the end goal to pursue has to be “to deliver a product/service of value to society” and everything else is a “side-effect” in fact, the whole concept of shareholders “owning” a company is a throwback to the industrial age, where a “company” was a bunch of machinery and tools operating by, replaceable, workers. This is no longer true, companies today are mostly in the employees heads, this is especially true in the case of the “knowledge industry”, so what does the shareholder own? people?

I think we need to look at companies as tools to achieve good outcomes ONE of which is shareholder value. Its probably time to come up with a form of corporation that takes into account the other stakeholders too, who have been ignored for too long.

Comments?

Maybe…after the comment by Tzvika, I thought about the chess analogy even more, and the interesting thing about chess is that it is dynamic, yet as the play progresses, except for maybe the elite chess players, the upfront analysis increases before moving.

I believe the chess analogy makes the case for upfront analysis even greater. In the middle of a game is when I’m finding I’m thinking and analyzing even more before moving. If I don’t, losing is a near certainty.

I agree with Bill that FreeCell offers a more relevant analogy than chess in the sense that once you know the patterns you can guarantee a win.

I’m noticing more and more IT organizations these days implementing both predictive and adaptive processes so that they will be well prepared to handle all classes of problems. I think that’s wise.

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

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.