Nexus Integration Team is responsible for keeping multiple teams technically and successfully integrated. The Nexus Integration Team plays a healthy role to ensure that the…
Nexus Integration Team is responsible for keeping multiple teams technically and successfully integrated. The Nexus Integration Team plays a healthy role to ensure that the teams stay harmonized with each other. It gives the necessary support and facilitation to the teams in order to keep them in line.
Members of the Team
The Nexus Integration Team mainly consists of the Product Owner, Scrum Master and Nexus Integration Team Members who can be coaches and trainers or members from the development team. They ensure smooth integration and following the cadence of the work done by the scrum teams. The Nexus Team consists of people who are skilled in the use of tools and technologies to make scaled software development possible.
Members of the Nexus Integration Team may also work on the Scrum Teams in the Nexus. However, where they do priority must be given to their work as part of the Nexus Integration Team. This is to ensure that the work to resolve issues that affect many teams takes priority.
Why do you need a Nexus Integration Team?
They make sure if the processes are followed and truly work as servant leaders to ensure that the teams flourish. The teams confirm relentless improvement with activities like the refinement of the product backlog, sprint review and retrospective. It emphasizes on adapting to any changing requirements using cross-functional teams and eliminates any waste with Lean-Thinking.
Scrum teams are responsible for integrating their work with each other to produce an integrated increment regularly. If any integration issues arise, one or two team members of each scrum team meet with the integration team to find a solution.
Nexus Integration Team does not act as a separate scrum team or a management group. If the situation of the scrum teams gets out of hand and if there is a need, then it can become a scrum team to bring matters into order. Their main purpose is to remain servant leaders and coaches for their scrum teams.
The Nexus Integration Team will take ownership of integration issues. However, they may not necessarily do the work required to resolve these when they occur. They may work with 1 or more Scrum Teams to help them resolve issues around integration. At other times they may deliver tools and technology to help make integration run more painlessly.
About Kendis
Digital boards to manage dependencies, multiple teams and program increments for scaling agile initiatives. Kendis works on top of JIRA and other agile tools, your teams can keep on working with their existing JIRA boards and program level and above is planned and managed at Kendis.
Try out 30 days free trial or book a demo with our product expert.
Nexus is a simple framework which implements scrum at scale across multiple teams to deliver a single integrated product. It can be applied to 3-9…
Nexus is a simple framework which implements scrum at scale across multiple teams to deliver a single integrated product. It can be applied to 3-9 scrum teams which are focused on producing a combined increment in every sprint.
Sprint Planning in Nexus
The sprint planning session has two parts.
In the first part, the Nexus Team conducts a sprint planning session in which they plan the bigger picture of the project. Information and decisions made based are conveyed to the scrum teams. Dependencies are found and sought out. The backlog can have stories, tasks, business initiatives, epics or any item of any size that suits the teams.
For the second part, scrum teams have their individual sprint backlog to work on. During these sprint planning session, teams interact and collaborate with each other. Teams align themselves in order to achieve their sprint goals. At the completion of all teams sprint backlog planning, Nexus Sprint Backlog is ready.
The Nexus Team and the Scrum Teams work in cadence. The teams pick out items from the refined Nexus Product Backlog.
Items in the product backlog are continually refined to minimize or clear away dependencies. New requirements can also be added. It also includes carrying out relevant estimates of story points.
The product owner has the Nexus Product Backlog but if the size of the teams exceeds, then the product owner may delegate some of their tasks to the scrum teams, business analysts, project managers or other roles.
How does this Planning compare to that of Scrum?
In sprint planning you plan what needs to be delivered in the upcoming sprint and how will work be done to achieve it to deliver in the sprint.
When it comes to planning a sprint in Scrum, here are the key events that happen:
After the review and retrospective of the previous Sprint, the Sprint Planning session is held.
It is usually kept in a place where all the teams are present. It is set at a time at which everyone can easily manage to attend.
The Product owner discusses to the development teams, what needs to be made in the product increment along with the scope and the Sprint Goal. They have to explain to the team what needs to be done or clarify on any detail of the product backlog.
The backlog is prioritized which consists of the items which need to be worked on in order to achieve the sprint goal.
The backlog is kept accessible and transparent to all.
All blockers and dependencies are identified.
The Scrum Master acts as an intermediary between the team and the product owner and clears up any problems that they the teams may have may face in understanding the requirements.
Using the metrics from the previous Sprint such as velocities and capabilities, the outcome of the sprint is forecasted and to see how confident the teams are in completing their tasks.
Once the sprint goal is decided and the items from the backlog are selected, the development team figures out how they will achieve their tasks to get their definition of done.
The team has to agree to all the items of the backlog.
Now the development teams create a strategy and mind map with how to achieve their sprint goal. Ideas are discussed on to how to deliver.
They pick out items from the product backlog which they think will help fulfill their sprint goal. The list of items selected from the product backlog that needs to be worked on in the sprint, form the Sprint Backlog.
Seeing the items in the sprint backlog, the development teams adjust themselves according to that. They self-manage themselves in a way that they know they can really achieve what they are aiming for.
Agile, Continuous Delivery, Devops, Iterative and Incremental development are the buzzwords in today’s day and age of software development. If you happen to be an…
Agile, Continuous Delivery, Devops, Iterative and Incremental development are the buzzwords in today’s day and age of software development. If you happen to be an agilist, then you know that it wasn’t an easy time before the birth of agile. In fact, agile has come a long way and has in fact paved the way for creating software that we use today.
In this article we will explore the reasons that led to the birth of Agile and how it has led to the formation of the frameworks that we are so familiar with today.
The Problem
During the 80’s and 90’s, the waterfall method was popularly used for civil and mechanical engineering projects. The waterfall model is perfect if your requirements are never going to change which makes sense as their requirements and the design remain the same for years. The same ideology was used for software development. But it never yielded the desired results.
Depending on the complexity of the solution, it would almost take three years or more, from an idea to be implemented into a working software that can be delivered to the customer. And during this time, business needs were never fully met which would lead most of the projects to get cancelled. And if there was a change in requirements that needed to be made, there was no room for accommodating this change. Since the product would take so long to make, it would eventually lose its value in the market. Although, theoretically in the waterfall model, you can shift back to the previous state. But in reality due to the scope and budget constraints, it was nearly impossible to do so.
The element of finality in the waterfall model, was one of the reasons that made it a very heavy framework. When it comes to developing software, you have to realize that developing software is different as it can never be absolute. There needs to be a lightweight method that allows adaptability and room for continuous change. There has to be a responsiveness and swiftness to any changing requirements. And lastly, it needs to be quick. It needs to be relevant with the times.
For creating software, you have to deal with a lot of ambiguities, misunderstandings and miscommunications from the business owner in order to fully translate the requirements. It takes time to clearly define the scope so that what you make is precise and to the point. You need to involve the business owners and stakeholders in such a way that you get regular feedback from them. So that you know that you are in some way or fully implementing what is needed. You need to have small processes. All of these were soon to become traits of Agile.
Nexus is a simple framework which implements scrum at scale across multiple teams to deliver a single integrated product. It can be applied to 3-9…
Nexus is a simple framework which implements scrum at scale across multiple teams to deliver a single integrated product. It can be applied to 3-9 scrum teams which are working in a common development environment and are focused on producing a combined increment every sprint with minimal dependencies.
Artifacts for Nexus Framework:
One Nexus Product Backlog for all teams
Individual Sprint Backlog of each Scrum Team
Nexus Sprint Backlog is the collection of individual Sprint Backlogs. It is the sprint plan which is helpful in viewing and highlighting dependencies between scrum teams.
The Structure of the Nexus Framework Teams
Customary roles of Product Owner, Scrum Master and self-managing and cross-functional teams. There is a single product owner that leads the complete product. They may be supported by business analysts or system engineers. Scrum masters are responsible for facilitating their respective teams only. Each cross-functional scrum team can have 3-9 members.
Nexus Team is constituted of 1-2 members from each scrum team that are responsible for planning the vision and the bigger picture of the overall product and also coordinating all the scrum teams.
Nexus Integration Team is responsible for keeping multiple teams technically and successfully integrated. Members of this team are not fixed. These team members may include coaches and trainers which ensure smooth integration and following of the cadence of the work done by the scrum teams. It is scrum team responsibility to integrate their work with each other to produce an integrated increment regularly. If any integration issues arise, one or two team members of each scrum team meet with the integration team to find a solution.
Planning in Nexus
The teams pick out items from the refined Nexus Product Backlog. The backlog can have stories, tasks, business initiatives, epics or any item of any size that suits the teams.
Items in the product backlog are continually refined to minimize or clear away dependencies. New requirements can also be added. It also includes carrying out relevant estimates of story points.
The product owner has the Nexus Product Backlog but if the size of the teams exceeds, then the product owner may delegate some of their tasks to the scrum teams, business analysts, project managers or other roles.
The sprint planning session has two parts:
In the first part, the Nexus Team conducts a sprint planning session in which they plan the bigger picture of the project. Information and decisions made based are conveyed to the scrum teams. Dependencies are found and sought out. The Nexus Team and the Scrum Teams work in cadence.
Scrum Teams have their individual sprint backlog to work on. During these sprint planning session, teams interact and collaborate with each other. Teams align themselves in order to achieve their sprint goals. At the completion of all teams sprint backlog planning, Nexus Sprint Backlog is ready.
Development in Nexus
Multiple scrum teams work in a collective working environment to produce an integrated product. Teams fuse their work with each other consistently. The Nexus Integration Team plays a healthy role to ensure that the teams stay harmonized with each other.
Nexus Daily Scrum is when the Nexus Team and the respective scrum team 1-2 members have a scrum session. The purpose of this meeting is to coordinate any challenges and dependencies of the day that all teams should be aware of. Daily scrum is held for each team separately afterward.
A Nexus Sprint Review is held at the end of the sprint in which all the scrum teams meet with the Product Owner and review the integrated increment. Scrum teams do not have their own sprint reviews. There is only one collective sprint review in which the integrated increment is the subject.
Finally, there is a Nexus Sprint Retrospective. The essence of every retrospective is to meet and identify shared challenges. The solutions are discussed by sharing ideas and how they can improve. Afterward, Nexus Team and the scrum teams have their individual retrospectives. Then there is a collective retrospective where solutions are shared with the entire nexus and the scrum teams.
(Source)
Nexus in a Nutshell
Nexus promotes value instead of expansion. It is a scaling framework that does not say that much about stakeholders. It guides the scrum teams how to prosper, and resolve coordination issues. It does not mention the restructuring of the whole organization at scale.
One cross-functional Scrum team is the prerequisite of Nexus. Possessing knowledge and having worked in a Scrum environment gives you an edge to work with Nexus. It promotes and ensures transparency, continuous integration and relentless improvement.
Having a single product and sprint backlog boasts transparency as all the teams sprint data can be easily visualized. Daily scrums enhance communication and help erase dependencies.
Working in a shared environment where work is constantly being integrated into one final product guarantees continuous integration. Teams use automation to manage any complexities. The Nexus Integration teams give the necessary support and facilitation to the teams in order to keep them in line. Thus eliminating the need of scrum of scrums meeting that is essential part of other scaling frameworks. They make sure if the processes are followed and truly work as servant leaders to ensure that the teams flourish.
For architecture, Nexus does not deny the need of an enterprise architect but remains silent on making such a role as part of the integration team. It also emphasizes on adapting to any changing requirements using cross-functional teams and eliminate any waste with Lean-Thinking. The teams confirm relentless improvement with activities like the refinement of the product backlog, sprint review and retrospective.
To improve visibility and transparency, Nexus teams need a tool that fetches real-time data from all the teams and shows a summary at a higher level using Nexus Sprint backlog. Kendis is equipped with such customizable boards that can empower Nexus teams to outperform by attaining greater visibility and transparency into Nexus Sprint backlog. Teams are able to create multiple customizable boards that fit in a variable size of the screen seamlessly for big planning and review meetings. Find out more about Kendis here.
For any guidance on Nexus, click on the link below.
Introspection to Nexus Framework - Scaled Professional Scrum
Introspection to Nexus Framework – Scaled Professional Scrum
Recently, August 2015, Agile expert and founder of scrum Ken Schwaber and Scrum.org published Nexus™ Framework. Nexus Framework is another addition to already available many Scaled Agile frameworks such as – Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DaD), Large Scale Scrum (LeSS)etc. While reading through the first version of framework document, I could think of some interesting…
