Your agile scrum team can’t do it alone
15 June 2018
Okay, so now you have an agile scrum team. Good for you! But unfortunately, you are not there yet. The decision to use agile software development is only a first step in involving your (entire) organisation in digital projects. A study of Collab.net’s agile working showed that ‘general resistance within the organisation to change’ is a major cause of the failure of agile projects. If your project is to really stand a chance of succeeding, then the rest of the organisation must also be prepared to move along with you.
Agile means agile, not for nothing
My experience is that companies are not so reluctant to introduce agile working in software projects. Where it falters is that they think that the agile/scrum development process stands on its own. However, this way of working has an impact on the entire organisation. Agile means agile - a great deal of flexibility is needed to apply this method successfully, and not only in the team itself. After all, you don’t do laps around a residential area in a Formula 1 car. You have to provide the right environment and conditions. This requires a change in the culture of many companies.
Baseline measurement does not dictate the continuation of the project
At the start of a project or at the start of a team, the conditions are established that are necessary to achieve the desired result. This also includes agreements with the rest of the organisation. There is no point in setting this down in a contract; it is a baseline measurement that cannot be set in stone. Retrospectives and other interim benchmarks are intended precisely to evaluate, adjust and monitor where the project is and should be heading. Agreements with the rest of the organisation are evaluated just as well as agreements made within the team, by looking at how many sprints are needed, what the teams should look like, and so on.
You can imagine in advance that a sprint will last two weeks, but if practice reveals that three weeks is better for the course of the project, then an adjustment is necessary. This not only has consequences for the team itself, but also for the release cycles, test cycles, reviews (a combination of a demo and an explanation of how much has been delivered and what is still to come), reports and invoices.
After all, you don’t do laps around a residential area in a Formula 1 car. You have to provide the right environment and conditions.
Distributing work differently has consequences for the entire organisation
A practical example: two teams were deployed for a company, one for development and one for maintenance and minor further developments. It soon became clear that the maintenance team was starting to miss the challenge. Scrum teams need that challenge, especially in the current employment market where it is even more important to keep your employees satisfied.
So it was decided to divide up the work differently, with each team being given a bit of innovation and a bit of maintenance to do. However, this had an impact on the velocity of the development programme, budget allocations, administration and the division of tasks of the product owners. But because it was essential to the success of the project, the rest of the company had to adapt.
This kind of flexibility in the rest of the company is also entirely in line with the agile manifesto, which states that contracts are important, but good cooperation is even more important. The aim is to build the best software together, in an open culture in which everything can be debated. Companies that are prepared to exchange the false security of contractual agreements for flexibility have taken a major step closer to successful agile software development.
This article was published earlier on Emerce.