Working for a consultancy that develops and configures apps and software means I have to balance often competing expectations – those of the customer regarding price and timeframe, those of my development team in terms of quality of build and milestones, and those of our management in terms of cost and duration of the project.
However, the important question is whose expectations matter the most? Clearly, it’s the customer’s expectations which take precedence over the others since they are purchasing the product/service and, as a result, keeps our lights on and our business growing.
Developing software solutions takes time, with one of the most challenging issues being that sometimes small features take up a disproportionately large amount of time and resource.
So how does one manage this situation?
We use the ‘Soft Point Development Doctrine’.
In modern military doctrine, there aren’t as many ‘lines’ or ‘walls’ as in the past. Warfare has become asymmetrical common conventional strategy is to maneuver around any static “Hard Point”. You encircle it and eventually, it capitulates. No-one likes being surrounded.
Developing systems for a customer should be approached the same way. Soft Point Development Doctrine provides multiple benefits for both the delivery team and the client, therefore adding to a more productive working model.
Step One. Develop a plan.
All well-constructed development projects are reliant on their initial ‘boilerplate’ being high quality. At Experience Digital, we rely on senior team members applying their expertise to any new build that can be utilised as a template for reference for any less experienced developers who may also work on the project. Senior team members then review all code accordingly to keep them on track using this model.
Step Two. Attack the soft parts of the line
In the sprints that follow (and I believe you should always use sprints) build the modules accordingly while considering the value of each feature in the module for the client. When has a client ever gone “wow” at a “sort” function or an API call to filter results. Probably not that many!
But another set of screens that are actually connected to the API – they’ll be astonished at what you got through!
Essentially think of this as reaffirming the Minimum Viable Product (MVP) at all times, which any client would be mad not to do.
If the customer doesn’t value the sort function that’s going to take you a couple of hours to complete – why would the end customer for your MVP?. More than likely, they won’t, and it’s something you can keep in your backlog to work on post-release!
Step Three. Take the initiative.
Once the sprint plan is set, sometimes it’s easy to just put your head down and keep working until all the cards are dealt with. But this isn’t optimal. What is, is that even as developers, asking the question, “What is the value to the client?” at the next showcase. If you are assigned a feature and you see that it’s something that’s going to take almost the entire sprint to complete – speak up, let the customer and your Project Manager (PM) know so everyone can reassess its value! It’s far better than getting halfway through it and having the client say, “oh you know what, if it’s that hard let’s skip it for the MVP”, leaving you frustrated that you didn’t finish that work and the client frustrated that they paid for it!
And that’s pretty much it. Hit easy targets. Whip them together for each showcase and return to them at the end of the front delivery when the client determines their value.
You’ll find that you as a PM and your customer will get things done faster and released quicker if you approach your builds this way.
