What is a good way to incorporate an agile process like SCRUM for projects on the Force.com platform?

Question

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:

1. It is extremely easy to prototype screens and/or mock out some limited functionality.
2. You don't have to worry about servers/infrastructure too much or at all.
3. 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:

1. 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.

2. Continuous Integration is hard. This can be mitigated by setting up a Job to run the unit tests periodically or just doing it manually.

3. 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?

Answer 1

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.

Answer 2

So at Bracket Labs we faced a lot of those technical challenges, and we are still facing the 4th one as well.

Those configuration settings just don't lend themselves well to being automated.

I've done some work setting up Selenium to setup and teardown orgs. However, it's far from the experience of working with a traditional web-application server, which really slows down continuous development.

Perhaps having someone on the team whose job it is to manually setup the org configurations and use automated deployment to build into those orgs on a regular basis so that your developers/qa people can test the eventually of having to check for non-trivial use cases against your code.

That's the way we have to do it for sharing models with TaskRay which we started supporting with our custom UI that has to inherit these rules.

Answer 3

Regarding issue number 3 (shared repo and developer sandboxes). Have you tried using the Force.com IDE and using Git to manage the codebase, and allowing each developer to have their own sandbox?

In this case, it should be possible to work on separate branches and merge in the work of others, as long as your pushing those changes up to your sandbox. You need to make sure the project contains all of the assets, and not just the default of classes and Visualforce pages.

It's still messy to go this route, because some of the changes you push from the IDE up to your sandbox don't "take". For example, if you're switching to a branch that doesn't include a field on some custom object, we've found that pushing the .object file up to the org isn't enough to remove the field, and you need to do it from the web interface.

As for refactoring, you might need to try doing it entirely in the IDE, updating the objects, objectTranslations, layouts, classes, and pages all in one shot, and then pushing the project up to a fresh org.

Answer 4

If you have Java or .Net developers then you can ask them to write some utility with the help of Partner and Metadata WSDL to compare your organization. So while configuring other org the chances of error due to manual customization will be reduced.

Answer 5

I think the answer to 4 is that 'Agile' doesn't really mean just diving in headfirst. You really need to have a good idea of what the overall aim is, and choose an appropriate db structure, role/sharing/profile model to start with. That doesn't mean that you have to or will get it right first time, but time spent thinking about the overall structure up front will pay dividends later on.

Experience helps too I think.