Partitioning Operations and Projects with Azure DevOps (VSTS) and Agile
First off let me start by saying that if you haven’t had a look at Azure DevOps (VSTS) get with the program its 2018 and Microsoft’s suite is full of some incredibly powerful business tools.
It seems that while everyone is aware of the quality benefits of the iterative Agile approach many organisations struggle to implement it successfully. They cannot fit it to their traditional non-iterative waterfall project management reporting structures and mindset. This is because traditional waterfall focuses on sequencing and milestones while agile is iterative and evolving.
In one environment, we have a very small team that successfully runs a setup that processes 50 000 online orders a year. We manage the website as well as the custom operations management portal for our customer.
Anyone who’s worked in a support environment will know just how difficult it is to keep track of the sheer volume of user generated calls without some sort of categorisation methodology. Trend analysis, issue clustering and any critical mass analysis without visibility is impossible.
On any given day, we can receive upwards of 20 calls that need to be categorised into support calls, bugs or enhancement requests. Each of these needs to be tracked and feedback provided to the customer and individual call loggers throughout the process.
At the start trying to decode this is not so simple, but we have developed a pretty robust process for taking thousands of work items, and ordering them into a coherent work flow where items are seldom lost.
Aside from our management contingent we have 1 support analyst, 2 senior analysts, 1 project manager, and a team of developers, this is an unusually small team for such a large project. To run so lean we must be process driven, and each team member must hold up their commitments.
Agile
Before getting into the nitty gritty of how we split and manage the pipeline let’s look at Agile, and share our definitions of the work item types.
In Agile there are 6 types of work item;
· Epics
· Features
· User Stories
· Issues
· Bugs
· Tasks
Here’s an easy overview of how the work item types are categorized according to our process:
Team Structure
We split the ownership of work items according to functional work units and technical work units, in our view the developers are only responsible for the work units required to get something working. Everything else is created, documented and managed by the analysts. Here’s an easy graphic to explain this understanding.
To explain it in a bit more detail we break the roles down as follows.
Support Analyst
So, we start with first line support and traffic management which is the support analyst’s role. Calls can come in via two channels, a support mailbox or a call management portal.
The support analyst is responsible for ensuring that the call is in fact a valid call. Initially they will need guidance from the senior analysts on expected system behaviours, but after the probationary period issue should be familiar and they should start gaining autonomy.
The support analyst replicates issues and documents the reproduction steps to make sure that anything logged is a real issue and that the downstream team member has all the information they need to be able to understand the issue.
DevOps has some great tools for capturing issues automatically as they are tested by the analyst.
The support analyst can assign issues and bugs to developers directly to have them fixed during the day to day operational activities. Once these have been fixed the support analyst performs the initial testing to confirm that the issue is no longer replicable. The work item is then passed on for user acceptance testing.
Anything that is identified as requiring a business rule change or major functionality changes is assigned to a senior analyst for further analysis, documentation and signoffs before it becomes an official initiative.
Business Analysts
Business analysts are responsible for 2nd line support for the support analyst and managing any enhancements that arise out of support or feature requests.
Once an issue has been identified as requiring a business rule change or a more extensive system change than can be managed by a support call the business analyst needs to step in to understand the issue and document it correctly.
We have a stock standard enhancement lifecycle:
1. Analyse
2. Document
3. Sign off
4. Development in Branch
5. Internal Testing
6. User Acceptance Testing
7. Transport to Staging/QA
8. Staging/QA Testing
9. Production Roll Out
Project Manager
Finally, our project manager is responsible for most of our customer communications and updates. The project manager sets up any meetings, serves as an escalation point for the customer and keeps the team advised of the customer priorities and on track.
Development
We have a small team of specialised developers who split their time between operations and project work. This is not an ideal setup, but we have managed to make it work by ensuring that two core things are in place 1. the items that get to the developers are actual issues 2. There is sufficient information available for them to investigate properly. During the dark times before DevOps we could have up to 400 open calls. Now if we have more than 20 open work items there’s a systemic failure.
This may seem like a very simplistic approach to managing a demanding environment but it is the simplicity — aided by the granular visibility provided by DevOps that allows things to move smoothly through the SDLC.
