Agile @ Neev

Contributed by Vinci Rufus on 21 Apr 2013

• 
• Tweet
• Get in Touch

Being a person who had a rather distaste for processes would be strange to have been writing about Agile processes here at Neev. Agreed Agile is just another way of managing your projects but here are a few things that added big value in the way projects were being delivered :

Just enough requirements:
Requirements are just sufficient to enable the development and testing to able to be done with reasonable efficiency. You don’t really waste too much time on what on requirements that don’t actually add up to the end product.

Each requirement contributes to a story on your story board. Each story is discussed and can be broken down into small task deliveries. This ensures all the requirements are well understood and can be achieved in about 8 hours of work. Using Scrum here progress is tracked objectively and on a daily basis.

Small, Incremental Releases:
The best way to build a house as someone said is brick by brick. Agile works on similar lines - analyze, develop, test each feature one feature at a time. Advantages of this would be
Reduced Risk: tells you what is completed throughout the project.
Better cost management: you can prioritize and get features done
Flexibility: to plan features that go into the next iteration

Empowering the team:
The responsibility of delivering the project lies with the project team. It is essential to empower them to have to be able to take decisions and take complete ownership of the project.

Agile ensures teams must do everything together, right from requirements to prioritization to estimation and finally delivery.

This would not only bring a buy in from the entire team but a commitment and a sense of being part of the bigger picture.

The ‘User’ Team member
In most other Project Delivery models the end user is involved only at the end of a milestone. This means that the user would only get to see the product being built at long and far intervals.

Agile on the other believes the user is part of the team. Who ensures high level requirements are communicated clearly, the tasks are prioritized appropriately, requirements can be clarified daily, the usability of the product and most importantly the correct product gets delivered.

Thus the ‘user’ team member ensures both business and technology converge.

100% or nothing
All tasks within a Sprint would need to be 100% complete by the end of the Sprint. Hence there is no separate development complete or waiting for QA scenarios here. For a task to be  100% complete it would need to be developed, tested and accepted by the product owners.

A task that is 100% complete should be ready for shipping!

80/20
In all projects the effort distribution is 80% of your tasks get done in 20% the effort and 20% of your tasks get done in 80% of effort. This ensures that you are able to complete 80% of the tasks that required to take the system live and not wait for the remaining 20% of the tasks to get complete.
Defect Driven Testing no more
Agile ensures that each task needs to be tested before making it complete. Having the developers write test case driven code would ensure that we stick to the more efficient Test Case Driven Development rather than the Defect approach.

Contributed by Govind Dalwani

Visit us at Neevtech.com to know more about our offerings.

Tags: Agile Development, Agile@Neev, Project Management, Project Timeline