How small tweaks can bring long-lasting process improvements

Reviewing processes and making tweaks can bring wide-ranging and longstanding benefits to a team

“One Way street sign beside road far at the mountain during daytime” by Nick Tiemeyer on Unsplash

I recently caught up with an old colleague of mine. We had a chat about our time working together; the great people we worked with and the impact our work made to the end users.

One of the things that we looked back on was the difficulty we had in delivering our sprints and how we went about changing it for the better.

In this post I’ll describe the processes we inherited, the obstacles we faced in bringing change and the positive results we achieved in time.

I was part of a large team who managed a business critical site with 800k visitors per month. This would often go up to 2m during busy periods.

With many stakeholders with a vested interest and a highly distributed development team tasked with delivering the work, there was a lot of responsibility resting on the shoulders of the Product Owner and Digital PM to bring it all together.

Pain Points

When I joined the team, I didn’t immediately take over from the existing PM. This gave me an opportunity to assess existing processes and identify any pain points that existed:

Divided Teams

There was a clear sense of division between the product team representing the wider business and the technical team responsible for delivery.

1. Fragmented planning - The product team would discuss potential features with the wider business without the input of someone representing technology. Some features often required a substantial investment of time, but they weren’t always validated, clear or prioritised.
2. Lack of trust - Rare meetings between product and tech were often frosty, with one side making requests and the other not sure if they are possible. Add a distributed development team to the mix and you’ve got yourself the perfect ingredients to create confusion and a lack of trust.

Agile?

Whilst there was a general consensus to work in an Agile approach, in reality, this was simply not the case.

1. Lack of communication - There would be just 1 or 2 meetings between the product owner and the tech team to plan for the upcoming sprint. The development team were really introverted and often were not vocal enough with their questions.
2. Never-ending sprints - Once sprints began, it was like a revolving door. New stories were added to the sprint late on and there was undue pressure placed on the tech team to deliver. Releases were often delayed and when work was pushed live, bugs were a frequent occurrence as things were rushed over the line.

Testing Bottlenecks

We had 2 full-time QA team members responsible for completing Regression, Integration and Smoke Testing. There was a clear pattern; we experienced bugs on work done later on in the sprint. These would then have to be re-worked in upcoming sprints.

As this was a large site, it was impossible for 2 people to test it in its entirety late on, so inevitably corners were cut which resulted in defects.

Objectives

We had to focus on reducing waste in order to deliver value and increase our throughput.

The wider stakeholders were initially quite reluctant. They were worried about losing control, losing visibility and the impact on timelines.

However, I was confident we would see improvements if we could:

1. Reduce time spent on planning
2. Reduce time spent on manual testing
3. Reduce time spent fixing defects
4. Reduce time spent working on features not required

Capacity Planning

Teams usually set aside 70% to 80% of their capacity on development. Ideally, you want to allocate:

• 50% on development of features
• 20% on ceremonies
• 10% on engineering activities and improvements to code i.e. deployments, refactoring
• 10% on manual testing
• 5% for updating your automated test suite
• 5% for contingency

An estimated calculation of capacity allocation before our changes and the ideal scenario we were striving towards

The data represents our overall time at a very high level. We were still doing sprint planning and estimating story points, this just helped us account for ‘everything else’ a delivery team has to do.

It’s crucial you invest time to review and improve areas away from core feature development.

Improvements

Implementing Scrum

The first thing I wanted to do was implement Scrum to bring some sort of structure for everyone involved. This would mean:

Fixed Sprints

We limited our sprints to 2 weeks, usually occurring twice a month. Once sprints started, we would resist any late additions to it.

This dramatically improved visibility between teams. Everyone was aware when sprints would start/end when planning was due when stakeholders were required to validate work when we would release into production and so on.

Ceremonies

To improve communication and promote collaboration between teams, I wanted to incorporate Scrum ceremonies into our process.

1. Sprint Planning - Gives the Product Owner and development teams a chance to clarify, estimate and lock in the stories for the upcoming sprint.
2. Sprint Reviews - Gives the product team an opportunity to review what we delivered in the last Sprint.
3. Sprint Retrospectives - Managing a remote team brings its own challenges. A retrospective gives them the opportunity to speak in a safe space, helps them feel part of the team and ultimately build trust between the development team and myself.

Conversations between the Product Owner and the development team were no longer one-sided.

A short sprint cycle meant the product team could utilise new features quickly and start collecting feedback from real users.

Stakeholders also felt more involved as they could see their stories come to fruition and were no longer in the dark about when or what would be delivered.

Simplified Planning

We were confident we could deliver more valuable functionality, with fewer defects if we spent less time going back and forth on every potential feature and did not have to accommodate for additional work late on.

To achieve this, we ensured potential features were validated, stories were broken down, clearly prioritised and had all the necessary information for the development team to accurately estimate — Before they were put in front of the development team.

Source: Manifesto Digital — https://manifesto.co.uk/how-to-measure-velocity-agile/

After we completed a few sprints, we were able to increase our planning accuracy further by utilising the Velocity metric. Whilst it is by no means 100%, it gave us a better indication of how much work the team could do in a sprint; again helping the product team prioritise their features.

Automated Testing Suite

For an enterprise level site, we simply could not continue with the obvious bottleneck and had to improve our testing processes and overall efficiency.

This required a significant investment over several sprints but unquestionably went a long way to provide long-term benefits and cost savings.

The outcome of this meant our QA experts could focus their attention on validating stories and we could run regression, integration and smoke tests (and generate a report) at the touch of a button.

Ultimately, we were no longer holding our breaths when deploying to production and had significantly fewer defects to fix.

Harmony between teams

Managing expectations is a big part of a Digital Project Manager’s job. However, this shouldn’t be just limited to delivery.

Clearly defined roles - As part of bringing structure to the development process, I wanted to ensure stakeholders were aware of what was expected of them. For example:

1. When they should be available for validation
2. How they should raise bugs/emerging requirements and when they can be worked on
3. Planning pre-requisites such as clear requirements with acceptance criteria and a well refined, prioritised backlog
4. Ensure features have been defined, designed and researched, taking into considering user feedback long before they are added to the backlog — To avoid developing things that won’t be used/no longer relevant.

This resulted in less friction between teams, reduced guesswork, fewer defects and created a positive environment that felt less like product vs tech and more like one team working towards delivering value for our users.

Conclusion

Having just joined the organisation, I initially encountered some resistance to the changes we proposed. However, with the right support, I pushed through and implemented them gradually.

Over time, tangible results followed and ultimately we released quality features and improved communication, interaction and overall teamwork right across the business.

Finally, You should never stay still. There are always ways to improve your tools, techniques and processes. For example, once we had a handle on our processes, I started looking at engineering improvements i.e. Continuous Integration.

Notes

1. Whilst these changes worked for us, they might not be the best option for you. Experiment, review and improve where needed.
2. There isn’t a one size fits all solution for any organisation. Agile/Waterfall/Scrum/Kanban — There are a lot of options! In my experience, it’s usually a combination of these that might be your best route.
3. I have decided to not name the company in question. However, I must emphasise, the support I got there to make these changes and to do my job was incredible. I have no doubt that this was the best place I’ve worked at so far.

Further Reading

How to measure and use the velocity of Agile teams by Louise Bliss
How to Create Virtual Co-location: A guide to managing remote teams by Galen low