Most of the Salesforce implementations are following Agile methodology, especially using the most powerful framework ‘Scrum’. There are many misconceptions about how Scrum works, what the roles involved and the ceremonies followed. Join this interactive session to unveil how Organizations are being Agile!
What is Agile?
Agile was born from a collaboration of 17 thought leaders in software development who met in 2001 to seek alternatives to the documentation-driven, heavyweight software development processes that were common at the time.
What is Salesforce Agile Methodology?
Agile methodologies propose is an incremental and iterative approach to software design. In Agile, product is developed in small incremental builds. These builds are also called as sprints. Sprint cross functional teams works on various areas like planning, requirements analysis, design, coding and testing. At the end of each Sprint a demo product is made available to the customer or stake holder for sign-off.
Why Agile – Why not Waterfall?
Because Agile enables the following activities, which Waterfall doesn’t:
- Highly incremental – short, value-driven intervals
- Regular re-planning, status-checking, reviewing, learning
- Continuously striving for improvement in delivering customer value
- Regular customer interaction/communication
- Accommodating change
- Team members make tactical decisions and self-organize
- Test- and Behavior-driven development
- etc…
Salesforce Agile implementation Video
Topics:
– Agile vs Waterfall
– Introduction to Scrum
– Scrum Roles
– Scrum Ceremonies
– Q&A
Please subscribe our YouTube channel to get notification for video upload.
Salesforce User Stories in Action
Check our out next session Salesforce User Stories in Action. This interactive session to understand how to write Salesforce specific user stories, how to prioritize user stories, and learn some guidelines around story estimation.
Further Learning
Check our below module to learn more about Agile Implementation.
Summary
Scrum provides us with an effective way of preventing changing requirements from affecting a DT’s performance – i.e. the Sprint timebox.
