As an Agile Project Manager, Amy has been instrumental in running Kyan projects with Scrum methodology in mind. Scrum and agile approaches are now commonplace in software development cycles, and whilst you can follow these processes to the letter, they’re also flexible enough to customise for your business and make them your own. Here are our key learnings from running agile projects using Scrum.
1. The importance of sprint zero
Our process is always evolving. Previously, we moved straight from the initial design sprint into sprint one. Although there was often a gap between the two, very little project work happened here. What we did have was the very beginning of a non-prioritised product backlog, which lacked input from UX, Product Designers and Engineers. This meant that the planning session for sprint one became pretty full-on and fraught.
Whilst the Scrum framework doesn’t formally include a sprint zero, many teams use this period—often one week—to undertake initial tasks. For Kyan, the emphasis of a sprint zero is to ensure readiness for the first sprint and often includes:
-
Discussions around architecture
-
Setting up the environment
-
Delivering a small, usable piece of code
-
The Product Owner and UX Team fleshing out the product backlog (as much as possible but typically at least two sprints’ worth)
-
The Product Owner prioritising features ahead of the Sprint One planning session
-
Release planning by the Development Team and Scrum Master
-
Sprint process familiarisation led by the Scrum Master. This is because not all team members have experience in working with the sprint process, so it's helpful to lay the foundations before we begin
One of the key benefits of running a sprint zero is that the wider team can get a base understanding of the work ahead before the first day of sprint one. This increases their confidence and enables them to self-manage. It also reduces impediments and blockers by encouraging discussions around the more complex project elements, or what we call the ‘unknowns’.
2. Nothing beats a great Product Owner
There is an art to being a fine Product Owner, much of which comes with experience. The rest, I find, is down to character.
We’ve been blessed with some amazing Product Owners, and their key characteristics include being decisive, resilient, curious and empathetic. Decisiveness is key to making important decisions under pressure, whilst also keeping their Product Owner and Stakeholder hat on. Resilience, because (as I’ll come on to) projects of multiple sprints are lengthy and demanding. A curious Product Owner engrosses themselves in the detail of the project. They gain an understanding of the wider project, how things fit together, the different dependencies between disciplines and how to see things from multiple viewpoints, including that of the Engineers. This leads me on nicely to the empathic quality; which is being understanding, firm-but-fair, and praising the team when it is deserved.
3. Projects with a fixed number of sprints are actually marathons
It’s important to keep in mind the number of sprints the project requires. The client and their team are often impressed with the output and methodology, so they proceed with future sprints. This makes Agile development a marathon and, while ‘sprints’ is the technical term used, it is imperative for all involved to remember the following:
"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
— The Agile Manifesto, Principle 8
This constant pace is tricky to master, but is key to consistency. Therefore, it’s important for all team members to invest similar amounts of time throughout all sprints. So for those who are on the project full time, pacing themselves for say, eight weeks, is key to reducing burn-out.
Some of the tell-tale signs of sprint fatigue include:
-
Team members arriving late for meetings, consistently
-
Body language of team members, including slouched shoulder and less eye contact
-
The tone of voice and words used by those in the sprint
A project that we are currently running has seen four 2-week sprints, with a goal to launch a site with a customised CMS and API integrations. We knew it would be a challenge, but the Product Owner has been excellent at controlling the scope, making priority calls and looking out for our Engineering team. However, during sprint three we noticed a slight drop in the number of user story points delivered compared to the previous two sprints. We still hit our sprint goal, but found we delivered less of the nice-to-haves, which would have kept us on track for overall delivery of the client’s end-to-end desired MVP.
In the sprint retrospective for sprint three the team were not as engaged, looked tired and had lots of feedback for the ‘lacked’ and ‘longed for’ categories. So it was obvious to me that it was time to make some subtle changes.
Ways we’ve found to mitigate sprint fatigue include:
-
Ensuring team members take annual leave
-
Encouraging team lunches
-
Agile training and framework refreshers
-
Changing locations for meetings and co-working
The art of a good Scrum Master is to spot the signs of sprint fatigue and put in place measures to counter it. Scrum Masters should be in-tune with the wider team, be personable and approachable, whilst helping the team set and stick to their sprinting pace.
4. It's not always about being better but being consistent
Don’t get me wrong, we absolutely want to improve and get better as project teams and as a company (hence the ongoing company-wide knowledge sharing and learning), but we’ve realised that being better is a by-product of being consistent. Consistency is key to ensuring the full Scrum team, which includes the client, feels comfortable and familiar with the process. It is really important to trust the tried and tested method.
When you first break it down and calculate all the meeting time, ad-hoc chats, questions, PR reviews, plus some downtime (because as I said before, even during a marathon, you don’t run the entire distance) there is a lot of what I call ‘non-doing’ time. For the Engineering team, this is essentially non-development time and accounts for 35-40% of their 80 hours per fortnight when working on an Agile project. The majority of this time is spent in the Scrum meetings; sprint planning, daily stand-ups, sprint review and sprint retro. Plus, where necessary, peer code reviews and product backlog refinement.
Initially, there was push back from team members on the number of meetings and time lost to these discussions. However, having completed and delivered projects, the wider team now appreciate the rigour and structure that these meetings give. It is not just the time to think and share but also the pace that these sessions provide that aids the team. It would be really easy to skip a retrospective if the team felt their time would be better spent developing, but we’d lose the consistency and learnings from this session and, in my opinion, we’d take two steps back to take one forward.
5. You don’t always get it right first time so try, try again
As is the way when adopting new ways of working, we are constantly learning the best way to implement methodologies and frameworks to suit us. And, whilst we’d like to always get it right, realistically we learn something every sprint and we usually find that we agree on at least one thing to change in the next sprint, sometimes more. These are documented and shared for all teams to see.
Following the framework and the meeting schedule provides a safe and reliable structure so that project issues can be raised and resolved quickly. Successes can be shared with the wider business to cascade out the learnings to everyone.
In summary, we are loving the Agile methodology and in particular, the framework Scrum provides. We are working more collaboratively within Kyan and also with our clients (Product Owner and Stakeholders), which can only result in better products and happier colleagues who look out for each other and learn together.
