The Spirit of Agile
If you are like me, you might have done some searches on the internet about this “agile” thing over the years. And you most likely came across terms like “stories”, “scrum masters” and “sprints” all over the place! Then, you might have had the thought that this seemed really complicated and ultimately was not something you had the time to figure out or the authority or expertise to implement in your company.
At least, that is the thought that I had.
Until something interesting happened: I accidentally started implementing the spirit of agile, and experienced some really amazing benefits.
Don’t let the particulars of agile methodology bog you down; the spirit of agile is smart.
At its core, agile is about feedback in multiple forms. It helps you get buy-in to start a project, ensures you get support from your end users, and gives you a framework to ensure you’re communicating on all cylinders! Here is what I consider applying the spirit of agile looks like for an admin:
- Demo Quickly. Your stakeholders and end users usually have no idea what you are really talking about when explaining the power of salesforce.com process automation. When you are trying to get traction on an initiative but find stakeholders are dragging their feet on giving the green light, the best tool you can use in this spot is to repeat to yourself “If you build it, they will come” over and over again (watch the movie, A Field of Dreams, to get inspired)! Then build something fast in your sandbox (or a free dev org); just enough to schedule a demo with your stakeholders and a handful of end users to show them an example of what you are talking about. Watch the light bulbs go off, and see how fast someone gives the green light to implement immediately!
TIP: Visit the Automation Champion website for inspiration on how to start automating process today!
- Get Feedback Regularly. When you get the green light and start building, be sure to keep doing demos as you go, letting end users perform unit testing regularly (let end users have a login to your sandbox and provide them with testing scripts of how the system should work for them). The idea here is to get feedback from end users as you build. When they give you feedback put it all on a spreadsheet, mark their name and a note of “future phase” or “current phase” (an example spreadsheet is below).
As you interact with end users, make it clear that some of their feedback will be looked at for implementation in a future phase and some of it will be implemented for the current release. Always set expectations so that people are not upset that their ideas are not being implemented. Explain that if you were to build all of the ideas that are given to you right now, then the project would never go live! Make the feedback list public, so that they can see that you are not going to forget about their ideas. Include a column for estimated work and put some hours in there if you want to show how much extra time each idea would add to the build
TIP: Here is an article introduction more information around iterative development, agile and scrum.
- Communicate More. Schedule a weekly 30-minute scrum with the full team. Make sure you set the pace that the meeting will be used to deliver timeline and milestone updates, and any major decisions that need to be made or roadblocks. Don’t let it get overrun with details of the “feedback” items, when those come up tell the person you will talk to them offline directly and will continue to document this feedback on the spreadsheet. Communication should be happening constantly on the spreadsheet (and a Chatter group can be setup for regular conversations!). The weekly scrums will ensure milestones and big decisions are being made, you should be able to keep things moving steadily when leveraging these meetings!
The major benefits that I found when I started applying the spirit of agile in my project work as an admin, included multiple layers around support and adoption. When bringing the team in for their feedback, the team felt a sense of ownership. Which cascaded to high adoption from these team members as well as the people they interact with, as they take the time to explain how to use the system within their small groups (vs. normal roll-out experiences where everyone would be “fighting the system”!).
Finally, I realized the constant feeling that nothing was ever actually getting done, completely went away when I started using this approach. It has held true over the years, that when everyone is involved and the work is transparent, the roadblocks come down because there is less fear of the unknown. Everyone knows exactly what is happening, and the project is top of mind (and everyone has a sense of ownership)! So it is harder for stakeholders and end users to drag their feet or put up barriers.