Agile Surgery - Real World Sprint Challenges

By Craig Howarth, Charlotte Sutton, Leah Unsworth-Hughes, Donna Tosney and Hannah Ellston, The Agile Surgery Team

So, you’ve planned your Sprint and surely it will run like clockwork? What could possibly go wrong?

In our latest Agile Surgery session, our team of looked at the gap between the textbook and reality. The team identified some typical real-world Sprint challenges and tactics we can use to handle these situations effectively. The session covered Testing, Fake News and Shifting Scope and Priorities (with lots in between). The Agile Surgeries are always designed to be interactive and so ‘you asked, and we answered’.

Below is a summary of some of the questions and insights from the team:

The organisation I work for preferS to plan future work (in excess of TWO future sprints) according to existing capacity. What is the attitude of the panel to this type of approach?

As a headline this is great! But digging into the story behind this a bit more: it can be difficult to manage stakeholders when they want to plan to a minute level of detail very far in advance but this can be tackled by taking the stakeholders on the journey with us as we shape and plan our delivery.

At the start of the delivery we produce epics and provide t-shirt size estimates upon which we can base our outline forecast. Is this 100% accurate? No. Is it useful? Yes.

As we move through our delivery, we learn as a team and ideally our velocity ramps up and we begin to understand what the team can achieve and what is sustainable. From this, we can use the average velocity from the previous Sprints to plan going forwards and see how this impacts our initial outline forecast and end delivery date. This is all about using the information we have today to predict as accurately as we about the future.

If we outline this approach to our stakeholders, they will be more likely to be accepting of any changes, as opposed to being surprised by what they may view as slippage at the 11th hour. If, for example, on our plan we think it will take us four Sprints to address the riskiest areas of the delivery.We'll tell the stakeholders this to pre-empt any fluctuations we can explain today. Finally, make use of any tools at your disposal. If you have Jira use the version report to track movement in your planned delivery date and explain any key events which have impacted this.

What are the benefits of having a ‘definition of ready’?

This focuses upon setting our team up to succeed ahead of the Sprint. When we ask our teams to meet quality and coding standards and our Definition of Done, they can only do so if the Stories – and other tasks – at the start of the Sprint allow them to do so. By this we mean:

Is the acceptance criteria known and agreed with the team?
Has thestory been estimated and is a suitable size to be delivered within the Sprint?
Are external dependencies resolved?

Aside from the benefits of having a Definition of Ready, the risks of not having one also need to be highlighted. Essentially in skipping the Definition of Ready we expose the team to more risk during delivery and often end up with in-Sprint surprises. Looking at this from a fake news perspective, this is often seen by our stakeholders as stories which are not delivered, low velocity and under-performing teams, as opposed to the root causes behind this.

The other aspect of the Definition of Ready which is sometimes forgotten is the insight it gives us into the refinement process ahead of the Sprint. This was seen on a project two years ago where stories weren’t being completed, there were a high number of unknowns and blockers were arising during the Sprint. When this was reviewed, we found that the interface definitions were so out of date that the planned integrations kept failing due to missing information.

The result of this was a review of the refinement process, which led to an increase in the amount of upfront analysis required, to ensure better quality inputs to the team and ultimately fewer defects. The other thing that this brought to light around the refinement process was around the unseen effort – and cost – required ahead of the Sprint which the business didn’t see. When the refinement process was amended the blockers and issues flipped from being in Sprint to refinement based and the issue then became ensuring there was a sufficiently refined backlog to fill the next Sprint. Whilst any blockers can hinder us – identifying the right blockers and resolving them is the best way forwards for the overall delivery.

How do you timebox a Spike? How do you manage a Spike effectively?

The challenge with a Spike is that we are in the realm of unknown unknowns, however this doesn’t mean that we can’t structure our approach to it. We know the broad topic and the area that we’re going to be exploring, meaning that we can set ourselves clear acceptance criteria. For example, we may have a key technical challenge that will inform our approach which will mean we need to produce the minimum level of information to enable us to make decisions.

A key point to remember with Spikes is that they can go one way or the other – i.e. we could work through a series of options and proceed as planned, or, come to the conclusion that it is not a valid option to take forward.

One approach you can take to help define this minimum level of information is using a Three Amigos session to discuss and agree the acceptance criteria and planned activities. The key here is to define what we need to know at the end of the Spike – i.e. do we have sufficient information to prepare subsequent Stories based upon what we have learned. We then agree how long we should time box these investigations for, otherwise the risk is that you could spend weeks looking for an answer which could easily delay your overall plans.

What should developers do in the final days of a sprint?

If you find that development work has been completed and your developers are left with available time then it is important to keep them focused on activities that still add value to your sprint.

Having ‘T-shaped’ individuals in your team is a great bonus as they have the potential to assist with any testing that still needs to be completed and therefore ensuring the work allocated in your Sprint is completed.

Otherwise, have a look at your backlog; developers could start analysing any tech debt or Spikes for any challenging work which may be coming up in the next Sprint. This will help in refining the work to a greater detail and therefore reduce the risk to delivery.

Setting stretch goals for the Sprint is another option which will also help to utilise the developer’s capacity. However, be mindful when setting stretch goals. If the stretch goal requires testing, then you may find yourself back at square one! Also ensure that your stretch goals aren’t included in your burndown for that sprint, as they are a stretch and not a commitment.

How do you best integrate design tasks into your sprint plans?

It is important to try and plan design tasks for example, have your designer working one Sprint ahead of the rest of the team. This allows the team to ask early questions that may impact development and test activities and therefore the story is more understood when it comes to development. Design activities often work well following a Kanban style as there can be discovery work to complete as part of understanding the design requirements at the lower level of detail.
The team also benefits from getting early sight of wire-frames and prototypes in the sprint playback or a Design 3-Amigo session can be scheduled ahead of starting their development and test activities.

How do you balance an Agile approach with stakeholder need for detailed plan and milestones?

Moving to Agile is a cultural shift. When stakeholders want to measure progress in milestones and have detailed plans it’s because that’s what they’re comfortable with or used to and you team need to help them on their Agile journey and start to manage their expectations from the get go.

A key element to succeed is by building up open communication and trust. Sharing and collaborating with stakeholders early and often will give them the understanding they need. It’s really important to keep them in the loop as you estimate, plan and get into the detail. This gives them the visibility and confidence not only in your plans but in the Agile approach. Use these opportunities to educate them on estimation, breaking down user stories, planning etc and how through this they will get the detail they require and, in all likelihood, more confidence as you're delivering thin slices of functionality.

It’s worth remembering that you do still have milestones in Agile. The cadence of the sprint will give you opportunities to share progress and being able to demonstrate progress with your MVP via frequent demos and releases will help to reduce concerns. Finally, make sure stakeholders understand their role in the delivery, attend ceremonies and are actively involved.

Should a sprint goal be specific or generic - what does a good sprint goal look like?

Sprint goals should be concentrated on a user-focused delivery that the entire team can work towards. It’s not just a case of bundling all the tickets on the Sprint backlog together. You should be able to explain in a sentence, maybe two, what the Sprint will deliver. Ideally you want one goal for the team that they all agree on and can measure if they’ve succeeded and it should cover all the attributes of SMART i.e., specific, measurable, attainable, realistic and time bound.

Not every Sprint goal will be perfect, you might start off too generic or too detailed but that will improve as the team matures. The important thing is that the team understand what they’re working towards, what it delivers for the user and what’s the definition of done.

Thanks again for everyone who joined the session and keep a look out for the next ‘Agile Surgery’. Our Agile Surgery series is designed to support, grow and help the Delivery community.