Now I get to return to the theme of this blog series, “Deploy in Four.” What do I mean by this? Four days, four weeks, four months.
Days: meetings twice a week allow you to share something new and show progress roughly every four days. This stokes the fire and fosters enthusiasm and momentum.
Weeks: have a goal of deploying a new set of features in the sandbox at least once a month. Provide new things for the staff to test.
Months: Promote a fully functional portion or phase of the application every four months with the expectation it will be put into use immediately.
I am writing this post in late May. We began in January. Uh, well, it’s been over four months, and we have not yet delivered the first phase. Of course, there are reasons for this. No excuses, other than reality. Would I do things differently if I could start over? Sure. Would I have reached my goal? Probably not.
Availability
Working for a consulting firm, I took on this project above my regular 40 billable hours per week. While I allotted approximately 5-7 hours per week of my time, my regular work has kept me unusually busy and I managed to squeeze out at most 2-3 hours per week. Regardless, I have been diligent in meeting twice a week, and without that, we would not have made this much progress.
The same holds true for the Fishline staff. I gave them a lot of homework to do, and it turns out that questions led to more questions which led to the re-thinking of entire processes – exactly what I expected.
Exponential Growth
Everything starts slowly. I am getting to know the business, they are learning how to assess the organization, make decisions, determine what is critical and write solid specifications. We are learning how to work as a team and improving our communication. This alone takes at least six weeks. But then things start to move faster, and faster still.
While we did not achieve deployment in four months, we actually have achieved our four day and four week goals after the first six-week period. What’s the secret?
Divide and Conquer
Within the first six weeks you are in the “you don’t know what you don’t know” stage. There is no getting around it. What seems very simple is not, and what is portrayed as being very complex may be simple. There are many obstacles at this point, including “this is always the way we have done things”, differing perceptions of workflows, “pie in the sky” expectations, and fears about making changes.
The first thing I looked for is a clear division – something we could all agree on. We chose to concentrate on the primary reason a food bank exists which is to reapportion food. This is a simple in and out process: food enters the building through a set number of channels and exits the building in the hands of someone in need.
Both ends of this process involve software. We discussed each one in detail, trying to determine which was the least complex. It became evident that the inflow was independent of other processes whereas the outflow represented only a portion of the client service process.
Agile versus Waterfall
For non-technical types, you might want to check this out before reading on. It used to be that coding and configuration was so costly in time and resources that all the planning had to be done in advance. This is the waterfall approach. The reality is that no matter how much planning is done you simply cannot predict if it will work until it is put into use, particularly with a volunteer staff.
Salesforce makes it so easy to put together a proof of concept that there is no reason, particularly at the beginning, to be shy about just jumping in after a couple of weeks of high level discussions. Some of you purists may take issue with this, but let’s remember our client – this is a small organization with limited resources and is embarking on this journey with nothing more than faith in you. Spending precious time creating a business requirements document and getting sign-off is not the right approach.