Learn about scaling Agile in our latest video! We cover the basics, challenges, and available frameworks. Subscribe for more Agile insights! #ScalingAgile #SAFe
Nexus is a simple framework which implements scrum at scale across multiple teams to deliver a single integrated product. Teams work in a common development…
Nexus is a simple framework which implements scrum at scale across multiple teams to deliver a single integrated product. Teams work in a common development environment and are focused on producing a combined increment every sprint with minimal dependencies.
It can be applied to 3-9 scrum teams. So it cannot be scaled to more than 9 teams and not more than a hundred practitioners.
In this article, you will learn from real life examples of companies like Security Software Product Company, HVAC Manufacturing Company and Asian Airline who are truly exceptional in their respective fields transform with the application of Nexus.
These issues majorly ranged from having no clarity on integrating their product into one, coordinating multiple teams and scaling difficulties. These companies understood and realized where they were lacking. With Nexus, they found the ideal solution to their problems that eventually led them to the path of success.
Security Software Product Company
This is a leading international Indian company that makes security software products. Before changing to Nexus, there was only one scrum team that was working on mobile applications. They did try scrum with one team which proved to be very effective.
But as more scrum teams were added and the focus started to shift towards API development, mobile applications and integration services, this where they felt that their work was starting to fall out of place.
These are the challenges that the company faced at the time:
A need for a better organizational structure
No prioritization of tasks that needed to be done
No cross functional teams
Teams saw the product owner as a single authority, not a part of the team
Teams were not coordinated
The presence of agile and non-agile teams were working at their own pace that hindered making an integrated product
Dependencies were not being properly visualized
Since scrum was understood by the team, they needed a framework that was minimalistic and can be easily scaled across their small teams. They hired Venkatesh Rajamani, an agile coach, who enlightened them about Nexus. Thus their journey of transformation began.
Firstly, the teams had to become cross functional. They had to be taught how to be self-organizing and self-managing. A single product backlog was formed. In this backlog all the features were ordered and prioritized. This helped paint a better picture of how the sprint will go.
As a result of effective coaching, Nexus transformed the company entirely.
Six teams worked on an integrated increment that rolled out releases after every two weeks
The sprints and increments became more coordinated
Dependencies were minimized.
Product owner had the opportunity of inspecting and adapting that insured to bring the highest value in the shortest amount of time.
Retrospectives helped identify what was wrong and frequent feedback was given.
This increased faster time to market, value and delivery
HVAC (Heating, Ventilation and Air Conditioner) Manufacturer
The international manufacturing of HVAC equipment in Germany needed to redesign more than 80 of their websites. They had to be implemented on to a new CMS (Content Management System) which would provide information to their customers, installer services and data analytics. For carrying out this task there were marketing, IT and digital agency teams.
After a year, there was no progress as the company exceeded their budget and their time limit and accompanied by the following issues:
They failed to create a differentiation amongst their brands
The teams were not producing an integrated increment. Rather they were separately focused on to fulfilling their own requirements and tried to outdo one another, which led to creating internal conflicts and disagreements
There was a weak team and organizational structure.
With these complicated issues, they hired an agile coach. Johannes Geske, an eminent business agility consultant, who is renowned for his vast knowledge of agile, worked to put the company on to the path of success. His plan was to guide the company to Nexus eventually. But he had to start from the bottom. He started off with implementing scrum to one team.
The plan was to deploy a microsite that would allow the regional marketing team to carry on with their online platform in more than 30 countries. And by the end of the third sprint, this product increment was released. During which, the scrum team got the idea of creating the proper architecture and the appropriate technology to use. Teams became more self-confident and started taking ownership of the work they did.
With the success of the first scrum team, the idea gradually spread to four scrum teams thereby implementing the Nexus Framework. There was now only one product owner, who was supported by a team of business analysts and user experience experts. They frequently met with business stakeholders to discuss requirements and welcomed any feedback that would help them improve.
A single product backlog was made which had all the prioritized features and minimized dependencies. This was updated regularly by the product owner. As a result, the teams coordinated their work with each other as compared to the situation before where they were in a constant state of competition trying to beat one another. With the Nexus Integration Meeting, progress and dependencies were discussed. The scrum teams also had their own meetings where they discussed their goals and impediments.
The Nexus Sprint Review played an essential role in collectively assessing the work done by all the teams in a sprint. This was an opportunity to relentlessly improve and adapt to any changes that were suggested.
With Johannes Geske’s excellent guidance, the company thrived. Seeing how the company’s work was scattered before, with Nexus they got a sense of direction. They knew exactly what goals to achieve and how to attain them in the shortest sustainable time. In fact, their progress and quality of work improved so much that the websites were made 3 months earlier before their deadline.
Asian Airline
In 2012, the company’s leadership felt that they needed to implement agile methodologies into their company. They felt that they needed to become more adaptive and swift to changing requirements.
They started off with having one scrum team that focused on developing the airline’s loyalty mobile application. Seeing how their productivity increased with the scrum team, more scrum teams were added. By January 2015, there were four scrum teams. These scrum teams focused on the front and back end, user experience design and testing of the mobile application.
The scrum teams were doing great on their own, but when it came to producing a single product that is where their problems began. This ranged from:
Difficulty in integrating the work of multiple teams into one
Multiple dependencies
Inability to scale the teams
They needed guidance and a solution for their existing problems. This is where they reached out to Lorenz Cheung, who is a seasoned agile coach and a professional scrum trainer based in Hong Kong. He guided the company towards the Nexus Framework. He observed that the company had an idea of how scrum worked so he used that as a foundation to build Nexus. He educated the company’s employees on the practices and ceremonies of the Nexus framework such as Nexus sprint planning, Nexus daily scrum, Nexus sprint review, Nexus retrospective and refinement.
And an integral part of the framework was the Nexus integration team that guaranteed that an integrated increment was made every time. And lastly, Nexus would allow the teams to view and remove their dependencies.
With Nexus, the four scrum teams prospered. The teams were working at their own pace and at the end of every sprint the product was being integrated into one and on time. Dependencies were being sought and removed efficiently. Product owners eagerly participated with the stakeholders and took feedback in the form of surveys. This helped them focus on continuously improving to meet their customer’s requirements.
Before Nexus the integrated increment was delivered after eight weeks. But after the implementation of Nexus, the deliverable was made after every two to four weeks. Their rate of release became stable and consistent and by accepting feedback earlier, they were quick to change according to their requirements.
The resources have been obtained from Scrum.org
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.
We would like to extend our gratitude to Scrum.org, for giving their valuable feedback on our previous article about transforming to Nexus. In this blog,…
We would like to extend our gratitude to Scrum.org, for giving their valuable feedback on our previous article about transforming to Nexus. In this blog, we describe the transformation of notable companies, that have been requested and suggested by Scrum.org, to the Nexus framework.
The companies that have been included in this article are KLM Royal Dutch Airlines, Cathay Pacific, Net Health and Terminales Portuarios Peruanos. These issues majorly ranged from having no clarity on integrating their product into one, coordinating multiple teams and scaling difficulties. These companies understood and realized where they were lacking. With Nexus, they found the ideal solution to their problems that eventually led them to the path of success.
KLM Royal Dutch Airlines
KLM Royal Dutch Airlines is one of the oldest airlines in the world. Founded in 1916, the airline company employs 32000 employees generating € 10 billion yearly.
In 2014, new programs were launched under the newly appointed CEO, Pieter Elbers which were focused on making the company extremely customer-centric. These programs included, Customer Experience, High-Performance Organization, Operational Excellence and Digital Transformation.
They were already using Scrum. But problems started to arise when:
The backlog was not being prioritized
They were not quick to resolve impediments
The people were resistant to the idea of changing their current culture
They were having difficulties scaling to multiple teams
In 2016, Nana Abban, an agile coach from the South African Company Akaditi and a member of the Engagement Manager community of Scrum.org, was selected by KLM to help them with their persisting problems.
A workshop was held in which teams were taught how to prioritize their tasks. But seeing how the requirements and the set up of the company was, they needed Digital Studio. Digital Studio evolved from both Scrum and the Nexus Framework. This is useful for coordinating across a large organization with ease. Scrum Studio focuses on creating highly functional teams that are focused on their tasks and openly communicate with each other.
With Scrum Studio, the Digital Transformation program was a home run. Their performance boosted in operational performance, ability to innovate, time to market and customer experience. They also formed new partnerships with Apple and IBM in creating new applications that were used at the airports.
With the Scrum Studio, the company continues to grow and expands into new ventures like, Virtual Reality and Artificial Intelligence and Blockchain.
Cathay Pacific Airlines
Cathay Pacific is a highly-reputed Hong Kong based airline that flies to over 200 destinations around the world. It is also the member of the Swire Group and is listed as a public company on the Hong Kong Stock Exchange.
In 2015, the IT Team at Cathay Pacific had to launch their new Internet Booking Engine. They needed a framework that would help them deliver in the shortest time possible with the highest quality. The company was using waterfall with some elements of scrum which was creating challenges for them. These are listed as follows:
Failing to make an integrated increment.
Not delivering the product on time
There was a lot of rework being done
The teams were not coordinated and did not have a solid vision
In February 2017, with the help of Scrum co-creator Ken Schwaber, the company was bound to transform to Nexus. But to get there, they needed to strengthen themselves by building a strong understanding and foundation of Scrum.
Three cross-functional Scrum teams were made. These teams had a mix of UI, UX and front end developers and a separate team for back end development.
After two months of having implemented Nexus, Cathay Pacific was on the verge of coming on top of their game. Previously, they were releasing their product increment once a month. But with Nexus, they started to release two to three times in a single month thus increasing their frequency of releasing increments increased by 200%.
The Nexus Integration Team ensured that an integrated increment was delivered which helped in maintaining the focus of the teams on to their vision thus improving their quality. DevOps was gradually introduced to boost the development and delivery of their processes. The Product Owner also started to attain visibility into the teams’ work.
Ken Kwan, the IT lead at Cathay Pacific, says that Nexus is an extremely lightweight and minimalistic framework which was easily implemented.
Net Health
Net Health specializes in software solutions for out-patient care and dutifully serves 98% of the largest hospital chains in the USA. It has its head office in Pittsburgh and three regional offices present in Altoona, Jacksonville and Brentwood with a workforce of 300 employees. They have four departments of Software Development, Quality Assurance, Program Management and Product Management.
In 2014, the company first adopted Scrum. But with time and taking up huge projects, the company was having difficulties working with scrum as they were struggling with:
Breaking out of silos
Integrating work of multiple teams into one
Ineffective communication amongst teams
Failing to scale to multiple teams
Failing to manage dependencies
The absence of a single product owner
The Nexus Framework was discovered by one of the Scrum Masters at Net Health and it promised the solution to all of their problems. They chose Nexus because the teams were familiar with scrum already and liked the fact that Nexus focused a lot on self-organization.
After having implemented Nexus, there were five scrum teams that delivered three integrated increments at the end of every sprint. The teams started to communicate more frequently with each other as a way to break out of their silos to reach out and help their team members.
With Nexus, they found a way of how to deliver quicker and with optimum quality. They had regular inspect and adapt sessions that was necessary for relentless improvement.
Terminales Portuarios Peruanos
Terminales Portuarios Peruanos is a company in Lima, Peru that provides services for maritime, port and warehousing activities.
It was struggling to align its business objectives with development and to improve time to market. They were presently stuck in using a mix of Waterfall, Rational Unified Process and traditional Project Management. The problems that they had were:
The teams were not properly coordinated
The teams could not prioritize their work
Unnecessary waiting time that slowed down delivery and reduced their value.
They realized that it was time to change, and instead of having a mix of frameworks, they wanted to adopt one framework and scale that effectively.
They started off with Scrum. When scrum was understood, they naturally moved to Nexus and it did wonders for them. They found it extremely easy to adapt and simple to understand. The Product Owner played a key role in working with the business stakeholders to align the business objectives with what the users need. A single product backlog was made that had all the tasks prioritized into one.
With Nexus, sprints were timeboxed to two weeks and delivered at the end of every sprint. After one month of Nexus, the teams had their first release. There was a 300 per cent in velocity with an increase in business.
The resources have been obtained from Scrum.org
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.
PI objectives are a set of directives that are summarized to describe the technical and business elements of a goal that needs to be achieved…
PI objectives are a set of directives that are summarized to describe the technical and business elements of a goal that needs to be achieved by an agile team or an agile release train. They serve the basis of planning and aligning the outcomes of a program increment.
PI objectives help to give a clear understanding of what needs to be done. With that being said, the information described in the PI objectives is effectively communicated to business owners or stakeholders, which also educates them on what will be made and in a way that it also validates the team’s grasp on the matter.
A lot of work goes into correctly mapping the objectives out. In this article, we have broken down the process of creating smart PI objectives into three simple steps.
1. Planning your Objectives
Every agile team should have at least one PI objective to cover. But to start formulating these objectives, you need to ask yourself:
What and why do you want to achieve your goal in the PI?
How will you achieve what you want in this PI?
To answer all of these questions, you need to have a staunch understanding of the vision and the scope of your project. Teams need to possess an in-depth knowledge and an understanding of the teams, their velocities, competencies, milestones, and its dependencies. This helps in analyzing and doing relevant estimations of the upcoming stories. A time limit should be set for when the objective can be achieved.
The PI objectives should draw focus towards helping the user or the business owner implement a feature. It should be planned in such a way that you get feedback as early as possible so changes can be made in time so that it reduces costs and risks in the future.
2. Creation of your Objectives
Once the planning is done, these PI objectives need to be summarized down into statements that address both the technical and the business aspect of what needs to be done.
The information presented in these statements needs to be specific, clear and concise. A good practice to ensure that the objectives are correct is to apply SMART rules. SMART is abbreviated as Specific and Measurable, Attainable, Relevant and Time-Bound. Their rules are described as follows:
Specific and Measurable – They need to be supported by reasonable estimation thereby distinctly describing or quantifying what needs to be achieved. Feedback from stakeholders is important to guarantee success.
Attainable – It should be realistic, free of any ambiguity and should explain the matter as explicitly as possible.
Relevant – The PI objectives need to be aligned with the vision and the product backlog.
Time-Bound – Set a time limit to achieve the objective.
An Example of an unclear objective:
Improve Performance.
An Example of a Clear Objective:
Increase page load time by x% so the customers experience less frustration.
3. Assigning Business Value
With the PI objectives made, the final step is to get a business value assigned. This is assigned by business owners during the PI planning session. Business owners assign a value from 1 being the lowest, to 10 being the highest. These values determine the priority or the severity with which the objectives need to be done.
Having PI objectives give direction to your project. It enhances transparency and visibility into the entire project by coordinating everyone to the same mission. Not all of the PI objectives are completed in a program increment.
The objectives that are not met in a program increment, are re-evaluated from where they are either removed or moved up the backlog for the upcoming program increment. This not only reduces excess WIP but also ensures continuous improvement.
About Kendis
You can create custom or team PI objectives in Kendis that will help you in aligning and coordinating all the goals that your agile teams wish to achieve.
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 our 30 days free trial or book a demo with our product expert.
What is an Enterprise Architect? An enterprise architect lays down the foundation of the program portfolio.They guide the direction towards strategic, technical and adaptable design.…
