Sunday, March 26, 2006

Agile / Traditional approach- Why not hybrid?

Let’s discuss what are your options if there are some constraints which are preventing you from using agile methodology or simply if your customer does not want to use Agile methodology.
Well, why not use hybrid of Agile and Water fall approach.
Tie your deliverables as required by your customers to water fall steps. Let’s look at the following steps
Requirements Gathering

Go ahead and create requirements and design document and submit it to your customer for sign off.
Take your coding and testing steps and see if you can use some of part of Agile methodology in these steps. Try doing following in 2-4 week iterations:
Create stories from your requirements document
Assign points to your stories
Prioritize your stories
Develop and unit test your stories
Perform automated acceptance tests and deploy

Deploying every 2 week gives your Business Analysts a chance to validate and verify your software. Any resulting issues can be fixed early and will be less expensive to fix. Deploying every 2-week gives your team a short goal which your team can try to achieve and once the team’s goal is achieved, the team will get a sense of achievement and hence this will boost team’s moral. The team will get confident each time an iteration is successful. Not only that, by deploying every 2 week you can measure the development velocity of your team and hence will have more insight in to when the whole software can be delivered. You can take necessary steps if you feel that by this development velocity delivery of the software will be delayed.
Another thing which I want to highlight here is that Agile is less document oriented. No big requirements document, no big design documents, just enough documentation which you feel is necessary. For example, some times we create very detailed design documents explaining how the screens will look, which database tables will be used, what will be the pseudo code , what will be the sql query etc.
Instead of going in so much detail why not a screen design and few words about its functionality. In fact I would prefer to draw the screens with my hand and update the screen when the developer has developed it. Believe me you would save a lot of time and probably be able to code your screen in the time you will be writing your detailed design document. Another reason not to write design documents in so much detail is that no one can be 100% sure about the sql, the database tables and code logic and no one can guarantee that these won’t change. We must welcome change and if we don’t we will fall in our own trap where in the end we will realize that we are running out of time and then these very detailed design documents are left untouched and now suddenly your code and the supportive documents are not in sync. Otherwise also if we know the things will change then why write it. Let coding take its own course, let the development happen with bare minimum documents and in the end produce your documents from your code / software and not the other way around.
All of you who have looked in to RUP and if ever tried to produce those documents will probably realize the pain of doing so much documentation. Sometimes we forget our main goal. Our main goal is to produce working software and not lot of unnecessary documentation just to comply with a methodology. If just by writing few words can convey a software function then please do not write hundreds of lines just to convey the same function in detail. I have seen low level design documents with various sections inside those (For example, Screen Design, Description, Constraints , Database tables, Sql queries, interacting units.) Lets make it simple a screen design ( hand crafted) and just enough detail about its functionality.
Another thing if your customer is not requiring you to submit these low level documents then why make these so much great.

My suggestion lets make our life simple by making things simple, by reducing variables, by not over engineering anything , by being open minded and by welcoming the change. Let’s not make a methodology our religion (be it RUP or Agile or any other) and then keep believe in it for the rest of our life.

Agile or Some other Methodology. Are we still thinking?

We are still debating in most projects whether to use Agile or use traditional approach.
I find at least two reasons as to why its difficult in moving from traditional water fall / other approaches to Agile (1) our customers are unaware of how agile can help them build something they actually want.
(2) Some of us have made traditional software development approach as our software development religion. We feel threatened by the fact that what ever we have learned in our schools and during our past experiences of developing software applications using traditional approach is suddenly not the right approach.
In traditional approach the design won’t start till the requirements is finished. Coding won’t start till design is finished and the testing won’t start till you are done coding. The reason which was given was that you must gather all and correct requirements before you design because if a requirement is wrong then everything from design to test is essentially a waste. I guess in doing that we missed one major thing and that is human factor. First of all we should stop the over use of the word “Requirement”, and try to find out what are the preferences of our customers. Preferences change more frequently than requirements. (An ideal software solution would be one where there are no requirements but only preferences.)
Let me ask you this, if you plan to build a custom home for your self, can you write each and every detail of your house in a piece of paper, give it to builder and then come back when the house is completely build. Do you think that whatever you were imagining while writing your so called requirements is exactly what you got? You might be getting something close to what you were thinking but not exactly what you want and sometimes it could be totally different then what you have thought. That’s where the difference lies; there is a difference between what you think you want and what you actually want.
Now instead of building the whole house and then showing it to you, if the builder shows you every week or so what he has build so far and what he will be building in next week and each time asks you if you are satisfied? Now let’s say you are not satisfied with what ever was built last week or so and you want the builder to redo or change something. If the change is simple builder would probably do it for free. But lets say doing that change would cost some extra $ . Now you will have three choices (1) Not to do the change (2) Pay extra $ (3) Trade in some other feature of your house. (E.g. may be not to build the deck and instead do the change which is more important to you). The outcome would be totally different if the builder used this approach. At least there won’t be any surprises when the builder finally delivers you the house. Similarly if there are no surprises when the software is put to production then you have a satisfied customer and hence a successful project.
Water fall or other approaches works fine if there is no change in the requirements. No change means you were able to document exactly whatever your customer was thinking (not saying) when you were documenting the requirement. Another issue is that sometimes we don’t know exactly what we want until we see it. Take the example of buying a car. How do you decide that you need a particular car? Well, simply put, you will actually look at a car and if you like it, you will go ahead verify other specifications and buy it. You requirement is that you need a car but which particular car buy is your preference.

We all have seen that most of the time when software is delivered it does not meet our customer’s needs and preferences and then we start blaming our poor requirements gathering, wrong software design and may be bad technology selection. But I guess the blame goes to the fact that we were not ready to accept that fact that requirements could be poorly documented. Human beings to some extent are afraid of change, simply because changes are unpredictable and so we do not welcome changes easily. I guess time has come to solve this software problem and instead of resisting change why not welcome it.
Traditional approach resists change but Agile welcomes change. Agile software development methodology eliminates element of surprise by releasing software in short iteration (2-4 weeks). In each iteration you plan, design, code, test and then release your software. Every 2 week your customers get a chance to look at your software. With each iteration, they will have more insight in to what they will be getting in the end. They are welcome to change their preferences and even after 2-week, if what ever you have developed, is a waste then let it be. It’s far better and more productive than keep working on developing software for a year and then realize that more than 50% of the software is waste. At least we all know that changes done in early stages of software development are less costly compared to changes done in later stages of software development.
In the end I would say that I am not sure whether Agile will work for real-time and satellite/rocket software’s where whole system must be designed and tested before it can be put to use but I assure this approach works for rest of the application software.