Written by: Development Manager Henrik Wendt
Scrum: Time was when IT developers could work on a solution for half or even an entire year before sharing a single screenshot with the outside world.
The waterfall model, which was the preferred project management model for developers, meant long project times and an enormous risk of launching systems that were not user-friendly or that quite simply were outdated even before release.
This fortunately changed in the 1990s and 2000s with the advent of the Scrum method. The vast majority of development departments nowadays feel at home with terminology such as “Scrum master”, “Sprint”, “Project owner” and “Grooming”.
Although I have myself used Scrum methods in our development department for more than 20 years and have more than 400 sprints behind my back, we have learned little in the process.
In this article, you therefore get my take on the three most common reasons why IT departments are not successful with the Scrum method.
1. You get too ambitious with your product
The fundamental idea behind the Scrum method is that you can develop your product in short stages and get continuous feedback on the solutions you are developing.
To be able to get back feedback, you are therefore required to be able to continuously release the stages of development you are working with. We ourselves work with daily releases internally at our development department so we can see daily what our newest code looks like to the user.
Once our sprint is over every 14 days, it is our clear objective to always have our work ready to be demonstrated to the steering group — so that the rest of the organisation can keep up.
Nice-to-have or need-to-have?
If we are not able to release at least a demo version of what we are working on, this can be a sign that we have been overly ambitious with the functionality of our product.
This can indicate that our idea of the features and functions we would like to include in the software has not passed the test of “nice-to-have” vs. “need-to-have”.
To get the full value of Scrum, it is actually important to constantly evaluate the importance of a feature. The mindset behind agile development depends on the ability of the steering group and the project owner to prioritise the features that need to be developed in such a way that we constantly develop the system in small, but material increments (if we continue using Scrum terminology).
So always keep in mind that you should not develop more than what you can get away with releasing. It is not a question of jumping wherever the fence is lowest, but of rather choosing which fence you would like to jump over in an intelligent, user-oriented manner.
And by the way, we have also written an article on finding the right fence when it comes to IT support efficiency. You can read it here.
2. You fall for the idea of the week
In Scrum, you constantly select new features to work on. You need to be ready at all times to change course and develop other features than the ones you thought you would just a month ago.
The agile approach to development is essential. The changing prioritisation of features is what prevents your product from being outdated even before launch.
But the ability to change direction between every sprint also brings about the risk of falling for the good features of the week: an enquiry about a feature from a customer, a special desire from the sales department or perhaps a quick change of direction sent by the management.
However, once we ourselves fall into the trap and use a particular sprint for developing a feature that would “seal the sale to a potential customer”, we are confronted with two problems:
- The customer may still opt for another provider
- The rest of our customers will not be able to use the developed feature
In other words, we have wasted a development sprint on a worthless feature. On the positive side, the waste is limited to two weeks of work, whereas without the Scrum method, there could have been far more man-hours down the drain.
Putting “brilliant” ideas in quarantine
To avoid falling for the “idea of the week”, you can set up a waiting period for new ideas. By putting new ideas in quarantine for shorter or longer periods of time before considering them for your priority backlog, you are given the opportunity to see them somewhat at a distance.
It is really a question of letting the idea’s honeymoon period pass so you are able to see past the initial zeal and enthusiasm and so you are better equipped to assess the idea in an equivalent way with the other features and development ideas in your backlog.
If the new idea requires urgent attention — or it is, in other words, necessary to close a case or similar — and you therefore do not have the option to put it into temporary quarantine, then make sure that the entire steering group subscribes to the idea and that everyone in the steering group can see that the idea generates a material value for the exact function in the organisation that they represent.
The potential of the idea must be clearly visible to sellers, project managers and developers — as well as users — before it makes any sense to include it in a sprint.
3. It is necessary to reinforce synergy in the organization
The last pitfall that can cause the development department to fail with Scrum is linked to cooperation across departments. It is therefore a question of an organisational issue rather than an actual problem with the development approach.
Success with the Scrum method namely requires extremely effective communication between the development department and the other business areas of the company.
This requires the development department to be aware, at all times, of the needs of departments as well as customers and, for example, the sales department to be continuously up to date on the latest system updates.
If the sales team is completely up to date on the latest features of your solution, you raise your competitiveness, because you give your sellers a better product to go to market with.
Conversely, it is also important that sellers know exactly which features are being launched and which ones are still on the drawing board so they do not end up closing orders with promised functionality that is not ready yet.
Cooperation with the entire operations
The synergy between the sales and development departments is naturally necessary, but synergy with some of the other business units can turn out to be even more vital for avoiding both unnecessary annoyance and shadow IT.
For example, it can be of the utmost importance that the finance department can influence the timing of major EPR upgrades so that you as an IT manager do not come to release extensive system updates just three days before the deadline for the VAT accounts.
Just like in many other contexts, it is also often in the communication between people that the development department fails — Scrum or not.
Short development sprints and the changing focus of development merely strengthen the need for good communication and synergy between departments.
Therefore, make sure that you have check-in meetings with decision makers and users from the rest of the operations at regular intervals. Find a balance that is suitable for you. A briefing once a month can be a good place to start.
All in all, a good Scrum process is a question of being at the cutting edge of things and making conscious choices.
You are well on the way to valuable Scrum development if you care to take a proactive approach to communications, a healthy scepticism of “brilliant” ideas and cynical realism about what is possible and what is necessary — and what not — to launch a value-adding product.
