techVELOCITY Day

My company[southtech limited] decided to do a techVELOCITY day on every month. I think this is a nice attempt. The target is to arrange a seminar where people can present any technology that may have enough potentiality to use and get benefited.




I thought why not speak about agile method and try to make understand everybody some of the excellent features of agile development.I don't know whether i am success or not in that matter but I had good response and people were asking questions about how we can adopt that and in what sort of projects.




My main target was to describe the benefits of visual modeling and just enough documentation. Documentation is a good thing but people have to compare the benefits of documentation with the cost of its maintenance and effectiveness.
I also mentioned a comparison between agile and waterfall.I think adopting the complete lifecycle of agile development has few problems at this moment specially in the environment where I work. Some of them are Team empowerment,Customer involvement because if we fail to prove our customer the benefit of close involvement they will not give their timer so closely.
Any way, the techVELOCITY day was excellent and we enjoyed a lot.

Let's do it agile

“study of 6,700 projects, it was found that four out of the five key factors contributing to project failure were associated with and aggravated by the waterfall model, including inability to deal with changing requirements, and problems with late integration.”

Source: http://www.versionone.com/Resources/AgileBenefits.asp

The main problem of traditional development method is once one stage of the traditional/waterfall method has been completed, going back is impossible. If you go back it is costly and inefficient.

But on the other hand if you follow agile method, change is welcome. At the end of each stage/iteration you will have a working software. And the size of the iteration is 2/4 weeks.

The most interesting thing is agile says customer is a part of development. So where customer is a part of development, you can't have so many requirements gap and after all customer is getting a working software in every 2/4 weeks. so if there is any gap it is not going to cost you that much.

Agile says document but do not get lost in piles of paper.Agile includes some excellent practices and those are

-Active customer participation
-Respond to change
-Time boxing
-Iterative and Incremental delivery
-Use case driven
-Prioritizing requirements
-Team work
-Team must be empowered to take decision
-Pair programming
-Just enough documentation
-Testing is integrated throughout the life cycle
-JAD session/daily meeting/Communication
-Refactoring
-Feature driven
-Visual modeling- A picture is worth a thousand words

In traditional development for a mid size project the requirement specification takes few months and the boss loses patience and bullies all concerns to sign off the specification. Then the developers go away with the confident that they have the signed off requirements so no one gonna blame them for any problem. They design for few months and coding starts after several months.

When the customer gets the software, already it has been almost a year. When they start using it, they find their business changed a lot.
But in the case of time boxed delivery it would never been happened.

"another study of over 400 waterfall projects reported that only 10% of the developed code was actually deployed, and of that, only 20% was actually used."

Source: http://www.versionone.com/Resources/AgileBenefits.asp

Finally I am totally agree with cockburn and like to say "Waterfall is an acceptable way of failing"

Let's talk about agile method

Agile method is a framework concept, generally centered on iterative and incremental delivery of working software. It is iterative because we are repeating, or iterating, a complete lifecycle of development over a short, fixed span of time. With each of these iterations, we ship some working subset, or increment, of features.

Several agile methods exist. Some of the more well known include extreme programming (XP), lean software development, Crystal, DSDM (Dynamic Systems Development Method), Scrum, and feature-driven development (FDD). What they generally have in common is the IID aspect, but more importantly they hold similar values and principles. I've listed a few things that each method emphasizes:


Lean - Move closer to customer, shorter cycles, eliminate waste, decide as late as possible, empower the team, build in integrity
DSDM(my favourite) - Empower the team to make decisions, emphasize frequent product delivery, integrate testing throughout, promote collaboration and cooperation between all stakeholders
FDD - Center development around the feature, create a domain model with domain experts
Crystal - Emphasize people, gather techniques from other methods, improve communications, adapt the process itself (shrink or grow to fit)
Scrum - Manage a prioritized list of requires on a product backlog, collaborate through daily standup meetings, exhibit the product upon iteration completion, use retrospectives to correct the process
XP - Emphasize the values of communication, simplicity, feedback, and courage; use specific technical and collaborative practices, including TDD, refactoring, pair programming, continuous integration, open workspace, and automated acceptance tests

Original post by Jeff Langr