I have not taken a typical route into IT and software development, although, as I look back at the roles I have undertaken I am able to see some similarities and reuse of skills.
After graduating from university with a degree in Criminology and Social Policy, I spent seven years as a civilian in the police force acting as a conduit for the requesting of communications data, examining mobile telephones and analysing incident/crime data. I got to a point and time where I had limited career progression and so I moved into the NHS as an analyst, analysing healthcare data for NHS publications.
One of the publications I helped to write had the data processed by an external third party prior to it being made available for analysis. A decision was made to bring the processing of that data in house. Initially my line manager was to be the Product Owner on the project, however, he could not commit his time to all the Scrum events and so I was given the opportunity to undertake the role. It was an opportunity that introduced me to the world of software development and Agile.
Over the next 18 months I was the Product Owner on a £2.5 million project that used an internal, then external development team. As the project drew to a close I decided that I didn’t want to go back to my role as an analyst, wanting to remain in the world of IT. The structure of the organisation meant that there was not another Product Owner role for me to step into, however, I was lucky enough that there was an opening for a Scrum Master and my application was successful.
I have since spent the last three years as a Scrum Master (with varying job titles) at three very different organisations. This has provided me with exposure to different Agile methodologies and processes, third party and offshore development, time zone and cultural differences as well as different levels of autonomy.
There is a world of difference between examining a mobile phone and helping to remove impediments for a software delivery team. So where do the similarities lie? One answer is data, and the analysis of that data.
In my roles in the police force I analysed various types of data to generate Problem and Target Profiles, as well as Tactical and Strategic Assessments, which allowed for inferences to be drawn as to:-
- who was committing the offence(s)
- what offence(s) was being committed
- why the offence(s) was being committed
- where the offence(s) was being committed
- when the offence(s) was committing it
- how the offence(s) was being committed
This analysis required me to take data from multiple sources in order to make links, connections and show associations. It was my role to turn data into information in order to be able to make a hypothesis or draw a conclusion. From the inferences that I was able to make, it was possible to make suggestions as to where patrols should be targeted, at what time they should happen and who they should be looking for. On occasions, the results of my analysis would result in me preparing exhibits and giving evidence in court to explain how these links were made.
As a Scrum Master I have been able to do a similar thing using the metrics that I am able to retrieve about the team’s progress. I have been able to take data from various sources, link it together, analyse it, draw conclusions and make recommendations. This data has included (but is not limited to):-
- control charts
- cumulative flow diagrams
- phased cycle time charts
- number of tickets completed (done)
- percentage of time spent on different themes of work
- average velocity
- burn-down charts
- burn-up charts
One example of how I used this data related to a change in our delivery process where we combined columns for business analysis, technical elaboration and test analysis into a ‘3 Amigo’s’ column. We ran an experiment to see if we could reduce the time it took before development started (code to be written) by collaborating the efforts of three (or more) people at the beginning of the process. Previously it would take 3-4 days before a user story would go into the ‘Implementation In’ column, whereas by encouraging collaboration, it was possible to reduce the time it took for an item to be ready and waiting to be picked up to under a day. This also resulted in a reduction in average cycle time. I will discuss the process we went through in more detail in a future post.
Another similarity between my roles in the police force and my time as a Scrum Master is the pace of work at multiple levels. In the police force a Strategic Assessment would be completed every six months to provide an overview of what has been happening in an area, how it has changed and to project what may happen in the future. I equate this to a software delivery project that has on overall goal over a longer period of time. Within the project, if the team is using Scrum, they will hopefully be delivering a product increment in Sprints (normally of 2 week duration). Sprints align well with the fortnightly Tactical Assessment that gets produced in the police force. The Tactical Assessment highlights the shorter term issues in an area, which may prompt action to stop a situation deteriorating or developing. The Tactical Assessment meeting is like a demonstration, retrospective and planning session all rolled into one where the report is reviewed and discussed to work out what could have been done better, identifying actions and planning how to implement them. A third level is emergency response. In the police force this would be a life at risk incident, where all other work is put on hold until the incident is over. In IT a similar thing will occur if the service/website you support becomes unavailable. The development team may need stop what they were doing in order to help resolve the issue.
Hopefully this has provided a brief glimpse of the roles that I have undertaken and an insight into my Agile journey so far. One thing to remember is that an Agile journey has no destination. There will always be bumps in the road and deviations from the path. There will be obstacles to overcome, changes in technology and new processes that could be adopted and/or adapted. These developments will provide the opportunity to continue to inspect and adapt, with a view to continually improving and learning.
My Agile journey continues.
Next time I shall continue to look back at my Agile Journey, looking at my time as a Product Owner in more detail.