Tuesday, September 14, 2010

Agile methodologies - good or bad?


This is another of my pet topics - agile methodologies. You may wonder, why am I cribbing about this now - this is not new any more. But the fact is that many organizations are getting into Agile, still. See, it is a tectonic shift from, well, water-fall. So, people are not sure if it applies to them, if so in what way. May be they are scared of 'new', may be they are worried about learning new tricks, or may be they just do not see the point!

I do not exactly belong to that last category, but I am pretty close. Here, I want to explain how I differ.

Let me be clear up front, I am no fan of big, fat water-fall. I think that it is clearly old school. We need a more nimble, smarter way of developing things ('things', not just SW). But let us just limit ourselves to SW for this argument, because it is the prevalent example. Clearly, if we are taking 2-3 years to come out with a system, then we are definitely going to be out-of-date by the time we roll things out. So, what is the alternative? How can we become smarter? Well, in my view, the Agile camp has taken this to the other extreme - they say, prepare a shippable product in 2-3 weeks. You didn't see, but my jaw dropped, and my mind went blank. But that is their message - once and for all. Do you agree? Isn't there something drastic about this? I think so.

Consider that you have to come up with a average sized system - consisting of various applications, systems, databases, web servers, application servers, languages, protocols, so on, and a bunch of NFRs(non-functional requirements). Let us say this is a airline reservation system. Now consider the business back-log - let us say that the top item (how it got there is a different story) goes something like this - 'the user must be able to make a reservation'. Now, the team picks this item, uses its understanding of that sentence to come up with tasks and - voila - they can indeed deliver it (in a 4 week sprint, let us say). No biggie here - one UI screen for selecting the flight, another for paying by credit card - and the system to do the actual reservation. After 4 weeks, the sytem is delivered - the product manager goes bonkers, he is pulling his hair - he says who told you to do it that way - and the team says - eh, what are you talking about - there is no such thing as you telling us 'how' to do it, we just do it, remember - there are no analysis docs or design docs - we just do it. Oh, BTW, you Mr. product owner - you should know Agile (or Scrum) better - the only artifact (contract) in these methodologies is the sticky - that small thing on which you wrote the 'user story' - and if you are looking for anything more you do not know 'Agile' - you are an ignorante (better yet, you are old-school)!

So, no documentation (my favorite) - do not 'waste' time by writing those tomes - BRDs, FRDs, TRDs, Analysis docs, Architecture docs, Design docs, anything - no docs, period. Start coding.

Where do these guys come from, seriously? BTW, you should read this  'Good Agile, Bad Agile' - dated, but still relevant. It is so eloquently written, it is a great read.

Frankly speaking, as I said earlier, I do not agree with the tomes concept, either. But 'nothing' is no answer either. A reasonable sized project will have at least 50 people - that is about 10 scrum teams. Imagine each one marching to their own beat (you can say, oh well, we have Scrum of Scrums - and my answer is 'without tools (read documentation), scrum of scrums is not viable - we cannot expect humans to be so smart that they can find discrepancies between teams just like that'). The problem is not just between cross teams, problems exist within a single team as well. First of all, if I am doing analysis, architecture and design for 'miniscule' components every sprint - that is one big inefficient process. I would say, take a sizeable chunk of deliverables (not just from one sprint), and do the analysis, architecture and (high-level) design in one shot.

What I am suggesting is that we should have mini-waterfall for some key aspects of a system - like the major use cases, high-level architecture, and may be high-level design. To be more clear - the idea is to start at the abstract for each of these, and then keep drilling down at appropriate points of time. For example, let us say that your system needs, ultimately, and taking a simple case, features for message queing, web services, and security. You do not have to architect all things in one shot - but, the key thing I would like to say is that - at the time you start working on the web services interface - take some time and architect for all your web services needs, not just for the first interface. Similarly, at the time you start working on the first security requirement, take your time to architect for all the security requirements. This, BTW, applies to all other aspects of SDLC - requirements gathering, analysis, and so on. Have requirements gathering - but just not like we used to do - for a year. Let us identify a part of the system (or whatever granularity), and work on that. The idea is to take maximum advantage of the type of resources required for each task - get together for 2 weeks (or 4 weeks), in stead of 6 months for requirements gathering or analysis. The end result is that you still produce guiding artifacts (which are very important for me), just not as bulky. That is a great advantage - you have the artifacts, but you are also delievering must quicker. Once we recognize that all this work is important and needs to get done, we can make it part of the cycle (rather than just discounting it and 'assuming' that they will 'somehow' get done, as Scrum does). Heck, I feel like I should start promoting these ideas - may be I will write them up (oh wait, do I have to find a catchy name first? 'mini waterfall' may not cut it).

There are many other problems with Scrum, and I can keep going on. For example, Scrum is totally vague on when they can get things done (precisely because they do not do upfront analysis or architecture or design). If I were a product owner, I will scoff at it. I do not want such a team - see, at some point, I want to draw a line. Enough - I want some predictability - I want to be able to demand certain professionalism. I hope all product owners will stand up and say 'enough'! Heck, I hope everyone will stand up and say 'enough'!

No comments:

Post a Comment