Johannesburg, 25 Sep 2019
Software delivery is an arena that is frequently studied and analysed because of the pace at which technology is advancing. With fast-paced technology updates comes delivery challenges (particularly legacy delivery). Managing delivery is an art form in itself because those who adapt and innovate often find ways to improve the experience – from UAT to production releases, the name of the game is smooth, predictable delivery with as few hiccups as possible.
As a real life example, Singular Systems started delivering software systems in 2002 with a small team of very client-focused individuals. Small teams and fewer clients meant we could focus on personal relationships, rapid turnaround time and general support post go-live. Back then there weren’t as many proven delivery methodologies, but adjustments were made to ensure we were always refining our delivery model.
How were projects delivered in the past?
Singular had a strong focus on projects and set up delivery around each separate client. Each project had a project owner/manager who was usually a senior person. Project management meetings were held each week to discuss project statuses and to assist with any development or delivery issues. Where applicable, capacity would be drawn on across the organisation, but in an ad hoc/agile manner.
Why did this work for both clients and those delivering the software?
As a smaller company, we were very agile-focused – without necessarily noticing it. We were able to pick up any work across the organisation and teams communicated and delivered frequently as there were not as many staff. This worked well as we could act fast and attend to any client in a moment’s notice.
This dynamic delivery structure meant junior staff were thrown in the deep end, which facilitated a steep learning curve and broad knowledge base for the whole team.
What were the pitfalls with this methodology?
Singular’s mindset has always been to improve. So as we grew, we needed to keep checking in with ourselves.
Developers and analysts were spread thin, which was starting to result in a lack of end-to-end capability, especially in the middle management layer. This in turn created some key man dependencies on the senior management as they became the client’s ‘go-to man’.
If the key man was tending to emergencies or in a busy period with another client, the risk was neglecting their other clients.
Why is it good to reassess how to deliver projects?
With growth comes new challenges. New clients and additional projects meant juggling more balls. Growth brought an opportunity to streamline projects using different delivery methodologies, which are geared to more structure, predictability and defined roles.
Key man dependency is always one of the biggest risks at a company with a track record of longstanding clients. We identified that, in order to achieve success and longevity, we would need to transfer skills from senior to middle to junior resources, while keeping a very close eye on our relationships.
More layers of delivery would give us better continuity and project predictability. Our clients’ expectations are managed via a transparent and standardised delivery focused team, not individuals. A predictable framework meant we could be more proactive, objective and goal-driven with our clients and less reactive.
What has changed?
Singular chose a hybrid approach to delivery – each team uses high-level milestones to engage with clients upfront (eg, initial analysis and design, development, testing, go-live). These milestones become our objectives, which keep us in check throughout the project and gives clients clarity on what can be delivered and when. Remember that not all clients are the same and there is no one-size-fits-all approach. Some of our clients wanted to retain a waterfall approach to software delivery, while others relied more on an agile approach. It was important to us as an organisation to work with our clients on their preferred delivery model as this alignment meant the greatest chance of success.
We are now set up in teams:
- The size of each team may vary, but should be between six and nine people to encourage effective collaboration (less than six creates key man dependencies, more than nine gets difficult to manage and meetings start to become inefficient).
- Each team has a team leader (a project manager/business analyst) who is responsible to ensure all meetings take place and assists in planning, specifying requirements and resolving issues.
- We started pre-planning with clients, sprint planning with the team, stand-ups, regular demos and retrospectives.
- We split up the teams according to clients, products and skillsets and had one Jira board per team. This gave every team member a transparent view of the tasks in the backlog and those that are in the active sprints, which creates a greater sense of collaboration and accountability
The results?
Pros:
- Teams remain agile in their approach and delivery frequency to the client improves.
- Teams still get good exposure to diverse work by working across a number of projects, clients and technologies.
- Junior members still get lots of exposure; however, it is more organised and structured, which gives clients confidence in their ability.
- Key man dependency on senior resources decreases because we encourage collaboration and seniors play a bigger role in technical oversight and guidance of the other layers.
- The team structure provides economies of scale, which means that senior resources can commit to more research and development and ultimately improve our technology offering.
Cons:
- A shift in delivery strategy means an element of training is required to facilitate new roles and responsibilities – more time spent on co-ordination and planning, less reactive.
- There may not be a one-size-fits-all solution; we pride ourselves on our long-lasting client relationships, big and small.
- Handing over knowledge and skills to other team members takes time.
Conclusion
Without challenging our delivery model, we would not be making improvements. Singular chose the hybrid approach to project delivery to ensure we were able to cater for all of our clients' delivery requirements (big and small). Choosing the correct tools to help leaders manage a team effectively is important. Tools can really help software delivery as we grow and scale; Jira, Confluence, Slack and BitBucket all drive visibility and collaboration.
To avoid silos, the teams are set up at the optimal size and across more than one project/client. This change took some getting used to, but clients are already noticing the benefit of having a team looking after them rather than one ‘go-to’ resource.
Always challenge the status quo, but remember, there is no silver bullet. Ultimately, (good) software delivery comes from a well-organised team that is able to build trust and deliver value through timely planning, thorough understanding of the business requirements and being pedantic about service excellence.
Share