Insights

Late last year we released a case study on our partnership with a federal government customer providing a middleware product contributing great healthcare outcomes to Australians. While this has been a long-running engagement dating back almost 10 years, it hasn’t always run so smoothly. Our case study touches on some of the challenges and changes we’ve made along the way; this series of articles dives into much more detail.

Throughout the series, we’ll explore and provide examples to illustrate a few core values that have made a significant difference to how we work and to the product we deliver.

• Trust. Having confidence that all parties are experts at what they do and are concerned with the best interests of the partnership and the product it delivers.

• Collaboration. Leveraging the skills and experience of all parties to provide the best outcome possible.

• Eliminating waste. Ruthlessly identifying and eliminating inefficiencies in our value stream.

• Continuous improvement. Constantly looking for better ways of working.

• Iteration. Making incremental improvements and learning from them for our next increment.

• Providing value. Getting value into the hands of our customers more frequently, and learning from it.

None of these are revolutionary, but without them our work had been so much more difficult. As a reader, you should be able to discern these values in the examples we describe throughout the series.

(Interestingly, although as a team we’ve all had a sense of collectively aligning with these values, this is perhaps the first time they’ve been explicitly identified. We can always learn!)

So, let’s get into it.

Our Relationship

The single most important change we’ve made has been in the relationship with our federal government customer. Indeed, although there is still a consumer/supplier contractual relationship, the working relationship has moved towards a true partnership. This has been supported through several years of relationship building at multiple levels: director to director, project manager to project (now product!) manager, architect to architect.

These relationships and the trust they’ve established have allowed us to move to a completely different model for procurement and work approval. Previously, work on our product was procured as distinct projects defined as work packages. This project-based model had a number of inefficiencies: the significant effort involved in defining and agreeing (constraining) the scope of each work package (waste); the frequent requirement to start work at-risk before the work package had been agreed due to time constraints (challenging trust); the fixed cost and scope affecting the effort that could be applied to quality practices; and the resultant tendency to construct large work packages resulting in year-long delivery cycles (not providing value). It also imposed a substantial requirement for strict project management to tightly monitor and control scope, budget, schedule, quality, issues and risk. Perhaps worst, the uncertain funding model meant there was no consistency of resourcing, meaning critical expertise and knowledge was assembled & lost on each project.

By moving to a product and team-based procurement model we’ve been able to eliminate many of these inefficiencies. The team and the product we deliver is now funded on a longer-term basis, and we’re funded to deliver against a flexible product backlog – prioritised by the product manager from our customer – rather than a constrained scope. This provides us with flexibility: to deliver what we want, when we want. And when I say we, I mean we, not us and them: decisions on delivery are informed by the whole team.

The new model also means we can keep the band together. It’s interesting to examine the impact this has. From a purely contractual and financial perspective the previous project-based model may be seen to provide more certainty and short-term control (although even that is questionable). But the impact of the product and team-based model is more significant than dollars and cents (although, again, the more efficient use of such is a biproduct). The new model enables consistency of resourcing, increasing team cohesion and sense of ownership, preserving critical product and domain knowledge within the team, and allowing us to focus on quality and improvement. The value of consistency and sense of ownership can’t be overstated: a team that feels like they’re part of something bigger is much more likely to deliver great outcomes. Most importantly, the new model says we’re in this together and we trust each other.

How We Work

Building on our closer relationship we’ve been able to make some fairly major changes to the way we work.

We’ve started collaborating more closely with team members from our customer and industry through ceremonies such as:

• Monthly in-person backlog grooming and sprint planning

• Monthly showcases to demonstrate and gain feedback on what’s been achieved

• Monthly retrospectives to identify what went well and what could be improved

This increases engagement and leverages experience that we couldn’t otherwise tap into until much further into delivery – often too late!

Our team has focused on simplifying and streamlining standards and processes to improve consistency and reduce inefficiency. A great example of this is moving from a heavyweight upfront design documentation and review process (requiring the collation and management of feedback in spreadsheets!) to a more lightweight and ongoing design process that integrates stakeholders as part of the process rather than purely as a deliverable review authority.

Supporting this, we’ve rationalised systems we use to do our work, particularly:

• Using Azure DevOps Boards as a single work management system instead of having requests and defects spread across both Azure DevOps and Jira, and providing all team members with appropriate access

• Using Microsoft Teams for focused team chat

• Using Azure DevOps Wikis to capture team process and technical knowledge

• Migrating from product documentation maintained in SharePoint and delivered with the release package as Word documents to instead maintain the majority of product documentation directly in Confluence

• Using Azure DevOps Repos for source code management and Azure DevOps Pipelines for build and deployment automation

Using Azure DevOps in particular has enabled some great additional outcomes through the way we use it:

• • Where previously we managed separate teams and product backlogs per target product release, we’ve now instead consolidated on a single team and product backlog, and allocating work items such as backlog items or defects to target releases using the Azure DevOps concept of areas. This means we get a single view of our backlog and priorities – and the work and our team’s capacity to deliver it – while still being able to identify work items targeted for a particular release. This single view also really helps when prioritisation decisions need to be made.

  • We’ve extended work item type definitions to support capturing benefits, deliverables, acceptance criteria, release notes, and functional, technical and test designs – essentially anything that would previously have required several documents and their associated review cycles.

  • By capturing everything related to a piece of work in one place, we’re also able to leverage discussions right in Azure DevOps to discuss all aspects of the elaboration, design or implementation of a work item, pulling in the right stakeholders through mentions as needed.

  • We now have a fairly standard set of tasks & terminology for what’s required to deliver a work item – aligning with our definition of done – which makes sprint planning simpler and achieves a more consistent outcome.

  • We can produce our release notes directly from Azure DevOps as a query, where previously these were painstakingly pieced together from multiple sources by the poor unfortunate soul who didn’t step back quickly enough.

One of the changes we’ve made with the most impact has definitely been maintaining a logical continuous improvement backlog. We allow any team member to capture suggestions for improvement, whether they’re technical, functional, process or culture related. Our continuous improvement backlog items are reviewed, prioritised and scheduled equally with product feature requests and defects. This again highlights the importance of the high trust culture, where ideas for improving the way we do are valued equally with doing.

Finally, a practice we’ve recently introduced with great success is team swarm days. For these days we identify a theme or outcome we want to achieve, for example “migrating & validating unit tests in a new framework”. The idea is to take something that individually would be time-consuming & somewhat dull, and throw the whole team at it for a day. By doing so, we take advantage of the varied skills and perspectives across our team to collectively achieve something in a day that would otherwise have taken weeks – and have fun along the way.

Next Time

That wraps up the first article in our series. Next time we’ll dive into how we develop, build and deploy – stay tuned!