Why DevOps is great for our projects and our clients

At PDMS, we use DevOps regularly and in this article, we discuss how it benefits our clients and why it works for our software development projects. 

PDMS has been using DevOps (previously VSTS and TFS) since 2005. DevOps is a Microsoft Software as a Service platform based on the Azure cloud computing platform that provides a complete set of tools to manage software development projects. It   is an all-inclusive tool that allows us to communicate with our clients and each other.

Essentially, a linchpin to our operations, it enables us to plan and deliver software developments and provide ongoing support and maintenance services. We use it in all our projects, and in partnership with our clients to guide stakeholders and users through the software development life cycle, and through key stages of projects and post go-live changes.   

DevOps provides transparency during development, with opportunities for our clients to monitor progress and provide direct feedback, and due to its versatility, we can continually adapt and tailor our practices and ways of working to meet the needs of each client. We liaise with our clients at key stages of development to ascertain how we can use DevOps to better serve them which, at the same time, enables us to learn and improve our services. 

As part of our internal continual improvement objectives, we regularly review how DevOps is used across the organisation. Our aim is to standardise internal processes, following best practice, while allowing ample flexibility to deliver an excellent service to our clients.  One of our Project Managers explained that DevOps is key to enabling everyone involved in the project to be able to know, at any given point, exactly what stage a project is at, allowing them to shape and plan with ease.   

Tools to assist with project planning  

There are multiple tools that allow our Project Managers to effectively plan projects, whether it be enhancements to an existing system or the build of a brand-new system. The main features used for planning are Iterations, Capacities and Delivery Plans.  

Capacities are set for each Iteration to allow us to plan an appropriate amount of work the for allocated resource, and monitoring that we hit our Sprint deliverables instils confidence that we are on track to complete the project within the allocated timeframe.    

Delivery Plans pull through Iterations and their associated requirements to create a delivery plan, after which milestones and markers can be added, to allow both the internal team and clients to see clearly what is expected to be delivered and when.   

Tools to enable seamless operation  

During a project, the team will meet for short focus meetings, known as ‘daily stand-ups’, to check the project is on track to finish the committed work within the timescales. We use DevOps features such as Burndown charts, Burnup charts, Work Details and Boards, making project progress very transparent.   

The Burndown chart provides a ‘Remaining Capacity’ and an ‘Ideal Trend’ line, which are calculated from the team’s capacity for that Iteration. It plots the capacity remaining each day throughout the Iteration, allowing us to clearly see whether the work we have remaining is achievable within the team capacity remaining. If the project starts creeping over the ‘Remaining Capacity’ line, this would indicate that there’s too much work to complete for the remaining capacity of the team. Checking this chart daily allows us to spot and remedy any sign that we may not be able to deliver everything within the Iteration.    

The Burnup chart takes a step back from the day-to-day monitoring and tracks the amount of work being achieved, as well as any scope increase/decrease, on a whole project basis. It estimates how much of the project is complete and predicts how much time will be required to complete the whole project. From our client's point of view this is extremely valuable to ensure the project will come in on time and within budget to allow us to proactively trigger action plans to bring the project back on track.  

Work Details goes hand in hand with the Burndown chart. Team capacities are added for each Iteration, which then builds the starting point of the Burndown chart. Work Details display how much work is assigned to each Discipline and how much of that Discipline the team has within the Iteration. In the same way as the Burndown chart, the remaining work and remaining capacity are updated daily and used in daily stand-ups. Checking the Work Details daily allows early detection to remedy any sign that it may not be possible to deliver everything within the Iteration.    

Boards provide a high-level view of where each requirement is up to within a workstream. This is very helpful to ensure that both the internal development team and our clients understand the state of all requirements, not just the work within the current Iteration. The Board provides a strong filtering feature. The Board is customisable via the interface, which allows for any project nuances to be catered for with ease.  

"As a Project Manager, I always find myself needing to slice the DevOps data in different ways to feed into multiple reports. There are two main features in DevOps to allow me to report with ease: Queries and Dashboards. DevOps has an extremely powerful ‘Query’ tool that lets me search for any data in DevOps. It also allows me to extract the data into a CSV or into a PowerBI dataset report, to distribute to clients and colleagues outside of the core development team. These queries also feed into data on the Dashboards." - Hannah  Phillips, Senior Project Manager

Tailoring dashboards for individual projects 

Dashboards are a highly visual way to show the queried data to both clients and internal team members. Bespoke, highly configurable Dashboards for projects are created to suit the client’s needs.  They can be used as a simpler way of identifying the work needed to be done in DevOps and provide high-level summaries to our Project Sponsors.   

DevOps also allows us to embed external reports, which is very helpful for tracking project progress against budget.   

Phases of the project   

When starting a new project, a standard board template from DevOps is chosen, typically one which follows the Capability Maturity Model Integration (CMMI) process, based on Epics, Features, and Requirements.  For new projects or major developments on existing projects, a new Team within DevOps is set up, which creates a new set of Dashboards, a new Backlog, and a new series of Sprints.  Once this initial set-up is complete, Epic, Feature and Requirement work items for the project are created in the Backlog.   

Epics are the highest level of work item hierarchically and typically corresponds to a core business function for the client, a core user type, or a top-level menu item.   

Features are the next level down and correspond to key business processes that the core business function or user performs.   

Finally, Requirements, one of the words most closely associated with Business Analysts, are specific pieces of functionality that the system must be able to do to meet a user’s need; alternative industry standard terms here are “User Stories” or “Tickets”.   

When a Waterfall approach is adopted, Business Analysts must write fully detailed Requirements in DevOps, to allow Developers to proceed with the work, with minimal input from the analyst or client. This involves extensive upfront collaboration with the client and consultations with the project team; all documentation and meeting outcomes are logged against the appropriate Requirement.  

When we use an Agile approach, we adopt a more minimalistic approach to upfront analysis and log just enough detail against each Requirement so that its objective is clear.  After the initial Backlog is complete, we consult the client to ensure that they are happy with the initial scope of the project, at which point we would proceed to Agile development.  

Once a project goes live, it enters the maintenance phase of its life cycle. This includes support requests to address any issues found, once the system is used in earnest by all stakeholders, and further change requests to support “business as usual” operations and enhancements to existing processes.  

Final Thoughts   

So, here's a snapshot of how DevOps works for PDMS and benefits our clients on multiple levels.  By allowing our clients to see the dialog internally, it gives them reassurance for time frames and completion of work items, which then eliminates the need for endless emails and updates. Importantly, the transparency of DevOps also gives our clients more control, and they can have complete confidence in how the team at PDMS is delivering their projects and ultimately business goals.