13

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?

|improve this question
5

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.

|improve this answer
  • Great answer Adam. In some ways this isn't that different from the question of how to incorporate UX design with a scrum process. In that case, the general best practice is to run design scrums that lead the developer scrums by a week or two, so the shippable product from the design sprint is what's used for the dev sprint planning. Both teams also plan overhead hours for clarification meetings. Does reduce the flexibility (it's a bigger ship to steer) and requires a product owner who can stage things correctly, but I've seen it work well once the whole team understands the rhythm. – Eric Wu Sep 7 '12 at 17:13
  • Sounds similar Eric, thanks for the comment. I like the concept of a "shippable" product being the starting point for dev sprints. I've also seen the practice of having more general "hardening sprints" up front for similar reasons, especially at the start of a long road map. – Adam Sep 9 '12 at 0:13
6

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.

|improve this answer
1

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.

|improve this answer
  • I def. suggest people try that out and if you are maintaining your own org probably worth the investment. I tried it out a couple of times but bugs with SF itself made it difficult. SF kept thinking that we were modifying files that we weren't. The IDE had a bug in it where we couldn't select individual custom fields. It was difficult to only push the changes we made to git instead it wanted the * metadata selections. Many other issues. I'd be willing to try it out again, but clients don't want to pay for a month of working through SF bugs before starting in on their actual project. ;) – Peter Knolle Sep 6 '12 at 20:45
  • That's interesting -- in our experience, once the ClassName.cls-meta.xml file was created, it never changed. On Windows, I use the Git Extensions GUI which allows for easy selection of what is and is not included in a commit, from files down to individual lines. – tomlogic Sep 6 '12 at 20:51
0

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.

|improve this answer
0

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.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.