How to scale Scrum - a couple of words about the Nexus agile development framework
In January 2018, the world saw the updated Nexus framework - a tool based on Scrum, sharpened for team work on large projects. The authors of the methodology corrected a number of definitions of terms and changed the licensing procedure. Since the beginning of the year, the Nexus Guide has been distributed under a Creative Commons license. And this means that any company can freely use Nexus (like Scrum).
We will tell about the features of the methodology and its main components.
/ photo by Sebastian Sikora CC
')
In 1996, the developers Ken Schwaber and Jeffrey Sutherland introduced the Scrum software development methodology to the community. It is a set of strictly time-limited iterations (sprints), for which developers must implement new functions for the program.
As Jeff Sutherland notes, in his book “ Scrum. A revolutionary project management method , Scrum allows development teams to achieve “super-efficiency” and increase productivity by 300%.
However, Scrum has a drawback - it is well suited to work within one team (and the recommended number of participants is only seven), but it doesn’t “scale” well beyond its boundaries - when you need to coordinate the work of a large number of people.
To correct the situation and help scale the methodology, in 2015 Ken Schwaber introduced the Nexus framework. Nexus helps to avoid common problems of joint development: difficulties in using the same code base and inconsistencies when integrating the practices of different teams.
Nexus used iterative and incremental approaches to scaling software development processes. Each team works within its sprint, and then their results are combined. Due to this, product development is easier to coordinate.
The framework consists of roles, events, artifacts, as well as rules that unite all familiar to any Scrum adept. In Nexus, these components have changed a bit so that the methodology can be applied in large-scale projects.
Roles According to the Scrum methodology, all participants in the development process are assigned certain roles. They can be divided into two large groups - "pigs" and "chickens". The first group includes all those who are directly involved in creating an application: a scrum master (Scrum Master), who holds meetings and monitors compliance with the principles of scram, the product owner (Product Owner), representing the interests of end users, and, in fact, the development team (Development Team).
The second group - “chickens” - includes end users, vendors, consultants, etc.
In Nexus, to help with scaling the methodology, the role of the Nexus Integration Team (NIT) has appeared. This is a whole team, which includes Product Owner, Scrum Master and representatives of scrum teams. Their task is to assess the potential problems of team development and prevent them. It is important to note that the members of the NIT are not directly involved in programming, but give recommendations on the application of the Scrum and Nexus principles to all other participants.
In general, the implementation of the NIT helped to improve coordination between the teams through the proper distribution of tasks. However, members of the IT community say that the new role also contributed to the creation of a kind of “bottleneck” - when members of NIT solve organizational issues, the development team is idle while waiting for instructions.
Artifacts. In Scrum, artifacts are a set of product functionality requirements that help organize developer activities. These requirements are described in two logs: the project backlog (project backlog) and the sprint backlog (sprint backlog).
The project's wish list lists the general requirements for functionality — the so-called user stories , sorted in descending order of importance. They help to get an idea of ​​how the final product should look.
Sprint Wishes Log - a list of implementation features selected by the product owner. Based on this list, developers track the tasks that need to be completed before the end of one sprint.
In Nexus, instead of a project wish log, teams use the Product Backlog. To simplify the interaction of a large number of developers, this magazine is divided into parts. Each part is “assigned” to one of the teams. So, all developers understand what tasks they are doing from the whole project. In addition, each team still maintains its own wish list of the sprint.
Developments. All team members attend meetings, sometimes called the general term “events.” "Pigs" spend them daily, and "chickens" - at the beginning and end of the project or sprint. Meetings are needed to discuss development progress, estimate plans, identify bottlenecks.
To improve communication between different teams, Nexus developers have added four new types of events:
On the official Nexus Guide, you can find the interaction scheme and the sequence of all these events.
In large-scale projects. The framework helps to seamlessly organize the work of several scrum teams in large projects. For example, one Indian company creating security-software (the Scrum authors did not disclose its name), used Scrum for the year to develop its products. Initially, the company had one scrum-team, but soon their number increased to three, and problems began with the integration of individual solutions.
Then the company invited an expert on Scrum, and he proposed to move the Scrum workflow to a multi-team level - to implement Nexus. Now, six teams are working on the Nexus methodology, which are consistently releasing new software releases every two weeks.
In large companies. For example, the IT department of Terminales Portuarios Peruanos (TPP), which deals with maritime freight in one of the ports of the capital of Peru, took nine months to release a new version of the core software. To remedy the situation, the company tried the methodology of Waterfall , RUP and the principles of traditional project management . However, they all did not give significant improvements, and in some cases even made it worse.
Then the company decided to try Nexus. The technique has reduced the time of release of releases three times and release the product every three months.
Nexus helps to establish interaction between teams scattered across the globe. “Daily sprints” maintain a high level of communication and employee involvement in the project.
Note that although Nexus helps coordinate the work of many development teams when working on a large project and speed up release releases (as is the case with TPP), it is still not able to solve the problems associated with the internal organization of the organization. For example, the framework will not have a noticeable effect if there are a shortage of specialists in the teams to solve all the problems.
Thus, Nexus is suitable for working on large projects (according to the creators of the methodology, it allows you to effectively manage nine scrum teams) and, if properly applied, helps speed up the development process 3-4 times. However, the main focus of this methodology is to solve problems with integration, because it can not help in solving other organizational issues in the company.
PS A couple of fresh materials from the First Corporate IaaS blog:
PS Several publications from our Telegram channel :
We will tell about the features of the methodology and its main components.
/ photo by Sebastian Sikora CC
')
Who and why created the Nexus
In 1996, the developers Ken Schwaber and Jeffrey Sutherland introduced the Scrum software development methodology to the community. It is a set of strictly time-limited iterations (sprints), for which developers must implement new functions for the program.
As Jeff Sutherland notes, in his book “ Scrum. A revolutionary project management method , Scrum allows development teams to achieve “super-efficiency” and increase productivity by 300%.
However, Scrum has a drawback - it is well suited to work within one team (and the recommended number of participants is only seven), but it doesn’t “scale” well beyond its boundaries - when you need to coordinate the work of a large number of people.
To correct the situation and help scale the methodology, in 2015 Ken Schwaber introduced the Nexus framework. Nexus helps to avoid common problems of joint development: difficulties in using the same code base and inconsistencies when integrating the practices of different teams.
Nexus used iterative and incremental approaches to scaling software development processes. Each team works within its sprint, and then their results are combined. Due to this, product development is easier to coordinate.
Nexus components
The framework consists of roles, events, artifacts, as well as rules that unite all familiar to any Scrum adept. In Nexus, these components have changed a bit so that the methodology can be applied in large-scale projects.
Roles According to the Scrum methodology, all participants in the development process are assigned certain roles. They can be divided into two large groups - "pigs" and "chickens". The first group includes all those who are directly involved in creating an application: a scrum master (Scrum Master), who holds meetings and monitors compliance with the principles of scram, the product owner (Product Owner), representing the interests of end users, and, in fact, the development team (Development Team).
The second group - “chickens” - includes end users, vendors, consultants, etc.
In Nexus, to help with scaling the methodology, the role of the Nexus Integration Team (NIT) has appeared. This is a whole team, which includes Product Owner, Scrum Master and representatives of scrum teams. Their task is to assess the potential problems of team development and prevent them. It is important to note that the members of the NIT are not directly involved in programming, but give recommendations on the application of the Scrum and Nexus principles to all other participants.
In general, the implementation of the NIT helped to improve coordination between the teams through the proper distribution of tasks. However, members of the IT community say that the new role also contributed to the creation of a kind of “bottleneck” - when members of NIT solve organizational issues, the development team is idle while waiting for instructions.
Artifacts. In Scrum, artifacts are a set of product functionality requirements that help organize developer activities. These requirements are described in two logs: the project backlog (project backlog) and the sprint backlog (sprint backlog).
The project's wish list lists the general requirements for functionality — the so-called user stories , sorted in descending order of importance. They help to get an idea of ​​how the final product should look.
Sprint Wishes Log - a list of implementation features selected by the product owner. Based on this list, developers track the tasks that need to be completed before the end of one sprint.
In Nexus, instead of a project wish log, teams use the Product Backlog. To simplify the interaction of a large number of developers, this magazine is divided into parts. Each part is “assigned” to one of the teams. So, all developers understand what tasks they are doing from the whole project. In addition, each team still maintains its own wish list of the sprint.
Developments. All team members attend meetings, sometimes called the general term “events.” "Pigs" spend them daily, and "chickens" - at the beginning and end of the project or sprint. Meetings are needed to discuss development progress, estimate plans, identify bottlenecks.
To improve communication between different teams, Nexus developers have added four new types of events:
- Nexus Sprint Planning - at this time, teams decide who will better cope with a specific sprint from the Product Backlog. After that, each team plans its sprint, communicating with other scrum teams so that their tasks do not overlap.
- Nexus Daily Scrum - used to discuss the current state of affairs. Allows you to make a plan for the day or solve the problems of integration.
- Nexus Sprint Review - teams here share their successes on the basis of each sprint.
- Nexus Retrospective - this time is spent on assessing past experience and drawing up a plan to improve the development process in the future.
On the official Nexus Guide, you can find the interaction scheme and the sequence of all these events.
When to use Nexus
In large-scale projects. The framework helps to seamlessly organize the work of several scrum teams in large projects. For example, one Indian company creating security-software (the Scrum authors did not disclose its name), used Scrum for the year to develop its products. Initially, the company had one scrum-team, but soon their number increased to three, and problems began with the integration of individual solutions.
Then the company invited an expert on Scrum, and he proposed to move the Scrum workflow to a multi-team level - to implement Nexus. Now, six teams are working on the Nexus methodology, which are consistently releasing new software releases every two weeks.
In large companies. For example, the IT department of Terminales Portuarios Peruanos (TPP), which deals with maritime freight in one of the ports of the capital of Peru, took nine months to release a new version of the core software. To remedy the situation, the company tried the methodology of Waterfall , RUP and the principles of traditional project management . However, they all did not give significant improvements, and in some cases even made it worse.
Then the company decided to try Nexus. The technique has reduced the time of release of releases three times and release the product every three months.
Nexus helps to establish interaction between teams scattered across the globe. “Daily sprints” maintain a high level of communication and employee involvement in the project.
Note that although Nexus helps coordinate the work of many development teams when working on a large project and speed up release releases (as is the case with TPP), it is still not able to solve the problems associated with the internal organization of the organization. For example, the framework will not have a noticeable effect if there are a shortage of specialists in the teams to solve all the problems.
Thus, Nexus is suitable for working on large projects (according to the creators of the methodology, it allows you to effectively manage nine scrum teams) and, if properly applied, helps speed up the development process 3-4 times. However, the main focus of this methodology is to solve problems with integration, because it can not help in solving other organizational issues in the company.
PS A couple of fresh materials from the First Corporate IaaS blog:
PS Several publications from our Telegram channel :
Source: https://habr.com/ru/post/425337/
All Articles