Feb 22 2008
First Learning on Agile
Last week I stumble upon a good podcast on Agile Methodologies by V. Subramaniam. I discovered some facts and apprehended few thoughts from it.
Facts about Software Projects:
- Only 7% features developed as part of software product are used by end user. It may give bitter feelings to developers, but it is fact. How many features of MS Word or Excel we are using while working with it on daily basis?
- Approximately 10% of software projects are successful where success is measured in terms of project being delivered on time, in budget and with reasonable functionality.
How should we tackle it?
If you build what customer wants, you will fail. You need to build what customer will need in future. Think about a scenario where you have recently finished your requirement gathering phase and planning for a huge project delivery due after a year. Through out the year, your team is busy in developing features that customer has cited. After a year when you go back to customer with your product, you would be shocked when customer comments that he may not be interested in couple of features now, aligning their requirements to current market needs. At times, it would be bit frustrating too, if you have become passionate about a feature that you developed skillfully, but it would never see daylight?!
So the question comes, how to gauge what customer may like to see in future releases? The idea is very simple - talk to your customer frequently. You can shorten the time between requirement gathering and customer feedback. Try to collect feedback by showing demo of the application [and not a prototype application].
How Agile Methodology helps?
“Agile Manifesto” says -
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Here, the implementation of first phrase does not happen at the sacrifice of the later one. For example, “Working software over comprehensive documentation” does not mean that we 100% overlook the documentation. But it does mean that we don’t want to follow it as strictly as we are doing as part of RUP.
We should implement “Pair Programming” [where one writes code, other thinks about test cases and logic] to promote interactions between developers. I had been working in similar environment some 6-8 moths back. Although at that time, I was not aware about pair programming. But thinking about it now, make me realize that it was quite effective and we developed very stable and scalable framework on which our software product is banking on!
As the last point in manifesto suggest, if we want to respond to change effectively, we should be checking ground reality often, a kind of adaptive planning. It would be a better idea to migrate the development process to an environment where continuous integration, testing & refactoring can be facilitate easily.
“Scrum” is the integral part of “Agile” way of software development. Scrum meetings are, usually, short [approx 10-15 mins], round table, stand up meetings. Participants should be discussing on,
- What did I work on yesterday or last couple of days [if we are not having scrum meetings everyday]?
- What am I going to work on tomorrow of next couple of days?
- What is holding me back?
As it is apparent from the agenda, it would facilitate knowledge sharing. At times, it would help developer sought a faster solution to a problem, by taking a help of his peer who had solved similar problem in past or who carries good experience in that problem domain.
It has another two important concepts – “Sprint” and “Backlog”. Sprint cycles are typical development cycles that spans around 30 days. “Backlog” helps in measuring amount of efforts that needed to finish application in terms of time.
Flip side
Software development using agile methodology may succeed well, if team is competent enough.
Scrum meetings are meant to be short lived. If people start dragging on their status updates, it would result in lost of efforts. Ideally, we should start on time and scrum master should keep a tap on time. Moreover, member’s attitude matters a lot.
Usually, we tend to forget the importance of retrospection. It is highly important that we have some time spend in retrospection between two spring cycles.
Some punch lines…
- Do not let your customer decide all three - Quality, Scope and Time. If he decides them, you are left with only one option – Failure.
- A fool with a tool is a dangerous fool!
- It’s not the tool, it’s the individual [craftsman] who makes the difference.
