The engine room of a salesforce implementation is the team of developers who work feverishly to build a solution that a series of users have described in a few user stories.
In nearly every project in my experience there are moments where the timelines are beginning to stretch and senior leadership are starting to get nervous about go-live dates, budgets and deadlines. Often the reaction is to ask the team to work longer hours and weekends. Occasionally where there is a big gap a whole new group of people are added to the existing team to try and increase the output (velocity) and meet an arbitrary deadline. In my experience both of these reactions are counter-productive and often result in more bugs, lower quality and an even later project. For me the root cause of this seems to be most people don't understand how technology is built or the skills required and therefore don't understand how to maximize developer productivity.
The closest analogy I can use to describe the work of a developer is writing poems about humans to a machine. You are trying to describe a solution to a problem using a strange set of semi-english terms that have different rules depending on the programming language. The very best developers describe a solution to a problem in a wonderfully abstract, short and clear couple of lines with lots of notes to help explain it to the next developer. The solution will reflect a wider understanding of the problem, capturing the essence of what the user is trying to achieve and anticipating change in the future. The inexperienced developer will write reems of complicated unstructured jumble which no-one else can understand but are some how proud of the number of lines of code they have written (this is a terrible metric for productivity).
A solution that is delivered as a series of wonderful 'poems' (classes) that seem to work even as things evolve are the height of the profession (think of all those old banking systems...). But it seems that most people don't understand this side of the job, they see it as a technical, maths orientated, process driven thing where output can be maximized by longer hours or adding more people to a 'developer factory'. The reality is as we push longer and longer hours the ability to think creatively and in abstract rapidly declines. Exhausted people never create masterful pieces of Technology. Equally it is naive to expect new developers with no context or background to contribute meaninfully as soon as they join.
The best code, much like a poetry, is delivered in bursts of inspiration that occur whist someone is in the 'flow'. For a developer the flow is an amazing experience where the existing technology components and the new components are all connected in their head. It becomes crystal clear exactly how to build and integrate the new with the old and deliver the user needs. It can take anywhere between 20-60 minutes of thinking about the problem before all the pieces of the puzzle are constructed in your head and if at some point you get distracted you need to start from the beginning again. This is why many developers sit staring at their monitors with headphones on deperately avoiding meetings - they are seeking that flow space.
Interestingly I believe the surge in popularity of Slack is down to the developer flow phenomenon. Instant messaging seems to allow you to stay in the flow where as speaking to the project manager (is it fixed yet?!) completely destroys it. I think this is your brain re-setting when you switch context or focus. The other context switch that robs productivity is having to step out of the flow after building something to go through a series of manual release processes. Slack has tapped into this need with a series of bots that enable automation of different processes which allows people to both collaborate, release their work and stay in the flow.
In technology, we aren't digging holes. We aren't a factory where the job is so simple that each person with a developer title is of equal skill, ability and so interchangeable, onshore, nearshore or offshore. Development is still an abstract and creative discipline where the best get incredible leverage and probably needs to be viewed more in that light. As Steve Jobs said impact of a single, experienced, inspired developer leveraging technology today is 100x that of an 'average' developer. That means if I can build an 'A' team of 3 they will produce more than 300 'B' or 'C' developers. The best cost more, but not 100x more in technology (at this time). So the question that really needs to be ask isn't 'Do we have enough development capacity in our factory' but 'Do we have a critical mass of top talent'.
Some tips for when you find yourself looking down the barrel of a late project :
- Ask your team if there are things you can do to increase productivity (less status meetings?!)
- Descope & Prioritize & Focus - get back to the core of the core of what you are trying to deliver and focus the team on that. 80% of requested features are never used anyway... look at excel.
- Clarify user stories, make sure they are visual, make sure they are super easy to understand and the business will accept them if it is built as described.
- Focus on first time success, how can you reduce the defects coming from work done, reducing rework frees up talent
- Enable real time testing, if you can pass / fail with reasons the work being done it is fresh in the developers head. Stale bugs take a lot longer to fix
- Ask your team what additional resource they would value, what skills, what problem domains - 'another developer' isn't very helpful as it requires on-boarding, training, explaining the current solution etc
- Be smart about how you ramp new resources, try not to distract your best, focused people up-skilling others thus decimating your velocity