Agile has become the prevalent methodology when it comes to managing IT projects, such as software development. Scrum is a type of agile methodology and is essentially an agile process framework.
But instead of looking to scrum as a means of achieving better project management, superior output or improved alignment with business objectives, some organizations seem to be looking at the adoption of scrum as the goal itself, the answer to every problem. Unfortunately, it’s not so simple.
Scrum can facilitate incredible improvements in project management and project output, but it’s not the answer to every problem. Marek Boratyński is a certified Professional Scrum Master and, during his 15+ years plus experience, he’s experienced scrum from the perspective of Developer, Consultant, Architect and Manager. Marek explains what you need to consider before adopting scrum for your IT projects.
In any given project, there are a range of factors that need to be considered: the business objective(s), the scope, the budget, the project team and the stakeholders. Furthermore, every project has its own specifications, such as duration and scale. All of these parameters need to be correlated so as to ensure (or provide the highest likelihood) of project success.
Since agile has gained widespread popularity as a methodology for managing IT projects, many organizations are asking themselves ‘is there really an alternative to agile?’. As part of this growing trend towards agile methodologies, scrum has emerged as one of the most commonly adopted frameworks. And while there is a strong case for scrum, it’s naive to think that simply implementing or adopting scrum will ensure the success of a project.
Based on my observations, my experience and my takeaways from discussions I’ve had with peers that I respect deeply, I’ve identified the main problems that I’ve encountered with how scrum is currently being used, and my intention with this blog post is to provide you with some advice on what you should try to address before you implementing scrum as a methodology for your IT projects.
Implementing scrum within a project team isn’t going to be the remedy for every problem or instance of underperformance. In fact, in many cases, the implementation of scrum as a process framework can do more harm than good.
If, for example, a project team is used to working in a waterfall method and is looking to improve its performance, then the implementation of scrum, without changing team habits and attitudes, will certainly not be the answer.
If you have team members that are not motivated to change or who are not open to developing their skills and to adapting to industry trends and business expectations, then simply changing the project methodology and process framework will not deliver the results you’re looking for.
For this reason, it’s absolutely vital that you select the right people for each project. This starts with an empowered and single-minded Product Owner, it continues with a Scrum Master who knows when and how to take decisive action, and it trickles down to each and every team member, who should be enthusiastic about what they’re doing, know why they’re doing it and thus be able to spread this enthusiasm and awareness to those around them. Picking the right team for your scrum project is the first step toward the success of a project.
Many IT or software projects fail because project objectives are not clearly defined. If you’ve worked within IT for a few years, you’ll almost certainly have come across or been involved in a project where there are several business stakeholders. They have their own ideas and objectives, but they also have a budget and a deadline.
The problem is that these established ideas and the need to meet a budget and deadline often take precedence over exploring and building out a proper functional scope, which remains at a generic high level. This means that the project starts with too many question marks, and almost inevitably becomes problematic.
Matters are further complicated if we hear phrases like: “but we’re working with an agile methodology, so we can still change things during the project, right?” Not exactly. With this type of approach, the likelihood of project and budget overrun, and even project failure, increases dramatically, and it might not be long before you’re all staring disaster in the face.
It’s vitally important for each project to have its business objective fully explored, defined and communicated to the project team. This should be supplemented with an exploration and initial analysis of the functional scope, and the plotting of milestones and mini milestones within a project.
The Product Owner – the person with decision-making power within a project – should, ideally, also be a beneficiary of the proposed solution. Equipped with a defined business objective and functional scope (at least a framework or draft), the Project Owner should be able hold the key business stakeholders to account for the quality of input they provide and their role in the project, and thus minimize the risk of a project deviating dramatically from its stated business objective.
Every project has a budget. A budget can be built according to a variety of different factors, including: number of workdays required or available within a time period, function points, story points or defined tasks that need to be completed. Regardless of how we build the budget, it needs to be managed responsibly.
Scrum should force us to apply the appropriate level of discipline in a project so that the process of writing the code and building the product is predictable and aligned with goals and defined parameters. This should contribute to effective production and satisfied stakeholders.
The fact that we use an agile methodology like scrum methodology does not free us from the responsibility for appropriate planning, budgeting and management of scope changes within the project. The product that we deliver should meet business objectives. If those business objectives have changed during the course of the project, then it is the Product Owner’s responsibility to manage those changes and the project team’s responsibility to alter course accordingly.
And while agile methodologies like scrum are receptive to change, it’s the responsibility of the Product Owner and project team to not abuse this receptiveness. A never-ending barrage of changes to original scope can lead to a project team coding in circles in pursuit of a constantly moving target. It’s akin to watching a dog chase its tail. And while that analogy might bring a smile to your face, the news that a budget has expired, and the product does not yet deliver on the latest business objectives rarely has the same effect.
Any decision to implement a change within a scrum project should be taken consciously, in an informed manner (i.e. understand the request properly, ensure the risks and implications are known and communicated) and with the consensus of all the key stakeholders.
I’ve been involved in plenty of projects that have experienced a high degree of change – we expect and welcome some degree of change in any project – but the difference between those that continue on to success and happy outcomes for customers, and those that don’t is the presence of a strong-minded Product Owner and team-wide discipline in managing project scope and project budget.
In fact, regardless of which methodology you’re applying to your project, discipline in change management should be considered a key foundation.
Scrum can bring about a lot of benefits – such as lower costs, greater stakeholder and team satisfaction, faster time to market and closer alignment with business objectives – but it’s important to make sure that you’ve got the right team, the right approach to articulating business objectives and the right approach to managing change requests within projects.
Without these, applying scrum is unlikely to bring about these benefits. Furthermore, scrum can’t be your answer to everything – there are still going to be cases where you’re working in challenging circumstances, with resources, stakeholders and tools that could be better or more abundant.
But, if you address these three key issues in advance, you are much more likely to be successful in your project, and if that’s a scrum project then you’re all the more likely to reap the compelling benefits of this agile methodology.
One of our biggest success stories with scrum has been with one of the largest projects delivered by ITMAGINATION. In 2012, we started a strategic partnership with a leading global construction company to deliver a new ERP system.
We started the project using a mix of different methodologies. The business analysis was conducted using a waterfall model, but as we entered the development stage, we introduced more and more agile elements. Yet the process wasn’t quite perfect – we were experiencing ‘feature creep’ and the time between the initial analysis and the delivery of a working product was longer than we aspired to.
In 2014, we began looking at alternative methodologies and, in 2015, we transitioned to scrum and the SAFe framework (an agile methodology that is perfect for large-scale projects). Soon after this transition, several major improvements were observed – there were fewer defects, features delivered were found to be more useful and more aligned with user needs and business objectives, and both business and user feedback improved dramatically.
Today, the system we’ve built is being used by seven business units across five European countries. We’re adding new features to the system all the time and continue to use scrum as the methodology to do this.
We have been cooperating with this client for 10+ years now and the team working on the ERP system is constantly growing.
At ITMAGINATION, we are big advocates of using scrum in IT projects. We have experience of implementing scrum on projects of different scales and in a variety of different sectors and for companies around the world. As well as using scrum on projects delivered by ITMAGINATION, we also help organizations implement scrum for their own projects, and provide training and consultation services to help our clients reap the benefits of scrum and other agile methodologies.
If you’re working out how best to implement scrum as a methodology for your IT projects or if you have an IT project that you feel scrum could be right for, get in touch. Looking for a new role? Join us!
.svg){kind=small}
