On some of the Force.com projects that I’ve worked on it has been more challenging to use an agile process than some of the other traditional web app (e.g., Java/Spring) projects on which I’ve worked.
Some of the things that I’ve really liked about Salesforce and agile are as follows:
- It is extremely easy to prototype screens and/or mock out some limited functionality.
- You don’t have to worry about servers/infrastructure too much or at all.
- It is easy to give access to stakeholders early on, although this has to be done in conjunction with setting appropriate expectations.
Some of the issues that I’ve had are as follows:
Hard to refactor. Other programming languages/platforms have more robust refactoring capabilities and/or tools that make it easier to constantly refactor. In Salesforce just removing a field from an Object can be time consuming if it is used anywhere else and also if the removal needs to be pushed to another sandbox.
Continuous Integration is hard. This can be mitigated by setting up a Job to run the unit tests periodically or just doing it manually.
Depending on the project or client org, it can be difficult for each developer to develop in separate sandboxes while keeping a central repo. Having a single shared developer sandbox makes it hard to do things like refactor/experiment/branch.
—All of the above 3 are technical issues that I can workaround, the 4th issue below is the one that I have found most challenging—-
There are a lot of requirements to gather with respect to role hierarchy, sharing settings, and the object model where it has seemed difficult to do this piece meal with the goal being production-ready code at the end of 2-3 week sprints.
So, what is a good way to incorporate an agile process like SCRUM for projects on the Force.com platform?
I second what jordan recommends about having a dedicated team member to focus on configurations. Actually, although it feels less Agile, I read the following book that makes a strong case for having a separate individual or team that focuses on “paving the road” for development, as a supporting function: Adapting Configuration Management for Agile Teams
Similar to configuration management, with salesforce org configuration the notion of Agile iterations sometimes seems inappropriate when a more front-loaded effort is required to save on expensive refactoring down the road. Another possibility is to dedicate one or more configuration sprints ahead of the development effort, adjusting the team along the way. But this has the disadvantage of resetting your velocity measurement (burn down) where sprint planning with story point estimates gets unclear (or the per-sprint story point capacity of the team).
So I would consider having a dedicated configuration team member or perhaps even a separate team (or person), even if the cadence differs from the development team. Then use a Scrum of Scrums approach to coordinate between configuration and development.
It’s a concept that Agile purists tend to frown on, but for example, when was the last time you formed a Scrum team to wire-up a new office location so your development teams could work there? Sometimes a little “gantt” up front helps smooth the iterations down the road, though this is not to be confused with the dreaded scrummerfall, which incorporates waterfall-like practices and binds them to each iteration.