I remember being told during the early 80's by every adult who asked me what I wanted to do as a career that I should get into computers because everybody would have one one day and would need experts to make them do stuff. Clearly those predictions came true, and it appears that I wasn't the only kid to heed the advice of his wiser elders at the time - actually I told everyone that I wanted to do something else so that I could look rebellious when I would decide to change to do all that "geek stuff" later on! The thing is, while there are a lot of software developers out there, not all of them appear to be able to claim to be very good at what they do, even after 10's of years of experience. Yes, that was yet another bold statement for me to make, but I have a good reason for believing this, and I might even have an explanation or two for why this is.
Now I hope you're not thinking that I'm going to try to paint software developers in a bad light, and I certainly wouldn't say that I am any better than the rest of them (yes, I'm putting both ego and modesty aside in an attempt to write a good article!). There are some very brilliant individuals out there, many of whom make me feel as if I've never learned a thing over the years, simply because they truly are the visionary geniuses of the digital age. There is however quite a lot of misunderstanding out there, which is perhaps why we have so many project failures and poorly applied processes. Sure, you can blame your company and your boss when a project fails because "they wouldn't listen", but that's really an excuse to hide an inability to achieve great results in spite of the adversities sent your way. I'm sorry, but the buck really does need to stop with you if your project fails, no matter who's fault you want it to be. These misunderstandings that I am talking about prove to be quite costly, not only to the projects you might work on, but to your own professional development as a software developer. In some ways perhaps, I believe that all of us, even some of the more brilliant of us, have been at the business end of this sort of situation at least once before in our programming lives, simply because we had a misconception that had not been cleared up.
Software development is at once both very straight-forward and very complex, and there are many aspects to the subject that are often misunderstood, however I've decided to focus on one particular subject area today, and that is the concept of Agile development.
While many of the development practices that are considered to be "Agile" may have been around for quite a number of years, the Agile concept as a philosophy was defined at a meeting between 17 well-respected software professionals in February 2001. While these individuals did not meet to specifically represent all software developers, the manifesto they created has had a great influence on the way in which software development is practiced today. In 2005 another meeting of software professionals (with a subset from the manifesto group) defined an adjunct to compliment the Agile Manifesto with a statement now known as the Declaration of Interdependence, which while perhaps lesser known than the manifesto have come to be held as commonly accepted practice in agile development teams, and in particular forms a framework around which many modern software development methodologies are defined. Together, I call these two statements the "Agile Philosophy", and when combined they read as follows:
Many of the people who contributed to the definition of these statements have written a large number of books between them, and in these books, there are many practices that they write about which are used to highlight certain aspects of the Agile Philosophy. Most of the authors define the concepts well in terms of applicability within a given paradigm to agile philosophy, however I have yet to see someone state categorically that "you are doing Agile if you do something in this specific manner". And it is right that they should not because the philosophy is a guiding framework, an axiom if you will which defines the rules to apply, without telling you what specifically to do so that you can do things your own way in order to apply the rules. Sad to say, that it's at this point that I feel people start to make up their own minds about what they think being agile means, and where a very large number of people are getting it wrong, because they've missed the meaning in the message.
Now for those of you with a classical religious up-bringing, this will probably all start sounding a little familiar. You get a set of simple 'commandments', and give them to a bunch of people who you hope will get what it all means, and then you watch them all try and interpret things any which way with all sorts of clever boundary cases, so that they can feel justified bending the rules to suit themselves. In the case of the Agile Manifesto, the message is that being Agile is all about communication. "Interaction", "Change", and "Collaboration" are the key terms of the manifesto. And yet, the most important part of the manifesto is that it goes out of the way to state clearly that there IS value in planning, documentation, contracts, process and tools, but that there are other things that are valued even more. The problem is that many people read the lines and interpret them very strangely. For example, I have heard or witnessed all of the following:
I would like to think of myself as a true follower of the Agile Philosophy. As a software developer, I live and breath the axiom that the philosophy defines, and I won't consider any team or individual to have the right to claim Agility if their thinking leads them to believe that doing software development any particular way is being specifically Agile. If the team is able to allow for and manage change in all areas of the development process from how requirements are gathered, to how the project is scoped and iterated, to the testing and implementation processes, and even to the choices of tools that are used to manage and do all of this, then perhaps the team may have the audacity to claim to be Agile. The moment you allow any pattern of fixed thinking to enter into the equation, the very second you feel the need to defend one particular tool or methodology in favour of another simply because it's what you always do or what you prefer, in other words, the moment the collective "I" becomes more valued than the collective "We", then I believe it is fair to say that you have lost your Agility and your right to claim yourself as such.
With all of this stated, Agile itself is not a religion. It is not meant to take sides, nor is it meant to be used to represent any particular side in a debate. Sadly, human beings seem to have a predilection for wanting to belong to one religion or another, even if the religion is simply non-belief. I find it a shame though that the loudest and most 'agility-religious-seeming' developers among us are also the people most likely to have misunderstood the philosophy. These are the people who will provide you with lots of pseudo-stats and misquote the Pareto Principle seemingly with authority, and will tell you that one set of tools and practices is effectively more agile than the other. These are the poor lost souls who could offer the Agile movement so much with their passion, yet probably do the most damage because of their dearth of understanding combined with their willingness to perpetuate the myths and false statements that they think represents the philosophy of Agility.
I guess that the thing that surprises me the most about the misconceptions about Agile, is how it has become the latest and greatest industry buzz-word, particularly in recruiting circles. Nearly every job advert on one of the more popular job search engines either promises or requires Agile experience, yet when it comes to chatting about it at interviews, you quickly learn that not all 'Agiles' are created equally. I would love to see the day come when I can talk about Agile Philosophy with someone without feeling a need to justify my apparently 'extreme' and 'orthodox' position. Until then however, I will continue to represent a voice of reason and see if a rational statement or two can stem the tide of misunderstanding, and encourage a more balanced view of the Agile Philosophy and about software development in general among those that have never truly understood it, even though they may have been writing software themselves for many years.
Software development is at once both very straight-forward and very complex, and there are many aspects to the subject that are often misunderstood, however I've decided to focus on one particular subject area today, and that is the concept of Agile development.
While many of the development practices that are considered to be "Agile" may have been around for quite a number of years, the Agile concept as a philosophy was defined at a meeting between 17 well-respected software professionals in February 2001. While these individuals did not meet to specifically represent all software developers, the manifesto they created has had a great influence on the way in which software development is practiced today. In 2005 another meeting of software professionals (with a subset from the manifesto group) defined an adjunct to compliment the Agile Manifesto with a statement now known as the Declaration of Interdependence, which while perhaps lesser known than the manifesto have come to be held as commonly accepted practice in agile development teams, and in particular forms a framework around which many modern software development methodologies are defined. Together, I call these two statements the "Agile Philosophy", and when combined they read as follows:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
We …Together, the Manifesto and Declaration of Interdependence define a philosophy that is meant to empower all of the people involved in a software development project. While the manifesto defines the values of the philosophy, the DOI provides an fairly broad definition of criteria by which the philosophy may be applied in a practical sense. The two statements compliment each other quite nicely, and even more importantly, they do not attempt to go so far as to limit your options by telling you what you must do, but rather provide guidance in terms of how to approach the software development process.
- increase return on investment by — making continuous flow of value our focus.
- deliver reliable results by — engaging customers in frequent interactions and shared ownership.
- expect uncertainty and manage for it through — iterations, anticipation and adaptation.
- unleash creativity and innovation by — recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
- boost performance through — group accountability for results and shared responsibility for team effectiveness.
- improve effectiveness and reliability through — situationally specific strategies, processes and practices.
Many of the people who contributed to the definition of these statements have written a large number of books between them, and in these books, there are many practices that they write about which are used to highlight certain aspects of the Agile Philosophy. Most of the authors define the concepts well in terms of applicability within a given paradigm to agile philosophy, however I have yet to see someone state categorically that "you are doing Agile if you do something in this specific manner". And it is right that they should not because the philosophy is a guiding framework, an axiom if you will which defines the rules to apply, without telling you what specifically to do so that you can do things your own way in order to apply the rules. Sad to say, that it's at this point that I feel people start to make up their own minds about what they think being agile means, and where a very large number of people are getting it wrong, because they've missed the meaning in the message.
Now for those of you with a classical religious up-bringing, this will probably all start sounding a little familiar. You get a set of simple 'commandments', and give them to a bunch of people who you hope will get what it all means, and then you watch them all try and interpret things any which way with all sorts of clever boundary cases, so that they can feel justified bending the rules to suit themselves. In the case of the Agile Manifesto, the message is that being Agile is all about communication. "Interaction", "Change", and "Collaboration" are the key terms of the manifesto. And yet, the most important part of the manifesto is that it goes out of the way to state clearly that there IS value in planning, documentation, contracts, process and tools, but that there are other things that are valued even more. The problem is that many people read the lines and interpret them very strangely. For example, I have heard or witnessed all of the following:
- Arguments about whether TDD or BDD is better, or whether to do either at all in order to be Agile
- Arguments about which mocking framework is better in terms of Agility
- Arguments about the amount of documentation to produce while remaining Agile
- Statements that it is Agile if you produce no documentation
- Statements that it is Agile if you pair programming, or if you use version control and continuous integration
- Statements that you don't need to design anything, because the entire system design will simply emerge through TDD, and that TDD is Agile
Held up against the actual wording of the manifesto, you soon realize how absurd some perceptions of Agile are, and that the sad irony is that the manifesto has failed to communicate it's own message about communication to the people who probably need to understand it the most.
I remember working for a company where I created an API that was highly modular. It was extensible, and could be modified easily, but it probably only had about 40-50% test coverage. This API was used one day by a colleague to express to another person that we were a company that practiced Agility, because we used a certain set of tools, we wrote tests so that we didn't need to plan heavily up front, and we could easily modify the API as a result. This individual scoffed when I said to him that we weren't an Agile company at all. What this person had failed to realize is that the tools don't make us Agile developers, and that the API was only as easy to modify because I had designed it to be that way, with up front processes I might add, and to be modular and extensible within a clearly defined specification that I had determined based on requirements I had gathered before this individual started working for the company.
This colleague had also not realized that all of the subsequent Agility he was experiencing was because I had implemented processes which were designed to be flexible in order to accommodate the changing needs of the company, while the planning and specifications could afford to be loosely applied because the process was so highly iterative that each change appeared to be a mini-project all by itself, even though the actual project itself had been running for over a year. He could not have missed the point of it all any more drastically, and yet he was offended when I pointed out that we weren't really Agile in the strictest sense because "individuals and interactions" were often forgotten, as the project ownership was strictly in the hands of a single individual who wouldn't allow others to play in his domain without directing change and project management in what was strictly a classic waterfall model in a manner that was not subject to change, and that given this project owner was also effectively the "customer", our ability to collaborate in any meaningful sense was non-evident.
I would like to think of myself as a true follower of the Agile Philosophy. As a software developer, I live and breath the axiom that the philosophy defines, and I won't consider any team or individual to have the right to claim Agility if their thinking leads them to believe that doing software development any particular way is being specifically Agile. If the team is able to allow for and manage change in all areas of the development process from how requirements are gathered, to how the project is scoped and iterated, to the testing and implementation processes, and even to the choices of tools that are used to manage and do all of this, then perhaps the team may have the audacity to claim to be Agile. The moment you allow any pattern of fixed thinking to enter into the equation, the very second you feel the need to defend one particular tool or methodology in favour of another simply because it's what you always do or what you prefer, in other words, the moment the collective "I" becomes more valued than the collective "We", then I believe it is fair to say that you have lost your Agility and your right to claim yourself as such.
With all of this stated, Agile itself is not a religion. It is not meant to take sides, nor is it meant to be used to represent any particular side in a debate. Sadly, human beings seem to have a predilection for wanting to belong to one religion or another, even if the religion is simply non-belief. I find it a shame though that the loudest and most 'agility-religious-seeming' developers among us are also the people most likely to have misunderstood the philosophy. These are the people who will provide you with lots of pseudo-stats and misquote the Pareto Principle seemingly with authority, and will tell you that one set of tools and practices is effectively more agile than the other. These are the poor lost souls who could offer the Agile movement so much with their passion, yet probably do the most damage because of their dearth of understanding combined with their willingness to perpetuate the myths and false statements that they think represents the philosophy of Agility.
I guess that the thing that surprises me the most about the misconceptions about Agile, is how it has become the latest and greatest industry buzz-word, particularly in recruiting circles. Nearly every job advert on one of the more popular job search engines either promises or requires Agile experience, yet when it comes to chatting about it at interviews, you quickly learn that not all 'Agiles' are created equally. I would love to see the day come when I can talk about Agile Philosophy with someone without feeling a need to justify my apparently 'extreme' and 'orthodox' position. Until then however, I will continue to represent a voice of reason and see if a rational statement or two can stem the tide of misunderstanding, and encourage a more balanced view of the Agile Philosophy and about software development in general among those that have never truly understood it, even though they may have been writing software themselves for many years.
No comments:
Post a Comment