Interestingly it is not the first time this has happened. After hearing several reports that Winstons Royce original paper on Managing the Development of Large Systems proposes a very different approach to software development then the way "Waterfall" is has been interpreted.
It turns out that Royce understood the importance of feedback and Emergent Design too:
STEP 3: DO IT TWICE
After documentation, the second most important criterion for success revolves around whether the product is totally original.If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operational areas are concerned
If you replace the word documentation with communication then there is nothing here that would look out of place in a modern paper on Emergent Design. It is a shame that people chose to cherry pick back then. Taking the bits that were convenient and leaving the bit that weren't.
Skimming through the paper, there are a few eye openers that show that nothing is new in Software Development, we just choose not to listem. This was one of the more surprising ones that jumped out at me.
2 comments:
Paul, I agree with your point, however here is an interesting aside. When I started off managing the project I am currently working on, it was obvious to me that a number of development practices needed to be worked on. So I introduced some practices that helped us to deliver software.
Due to some of the constraints on the project, it could never be agile, so I never set out to have the project become something it couldn't be - but at the same time I introduced a few practices that could be considered agile. No-one from an XP or SCRUM team would recognize our project as such, and neither would I expect them to, but if you look at it from this standpoint is it wrong to introduce practices such as refactoring, TDD, co-located teams and iterative development?
I guess that it all depends on what you claim to be. My team would never claim to be agile, but the funny thing is, some folks in the company would love to claim that our team is agile. Thats why I don't like the label - it can be quite subjective. Should it be - hell no - almost every book I have ever read on agility is very clear in non-technical terms what agility means, and I have seen bullet lists of items from these same authors stating that if you're doing these things, then you're agile. It can't get much easier, yet it still seems to be a problem.
No, I just want to drop the buzzword compliance and get on with the job at hand. It will still have a strong sense of meaning when like people congregate - but I fear that even the congregations will now be infiltrated by people who just don't get it and are intent on diluting the meaning of great practices. Your point on Winston Royce is a great testament to that!
Hi Andrew,
Yes buzzwords, buzwwords.. I think the problem here was that .people picked the practices that fit with their existing values. What I believe you are doing are introducing new values in a buzzword free way.
Effectively you are changing the organisational culture by stealth.
I believe what Winston Royce tried to do was change the organisational culture too. It is interesting that if you look through his paper, the practices that are consistent with a Taylorist belief system have been adopted and are now common practice, the ones that aren't have been silently ignored...
Post a Comment