Blog

(R)evolution of the development organization

Written by Rene van Seuren - Senior BPM Consultant

Monday, 18 December 2017

In the last couple of years I’ve seen and gone through several organizational changes for the software development organization. The different methods/frameworks that were applied to the organization I’ve seen are Waterfall, Scrum, DevOps, Feature teams & Agile scaling. In this blog I will give a short introduction of the five methods/frameworks I encountered and are commonly used within different organizations. Looking at these methods/frameworks, I noticed a lot of overlap between them and usually one method/framework is built on or extended from another method/framework.

This method was used with traditional software development. You first do a full analysis and create a complete functional and second complete technical design of the system by an analist team. When the complete design is done, you start building the system using a development team. Once the building of the system is done, a test team will test the complete system.

Within the framework of scrum you have a hybrid team consisting of designers, builders, testers to work on small parts of functionality. These small parts of functionality are called user stories. The order in which the team works on user stories is determined by the product owner. The product owner is the linking pin to the business stakeholders and the ordered list of user stories is called the backlog.

Work is done in short cycles called sprints. A sprint usually takes 2-4 weeks. A sprint starts with a planning session to determine what is to be picked up in the current sprint. The scrum team will look at the backlog and determines how many user stories fit in the sprint. For those user stories selected, tasks are created on the scrum board. The tasks are to make sure that by the end of the sprint the user story is ready to go to production. The scrum board is updated throughout the day and discussed during the daily stand-up. The daily stand-up is held each day, to see what the team members are working on and to see whether the team is still on track to complete the user stories within the sprint.

At the end of the sprint, the team will show & tell to the stakeholders the progress on the deliverables of the sprint (e.g. demo delivered software) and looks back to what can be improved for the upcoming sprints.

Where scrum ends for the scrum team with tested software and reviewed deliverables, the DevOps team takes it a step further. The DevOps team is responsible for the complete lifecycle of a system. This includes development of new software, but also getting it to production and making sure the software keeps running in production. Therefore, a DevOps team is a combination of Development and Operations. A DevOps team can also use scrum as a framework. For DevOps, the scrum board will include additional tasks for releasing the system and maintaining the system.

With DevOps you will see that the team will not only work on applying changes to the system, but also on automating the lifecycle management of the system (Continuous Integration, Continuous Deployment).

The experience I have with feature teams do not comply with the theory. So when you search for feature teams on the internet you will find a somewhat different description than I’m about to give you.

A scrum team or a DevOps-team usually works just on one system alone. In lots of environments your system will have to interact with other systems. This interaction is usually realized by calling services on another system. So when implementing new (business) functionality you could end up making changes to multiple systems. These changes to one or more systems are called features. Everybody working on one feature will have to be ready with their changes in the different system at the same time, to be able to test and release it together. To make sure the different systems are ready at the same time, you define a feature team.

The feature team consists of developers and testers of the different systems involved in your feature and they are together responsible to complete the feature. So if you have for example 3 systems you could end up with teams consisting of developers and testers of system A and B for one team, and for another team A and C and for yet another team A, B & C. For each new feature, you determine which systems are involved and how the team is formed.

Working with features teams can of course be combined with (parts of) the scrum framework or DevOps.

This is the most evolved method/framework I have personally seen while working on projects. Since the company Spotify was the first one to use this method/framework it is also called the Spotify’s framework. This method/framework uses a combination of the previous methods and frameworks.

Squad: is like a scrum team/DevOps-team.

Tribe: group of squads working on the same system/component/feature.

Chapter: members of squads sharing the same role (e.g. developer, tester). Members of different squads and/or tribes can be part of the same chapter.

Guild: a virtual group of people sharing the same interests (e.g. test automation: developers for unit testing and testers for system (integration) testing). Members of different squads and/or tribes can be part of the same guildmembers.

Within Agile scaling you usually use the framework of scrum to organize the work within a squad.

Conclusion

This blog gave an overview of the different methods/frameworks I have personally seen while working at projects. In my next blog I will give my takeaways I learned while working with these five methods/frameworks.

About René

I am a Senior BPM Consultant and I like to work on complex integration issues combining processes on one side and service integration on the other side. I aim for short and long term solutions to satisfy both functional (business) and technical (IT/Ops and platform) needs. These solutions need to be understandable for all relevant parties (business, architects, developers and maintenance).