At Zen4orce we have followed two widely used methodologies for project planning and delivery, namely the traditional waterfall and the agile delivery model.

For a recent project for a client in the financial domain we used agile methodology for implementing and customizing Salesforce. We went the agile way because we wanted to incorporate the dynamic requirements seamlessly at whatever stage of development the project was in.We also wanted to keep the key stake holders well informed and give them good insights at every stage of project development.

By doing this we diligently followed the Ajile Moto of “Customer satisfaction by early and continuous delivery of valuable software”. Having a matured team in Salesforce also helped us to build the project around motivated individuals and achieve our goal.

 Why Go Agile for the new project?

The traditional waterfall methodology would have proved to be a challenge for this project mainly because

• The requirements were dynamic.
• The client wanted a ROI at the earliest even with minimalist features.
• Client wanted a transparency and frequent inspection in the development cycle so that ever evolving changes they had can be catered to easily.
• Customer wanted to be hand holded with the system from Day One.
• Customer wanted to manage risks through increased visibilityand incremental releases.
• Customer also wanted to ship their product faster through regular releases.

Agile helped us to address all of the above issues and we delivered the project successfully to the delight of the customer.

So how did we achieve this?

Project Kick off – Product Back Log

“Welcome changing requirements, even in late development”

The project started off with numerous workshop sessions with the product team and stakeholders where the requirement was gathered and broken down into small user stories or Epics. This was a stage where our product backlog was base lined. Post base lining the product back log could accommodate new requirements at any stage of the development.

Sprint and Release planning

“Working software is delivered frequently (weeks rather than months)

The product back log was consumed to create a release plan to give a high level timeline for the release of the working software. Features at broad level were added to the release.

Sprint planning sessions helped us to define the sprint goal and define the requirement or user stories which can be completed in those sprints.Each story was then broken down into tasks and effort estimation, resource allocation was done for each task. Breaking the release in sprints ensured that we planned only as much as what we needed and what is achievable.

Daily Scrum meetings helped us to keep the team on track and remove any hurdles to achieve the sprints goal.

Sprint Demos

“Close, daily cooperation between business people and developers”

Sprint review meetings proved to be very useful in identifying implementation problems at an early stage. At the end of the Sprint the development team demonstrated the working software to the client which helped the client gain insight of the projects progress. All concerns and changes that the client wished to make were then incorporated at the end of the sprint.

Sprint Retrospective

“Regularly, the team reflects on how to become more effective, and adjusts accordingly”

The sprint retrospective meetings were diligently held at the end of every sprint where we discussed what went wrong in the sprint implementation and how we could avoid the same mistakes in the next sprint – it helped us to inspect and adapt. The goal of the sprint retrospective was to continuously improve our processes to deliver better.

There always has been a trade-off between choosing waterfall and Ajile methodologies when we manage our projects, But Adapting Ajile techniques for implementing projects has definitely helped us to maintain a motivated team ,a Motivated team is a key to Deliver Better and Keep your client Happy !