TerraT posted an interesting comment on this blog post.
I thoght I’d repost it here since it is illustrative of the slippery slope a project can get on when doing a “by the book” agile adoption and what the ramifications can be.
Emphasis added below is mine. This shows how things can go from agile to fragile all to quickly without overall higher level planning.
Reading this has made my day. I had got to the point of feeling isolated out of development completely purely down to the fact that even mentioning the short comings of Agile (as it has been applied) labels me as an unprofessional lunatic. Truefully Scrum and other “Agile” pseudo project management methodologies have the same problem that waterfall had; unrealistic expectations. Waterfall fell down due to an unrealistic expectation that scope wouldn’t slip and that design on paper would translate into good working software. Agile/Scrum fell down due to the unrealistic expectation that you didn’t need a global technical design, that businesses could afford the weight of testing and release (automated or not) and that business stakeholders would actually want to be continually involved.
Agile has become the monster that Waterfall could only have dreamed of. As a consultant I get a peek into many dev teams and overall productivity has evaporated and the focus seems to be fulfilling the requirements of the process rather than on producing the best possible software. What is worse the whole process has become so ingrained that developers can’t even see how mired in it they have become. Consider the following thought process that is remarkably common :
Agile is a must right? Hmm, we can’t manually test all this every 4 weeks. So you will need 100% unit testing coverage of course. Ah then we’ll need DI/IOC/Mocking on pretty much every class. Ok with that much decoupling our automated integration testing will need to be 100% too. Hmm, all that is hard to retrofit so we’ll have to use TDD. Ah, that doesn’t cover UI so lets dust off selenium and watin etc. Oh wait I have lots of JScript and Ajax calls and these JS testing and mocking frameworks are still not completely reliable. Ooops I have purely visual defects on dynamic content pages how am I going to deal with that? Hmm, the business stakeholder is telling me my automated testing isn’t a strong enough guarentee for the business as bugs are still hitting production; we’ll have to manually test it as well. Dang, my code is an abomination to DRY principles and the consistency is awful I am going to need a deep refactoring. Double dang, my tests all broke as they only covered refactoring where the interfaces stayed the same and not normalisations across classes and modules. Phew, finally got my tests all working but we had to descope half the stories from this sprint to give us the time. The product backlog seems to be getting longer and longer we might need some more devs, I hope they have TDD experience. Oh, why is everything taking so long, this is supposed to be Agile right? What do you mean we might need a rewrite as the productivity framework we picked had limitations we couldn’t have anticipated as those stories hadn’t been added to the backlog at the time? Ok, it was a no to a rewrite but I managed to hack around the framework, I hope no one sees this code, I’m so ashamed of myself. Why are people talking about version 2? The product life span can’t be over we haven’t even finished version 1 yet? (ok maybe a little dramatic at the end but I was enjoying myself lol)
Each subsequent layer of process seemed reasonable as we added it but when you put it all together it is laughable. I couldn’t prove it but I really believe only 10-20% of the man hours invested are actually being utilised on the production code. Worse still with so much preoccupation on the process the software seems to have become a secondary consideration and despite a legion of green ticks it seems to be suffering. I think what should be learnt from this experience is that we need to stop growing our techs and approaches in academia and R&D as it never seems to appreciate the realism of working in businesses where the technical team is considered a subsidary support department (regardless of how lost they would be without us). Development needs to be reactive to circumstances and not nailed to processes that are so brittle they shatter at the slightest pressure.
What are your thoughts?