Scrum Project Management: From Chaos to Calm
When I joined 15gifts as a project manager in 2016, there were 16 of us. The company was the epitome of a start up; the atmosphere was fresh, exciting, constant high energy, and there was a distinct feeling of camaraderie throughout the business — we were all in it and we were in it together. The evident lack of process almost added to the charm of the business, there was ample room for creativity, innovation and a natural aversion to corporate principles and practices. The issue, however, is that lack of process goes hand in hand with chaos, which isn’t sustainable and doesn’t pave the way for a happy, successful and scalable business.
So when I was tasked with implementing some kind of order to the chaos of our new build projects, I was daunted to say the least. I didn’t have a lot of confidence in our estimations or timelines and wasn’t sure where to start.
Fast forward to 3 years later and 15gifts now has over 40 employees, a reliable planning, build and delivery process, a scrum process for our development and UX teams, a kanban process for design and analytics teams, a release process… just to name a few. And guess what? We’re still that high energy, innovative and creative business with an aversion to corporate principles and practices. We still feel like a family, just a bigger one, with more successful projects under our belt and an even stronger culture. We are now at a place where our project deliverables are delivered on time and if we have delays we feel fully in control and prepared for them. In short, the inefficient chaos we were living in just three years ago feels like a distant dream.
All of our adopted processes have contributed to this, but for this post, I want to focus mainly on Project Management and Scrum, how we have approached them, and the Scrum Project Management role that we’ve carved, which has a number of advantages in successfully delivering software development projects for teams of a similar size.
Our Project Management Process
Using the PRINCE2 methodology as our basis, we took the relevant principles, themes and processes, adapted them to suit us and eventually found our own tried and tested framework for delivering new builds.
The biggest impact for us has been taking all seven basic principles of PRINCE2 and applying them to our projects in a repeatable format. For example, we introduced ‘internal kick off’ meetings for everyone involved in the project internally in which the agenda is always the same:
- Project executive presents the business case
- Product owner presents a finalised scope of work
- Project manager presents the status of open items and next steps
- The team ask any questions and raise any concerns they may have about the project.
This meeting alone addresses three of the basic principles, leaving the other four to be adopted throughout the build stages of the project. It also sets up the planning process nicely. The team now feel informed and invested in the project, leading to accurate estimations and a sensible project plan.
We also started mapping the PRINCE2 recommended processes to our own project management processes but quickly found that our stages didn’t exactly map to those recommended. We did, however, take the relevant activities and add them as part of our own defined stages, sprinkling in roles and processes from the Scrum framework as we went. The stages we now use for a new build are:
- Project Scoping
Key deliverable: A scope of work - Project Kick off
Key deliverable: Jira tickets covering all pieces of work, the project plan - Development design
Key deliverables: Finalised designs, relevant analysis, finalised Jira tickets - Build
Key deliverable: Final product live - Project close
Key deliverable: A project retrospective and handover
Using a combination of the above, along with other changes to roles and responsibilities and the way we estimate and plan (I will cover this in more detail in a future post), our delivery has now gone from a year later than planned in some cases, to pretty much on the day, give or take a few days (we are a software development company after all!). If there are delays, we are now able to foresee and prepare to mitigate them. Most importantly, we’re now at a point where we feel confident in our project plans, confident in our estimations and confident in delivering new builds.
Our Scrum Process
Scrum has become a vital framework for software development teams and we are no exception. Similar to what we did with the PRINCE2 framework, we took the core Scrum roles, rules, events and artefacts and introduced those relevant to the development team. We successfully embedded the principles and the team responded well to the framework initially, but then developed a little resistance and some elements became a slog.
After spending some time analysing why, we made some useful changes. We reinvented the core sprint meetings (sprint planning, retrospective and stand ups being the main culprits), to make them more efficient and useful. We also created some ground rules for our sprints, for example we established which tickets get accepted into a sprint and which don’t.
Once we had made improvements, we added a small incentive to keep the team invested in the process so we could keep improving. If the teams complete 80–100% of work in a sprint, 3 sprints in a row, they get cake and beer. Some people say that the introduction of cake and beer had the biggest impact on the process, but I choose to ignore those people.
It became clear that there was an obvious need for a role to manage the ongoing improvement of our sprints, and keep them ‘alive’. We wanted it to be someone who already knew the team and the processes well, so we decided to combine the roles of Scrum Master and Project Manager into one. Both roles are traditionally focused on improving processes, leading successful delivery, and working with similar teams so it felt like the right move. The role was an experiment for us; we weren’t sure if the combined role would work or would result in one person doing the work of two people. But as a company who enjoys new challenges, we decided to give it a go!
Scrum Project Management
I started the new role of Scrum Project Manager with two core objectives in mind. I wanted to help our sprint teams consistently achieve 80% of their sprints, and I wanted to deliver our new build projects on time and with minimal stress to the team. Not only did the role help us towards both of those things, but it came with added, unplanned benefits:
- Project plans have become a lot more accurate
With a stronger knowledge about individuals, departments and how they work together, it became clear where to add contingency in timelines and how to accurately convert story point estimations to chunks of time, down to the individual developer. - Common, recurrent dependencies are more familiar
As well as helping with accurate planning, this has made highlighting, communicating and explaining dependencies internally and externally a lot easier. - Project progress is more visible
Being able to see tickets move through the sprint, and hearing about its progress during stand up means progress is easier to gauge. In combination with the ground rules we’ve implemented into the sprint, there is now clarity on how each piece of work is progressing, and what the hold up is if there is one. Having the visibility and knowledge of our sprint release processes also helps with planning client-facing releases and communicating any delays ahead of time. - No more nagging!
With the increased visibility, there’s less of a need to disturb team members about the progress of work. If a blocker is at risk of causing a delay to the plan, it’s visible right away and it’s easier to coordinate unblocking that piece of work without having to ask someone for the details. Delays and risks are much easier to foresee and mitigate in advance. - Developers are more involved in project delivery
Developers have context around why tickets are in sprints in a particular order and there’s more knowledge around dependencies of each piece of work. The timeline is put together with a lot of input from the team, meaning they have been a part of deciding their own deadlines. There is also plenty of opportunities to raise any concerns or questions about the project during the scrum meetings. - Project plans get more investment internally
The Scrum PM manages scoping, estimation, planning and delivery of the final product along with the developers, so they have that constant bridge to the project’s deadlines, goals and stakeholders. This means that communication becomes a lot smoother, and eventually this great communication has led to increased trust and buy-in from the team. - Retrospective feedback influences project planning
A lot of points (both positive and negative) arise at sprint retrospectives which have informed the way we plan and run projects. The Scrum PM gets an insight into what stresses out the team and can see if there are any persistent trends in feedback which relate to project process. The Scrum PM is able to action relevant feedback and make immediate, beneficial changes to the process.
So far, these changes, along with introducing the Scrum Project Manager role, have made a positive impact to the overall delivery process. We sent out a survey and 100 percent of our dev team felt that the merging of roles had a positive impact to the scrum and delivery process. However, we still have plenty of improvements to make and it has become clear that we need more Scrum Project Management resource. As we get busier, the attention to the finer details is getting lost, and our scrum rituals are getting a little less love.
We now face decisions on how to hire for the next role in this team. Do we split it back into the traditional Scrum Master and Project Manager roles? If we do, do we lose a lot of the benefits we’ve gained from the combined role? Do we hire more Scrum PMs and how do they sit within the current structure of three sprint teams? Or do we take on scrum project administrators who can provide support to the processes and maintain the finer details? We’d love to hear your thoughts, let us know in the comments below.
