Solving the delivery conundrum
Guest blogger Mark Welsh discusses how #banks can successfully scale application delivery and meet customer delivery requirements against the backdrop of increasingly complex in-house systems and a worldwide-shortage of software engineering talent.
The Banking landscape is being influenced by significant forces of change. New customer and industry demands mean financial services businesses must bring new features and technologies to market faster than ever. If they don’t, they risk falling further behind the competition, whether that’s rival companies that have transformed and broken free from legacy systems or new entrants with greenfield solutions.
It’s a big challenge. Particularly with a worldwide shortage of software engineering talent and in-house systems that are becoming increasingly complex, as new layers are added onto legacy solutions.
Given these constraints, how can financial institutions meet customer delivery requirements?
How to scale delivery?
#Solving the delivery #conundrum means addressing three areas: People, #Technology and Process.
People
The obvious way to scale delivery output is to increase team size and/or number of teams. But even ignoring the challenge of recruiting/retaining the right developers, you’ll quickly hit the ‘pizza boundary’: Jeff Bezos’s rule that a team should be no bigger than two pizzas can feed.
The number of communication points increases non-linearly with each additional team member, so expanding a team’s size beyond a certain point becomes counterproductive (extra communication complexity outweighs additional capabilities/capacity).
Figure 1: More people = more complexity
Source
Large teams also engender ‘social loafing’. Team members have more opportunities to hide, aren’t encouraged to drive development forward, and are generally less dedicated to team and product success. Sound familiar?
Next question: how should teams be aligned? Product features span multiple lines of business. The same holds for technology: any feature will likely require changes/new development across various architectural layers and technologies.
So, do you split your teams horizontally, matching stack layers and enabling team alignment around key technologies? Or align them around product features, enabling team ownership of a complete feature, but requiring either a sub-structure within the team to align with technology layers or full-stack developers (‘jacks of all trades, masters of none’) that deliver end-to-end?
It’s probably best to mix the two: recruit and train team members to develop across layers (not all layers, there will always be specialisms) and build on a more vertically aligned solution as the feature moves up the stack (with the bottom-most layers delivered as a platform—see ‘Technology’.)
Ultimately, smaller teams with ‘t-shirt shaped’ developers (depth in one or more technology areas/breadth across many) will be much more productive than larger teams with lots of specialists. With the right recruitment and training strategy, it’s possible to create highly productive small teams focusing on a mixture of technologies across product feature areas. That ensures end-to-end ownership within a single team.
Technology
Where possible, splitting the system across the right boundaries will enable independent delivery that supports output scaling. After all, while an end-to-end feature is only delivered once, its constituent parts are delivered separately. However, breaking the solution up can mean the product becomes inconsistent and fragmented for end-users. Having somebody manage the system as a whole is essential.
There’s also increased need for engineering and delivery platform support to ensure consistency and efficient use and creation of assets. These platforms should be managed through ‘Guilds’/communities of practice and, where appropriate, draw on examples like GitHub, npm and stackoverflow for inspiration.
Technical debt is another key factor—ignoring it creates a drain on developer capacity and motivation. Of course, it’s difficult to justify technical debt stories over feature development. But understanding the direct impact on delivery timescales, productivity and production risk will help drive conversations that ensure a balance is achieved.
A key aspect of approaches taken at Amazon, Facebook and Netflix is the automation of repetitive tasks, either by adopting an industry toolset or, where that doesn’t exist, developing it in-house. Giving developers the tools they need has a measurable delivery benefit and directly impacts developer motivation and retention. Typically, capacity investment of five to 15 percent is needed to maintain a good development architecture.
Process
Process and governance are key contributors to the time it takes to get from idea to live. In many banks and financial institutions, processes are put in place as a direct regulatory requirement and cannot be bypassed.
Other, non-regulatory, processes will have often been added or modified in response to delivery issues or production problems. Frequently knee-jerk reactions, they don’t fundamentally address root causes.
All these processes have an impact on motivation. Skilled developers do the right thing not because it’s written down and checked multiple times, but because it’s the right thing to do. But good processes remain crucial—to provide a safety net for new and bad developers (and for good developers having a bad day!)
Achieving ‘good’ processes means continually reviewing them against the risk they’re attempting to mitigate. They must be understood—and wherever possible, automated—to eliminate the variability that’s inevitable when people perform repetitive tasks and (for regulatory processes) to increase speed/quality of compliance.
Taking action
To successfully scale application delivery, we recommend focusing on:
- People: Understand developer productivity and where your key people are, use automation to enable them to focus on building stuff, get the right people in the right roles (t-shirt shaped) in small teams and give them tools to be productive, use Guilds to drive collaboration.
- Technology: Focus on development tooling as much as production coding and continually invest in it, componentize the platform to enable decoupled development and releases, actively manage technical debt, provide managed assets to support consistency/accelerated development.
- Process: Appropriate process and governance continually refreshed, automated where possible.
Each of these areas will balance/constrain/support the other two (e.g. good tooling can enable process automation, which improves developer motivation/productivity). Thanks for reading.
Mark Welsh, Technology Architect
The post Solving the delivery conundrum appeared first on Accenture Banking Blog.
Reply