Scrum in an Integration Landscape: Do or Don’t?

Let’s go Agile!

Many of our customers across all lines of industries, be it Telecoms, Utilities or Banks, are switching from traditional ‘Waterfall’ methodologies to Agile software development. The reasons are always alike: they want to be able to go to market quicker than their competitors. They want to be able to respond to change in the market. They see that their lengthily requirement gathering only leaves them with software that is useless once it’s handed over to the business.

And almost always the next ‘logical’ step is to choose Scrum as the Agile framework to follow. Scrum is the most widely known Agile development framework. And if all these big companies are ‘going Scrum’, it should work for every company! We are often asked to guide our customers in this adventure of actually switching to Agile. However, sometimes to their dismay, our answer to their question if Scrum is the way to go is: ‘It depends’.

It Depends…

Scrum indeed promises that cross-functional teams deliver working (!) software every few weeks (‘the Sprints’) response to change, and close customer interaction. But these promises come at a price. Management cannot tell that IT needs to change to Scrum and do not change themselves. Let’s have a look at these promises and see what they really mean.

Cross-Functional teams, Cross-Domain

So, we just put Integration architects, designers, developers and testers in one team, and we have a cross-functional team? No. That would mean that each sprint (remember: two to four weeks) is a ‘mini-waterfall’ in which Design hands over to Development, which in turn hands over to Test. You need teams of people that are willing to boldly go where no man has gone before. Like teaching testers how to code. It’s just a start.

But not just cross-functional. More and more you see one department (e.g. Integration) is switching to Scrum, hoping other departments will follow. And when they do, they create a new type of waterfall… The Front-end team is waiting on the delivery of the Integration team, who is waiting for the Back-end team. Again: Waterfall. If you truly want to benefit from Scrum, you need cross-domain teams.

Every Few Weeks

How do I continue? You will need working software every few weeks (a sprint) and to be able to respond to change. This means that teams needs to be able to commit to the sprint goal itself. The team needs to be independent of external factors (such as changing interfaces).

Respond to Change

Scrum responds to change. Priorities and even requirements may change at the start of each sprint. However, the sprint goal cannot change during the sprint, or the team’s commitment will break. This is something management also has to commit to. Even high-priority changes will have to wait until the next sprint.

Customer Interaction

Teams that succeed in Scrum are striving to show working software to their business stakeholders every sprint. How frustrating is it when the same stakeholders do not show up at your demo? Or if you really want to understand the business needs and there is no one available to answer that crucial question? Successful Scrum teams depend on a committed ‘Product Owner’ and involved stakeholders.

So? Don’t Scrum?

So if successful Scrum is so hard, don’t do it? As said: It depends. If you have cross-functional and preferably cross-domain teams, please do. If you can keep change outside the door during a sprint, yes. If you have a truly committed Product Owner and really involved stakeholders, by all means: Go for it. If you can’t, you can still have the benefits of Agile without Scrum.

Scrum is Agile, Agile is not always Scrum

Please remember: Scrum is not the only Agile framework out there. They come in all kinds of flavors, from very prescriptive (e.g. Unified Process) to almost anarchistic. We learned from experiences with customers asking us to help their Integration Competency Centers (ICCs) switch to an Agile way of working. If the rest of the IT Department will continue to work as it was, succeeding with Scrum will be a challenge.

Instead, we advise to streamline the Integration Competency Center using Agile and Lean principles. We help transform the ICC into a smoothly running Integration Factory that is able to iteratively deliver working software to its stakeholders. By visualizing the workflow and limit work in progress, we can continuously improve the ICC process.

Concluding

Scrum is a widely used and powerful Agile framework that enables cross-functional teams to iteratively deliver business value to their stakeholders. However, Scrum is a tool and not a goal on itself. We can help you speed up your time-to-market, improve stakeholder involvement and increase your responsiveness to change by finding the Agile framework that suits your company best.