Tom on "Joel on Software" - BUFD Part 2: The Rest of the Story
It really pays to ask questions, to discuss ideas, to put yourself out-there. Learning starts to accelerate when you begin to articulate your thoughts and feel free to ask questions.
Case in point: in sharing this blog with Rob, a friend and colleague at work, he read my earlier posting on "Joel on Software" and he was able to answer a couple of the questions that I had posed to Joel. Of most interest, Rob was able to answer the question I have for Joel's project: Are your requirements stable? The answer was suprising (but if I had done a little more research I would have found the answer myself).
As it turns out, Joel is not only the architect for the system but he is also the customer! That means he is responsible for defining his own requirements. Well his requirements had better be stable then! Can you imagine how embarassing it would be for the customer and architect of the system to change requirements in the middle of development and have to do rework because of something he forgot or didn't consider?
So now that we understand the context of his argument a little better, let's ask Joel some more questions. If you had to work with a user/customer that was not able to articulate their requirements as well as he can, would you be able to do BUFD even if he wanted to? How many times have we as system developers worked with customers that, when we give them a demo of some working software, they essentially say "I don't know what I want but that is not it"?
Software requirements on most projects change, either because the user begins to understand the problem better as working software is delivered or the needs of the business changes during the project. At the heart of Agile is creating an environment where the project team can embrace change.
So I may agree with Joel that BUFD is appropriate for his project. I said I may agree - I still have a few more questions that I would ask of him. For example, what is the experience of his development team with the technology being used? Is there a need to do some exploritory / deep slice prototypes early in development that would give insight as to how the system architecture should evolve?
I am disappointed that Joel uses his project as support for his argument against Agile and for BUFD. His project is not representative of projects that should consider Agile. Let's focus the debate on this question: Would you prefer to use BUFD or Agile on a project where the requirements are likely to change late in the project?
Case in point: in sharing this blog with Rob, a friend and colleague at work, he read my earlier posting on "Joel on Software" and he was able to answer a couple of the questions that I had posed to Joel. Of most interest, Rob was able to answer the question I have for Joel's project: Are your requirements stable? The answer was suprising (but if I had done a little more research I would have found the answer myself).
As it turns out, Joel is not only the architect for the system but he is also the customer! That means he is responsible for defining his own requirements. Well his requirements had better be stable then! Can you imagine how embarassing it would be for the customer and architect of the system to change requirements in the middle of development and have to do rework because of something he forgot or didn't consider?
So now that we understand the context of his argument a little better, let's ask Joel some more questions. If you had to work with a user/customer that was not able to articulate their requirements as well as he can, would you be able to do BUFD even if he wanted to? How many times have we as system developers worked with customers that, when we give them a demo of some working software, they essentially say "I don't know what I want but that is not it"?
Software requirements on most projects change, either because the user begins to understand the problem better as working software is delivered or the needs of the business changes during the project. At the heart of Agile is creating an environment where the project team can embrace change.
So I may agree with Joel that BUFD is appropriate for his project. I said I may agree - I still have a few more questions that I would ask of him. For example, what is the experience of his development team with the technology being used? Is there a need to do some exploritory / deep slice prototypes early in development that would give insight as to how the system architecture should evolve?
I am disappointed that Joel uses his project as support for his argument against Agile and for BUFD. His project is not representative of projects that should consider Agile. Let's focus the debate on this question: Would you prefer to use BUFD or Agile on a project where the requirements are likely to change late in the project?
posted by Tom Looy, Tacit Knowledge PM at 10:43 PM
2 Comments:
If your requirements are being predicted to change prior to your projects completion, then there is a flaw in your development process. Neither Agile nor BFUD can solve for that properly.
Thanks so much for your post, pretty useful information.
Post a Comment
<< Home