The list of "crimes" conducted by the development teams against databases and development in general by their "use" of Agile methods continues to get longer and longer. Lately I have had to deal with a number of such crimes and their consequences.
- One group went ahead with development against nothing more than a strawman design, that in turn was for only verbally stated requirements. No one could agree in a meeting I attended what the actual requirements were. The number of times someone said "I assumed he meant ..." was incredible.
- Another group designed and implemented their own tables, but now have no time to have their database design reviewed before the release deadline. It "must" be delivered as it is, because it is too late to change anything.
- Another group simply did not bother to document anything. When asked at how they arrived at their final solution and the analysis they went through, they could not explain or justify anything.
- All of the groups have used the phrase "we left that for another sprint" for some major, critical piece of functionality. They are simply ignoring anything that is too difficult.
- Iteration speed is more important than getting it right or meeting all the requirements. The fact that the speed of iteration is introducing more errors that need to be corrected by future sprints never gets flagged by anyone. I am sure the quality of what is being delivered is going down, but everyone else is happy that we now have some more buttons to click on the user facing screens and forms.
- Design and code reviews are simply ignored. The only measurement seems to be the volume of exposed and visible functionality delivered. Whether it works or not is never really considered. By that time the developers have moved onto the next sprint, and the next piece of functionality to be delivered. The push is for additional functionality added to the application software at all costs.
- Many application level requirements are simply ignored in early development sprints, just to deliver some usable functionality as early as possible. The fact that the initial design and development cannot be extended in the future to meet the ignored requirements is itself simply ignored.
I now term Agile the "ignore it today, it will be someone else's problem tomorrow" development methodology. I really do think that many of the developer's believe in a world of magic fairies or pixies that will sprinkle magic Agile dust everywhere in the middle of the whole development, and all of their ignored issues will just disappear and go away. Unfortunately, everyone else is living and dealing with the real world. Have you ever tried living in a house built and delivered one room at a time, all with separately laid foundations, and installed plumbing, electrics, windows and doors? It is a mess, and it gets worse over time as more and more rooms are added on, because there was never an overall design, and no one ever bothered to think about future requirements until they had to deliver them.
7 comments:
I agree with you 100%. Agile is supposed to 'control development in today's chaotic environments', but in my opinion Agile methodologies and the stupidity of rushing to get things done without taking time to do it right is what CREATES the chaos!
If your only experiences with steak are gristly, undercooked cuts, you might conclude that all steak is inherently terrible. It's like that with Agile too.
Good Agile process laid over crap concepts just produces crap more efficiently. But in your case it sounds more like good Agile principles misinterpreted became bad Agile.
Sorry, looks like you got the short end of it. It's not always like this. Agile done right can be a wonderful thing for both stakeholders and developers.
Me too, I am in 100% agreement. Actually you have perfectly expressed all of my frustrations with "Agile" better than I could have myself. My guess is that teams where "Agile" works would be teams where any methodology works and it may be that it works better than something else for those guys, but I've never seen it work so I can't say.
The real problem with Agile is that where it doesn't work (most place I guess, although they wouldn't admit it) is that because it emphasises minimal planning and documentation (at least that is my interpretation) it gives managers the authority to not plan or document anything at all. To start with this is OK because up until this point, after some fashion the code has been planned so hacking in a lot of small changes is "surprisingly easy" and the higher levels of management who wouldn't know a null pointer from a for loop are very happy and declare "Agile" a huge success and commit fully to the project. Developers can see that the code is getting worse and worse, but they are reassured that this is OK because they will get to tidy it up in some later sprint - after all in "Agile" you compromise on features, never quality, or so the wisdom goes. (I'd like to meet a manager who was still employed after spending a whole release cycle focusing on quality, but...)
The actual focus is on "getting features out quickly" and the reality of this means that a few years down the road the code base is in such a state that even simple features take forever and a day to implement (I was recently on an agile project where adding a rich text box to a form took about 5 weeks and at one stage we had a key-logger as part of the implementation to intercept the, wait for it, the enter key!).
By this stage the business has got used to the idea that "Agile" gives them the features that the want "fast" and they are committed to it. The phrase "technical debt" has also started to be used with alarming frequency, but all that debt, the managers assure everyone, is of course from those nasty old "pre-Agile" days where they planned everything.
It also looks "good" to investors, because it is fashionable.
I'm sure that in the beginning Agile was a great idea that worked well for the people who pioneered it because there was no mantra associated with it; it was just a set of best practices that worked for them. But, I think now it is time to recognise that outside of small, "Rock Star" teams it is not only a total failure, but actually very dangerous.
Agile is good for front-end design, but not for back-end design.
It is good for the front-end, as users rarely say what they want. Even if they say what they want, it isn't what they mean. Even if it is what they mean it isn't well thought out. Even if it is well thought out, when they see it they want it changed. The list goes on and on, and Agile addresses this very well.
The back-end implements a data model. A data model is a consistent whole that answers the problem the requirements create. It is an idea that works in totality, but cannot be implemented as disparate parts, hence, Agile cannot be used.
The idea of "One Program, One Process", was created by a team that had no respect for their counterpart. In reality, each team needs to work with the others without compromising their own methods.
Agile is good for front-end design, but not for back-end design.
'It also looks "good" to investors, because it is fashionable.'
This is probably the #1 driving force for going Agile. I have personally seen well tuned development shops (that were iterative, but not technically agile) be forced to use SCRUM because "It's the industry standard". One in particular went from producing nearly bug free, monthly releases to producing quarterly releases that had little additional functionality and were just riddled with bugs. They've been using SCRUM now for just under 2 years, and they are looking to abandone it, but upper level management won't hear of it. In other cases, I've seen the development team pretend to management that they are using SCRUM but they use other, more effective methodologies.
I ran across this hilarious video that pretty much says it all:
http://www.youtube.com/watch?v=nvks70PD0Rs
John
The bottom line is that good programmers (and good teams) know what to do and don't need this Agile crap. I like iterative programming, but it can be done naturally. I know when I need to meet with my team, share information, gather requirements, go off and code on my own, create a prototype, do a demo, etc. I have successfully created software applications in a timely manner without it.
I had a similar experience and am about to have it again, ho hum!
I blogged/ranted about it back then too....
Agile development - Anything but!
regards
Rich
Post a Comment