Sprint reviews and retrospectives (retros)

The retrospective is slightly different. These, like any retros in project management, is an opportunity for those involved to look back at the sprint and highlight learnings or challenges that should be discussed and considered for future phases. Retros may be as quick or detailed as the sprint and team members’ experience dictates.

Ongoing product development over finite project

Great software in this era is as much about the ongoing support and maintenance as it is about the initial product releases. Scrum allows businesses to release a ‘product’ and get real world usage, without being committed to keeping any aspect of the product static. Think of some of the most prominent SaaS products, such as Xero – this platform is continually receiving updates from their internal teams to add functions, streamline existing features, update the design and user experience and so on.

A common approach in technology projects is to base a large project around developing a product from scratch (or significantly overhauling it), and then transitioning into more BAU, day-to-day product maintenance. Both stages can benefit from a Scrum methodology.

Possible drawbacks of Scrum for an IT project

Scrum isn’t right for everyone or every project. There are some issues that can come up if the organisation isn’t well equipped to keep to the methodology and mitigate certain risks. Common drawbacks include:

• The lack of a concrete end date – there may be an initial end date based on the first product backlog, but as we’ve explored in this guide, these can evolve and change – making it very hard to accurately estimate the end date.
• Scope creep – it’s pretty much built into Scrum that new requests from Product Owner, stakeholders, end users and even the Scrum team itself will change the parameters of what’s being delivered. This can really help the product be its best. However, if left unchecked, it can create serious resourcing and budget headaches. A scope still needs to exist and be protected with a Scrum methodology project, although these are typically more high-level and are focused on end users’ needs.
• Team sizes and scalability – Scrum is designed to scale, but as teams and projects become larger, natural collaboration becomes more challenging, and more attention needs to be placed on project management. Sometimes a product will split off into smaller teams to manage parts which enable the group size to stay manageable.
• Organisation culture and structure – businesses really need to commit to setting up Scrum teams to win – that means an understanding of the way work will be delivered, planned and completed by senior leadership and stakeholders. Businesses that are new to this approach may experience some teething issues if they’re more familiar with a waterfall methodology.

IQANZ provides specialist assurance services for technology projects across the private and public sectors. We apply proven assurance methodologies along with a high level of technical expertise to help guide projects and programmes to success. If you’re interested in getting independent, expert help on your technology project, get in touch with our team.