#scrum.org

There are many ways in which taking a Professional Scrum Master (PSM) course can help an individual grow and succeed in their careers and lives. Participation in this course has many advantages, including:

To better understand the Scrum framework, the PSM course introduces the fundamentals of Scrum as well as its history, evolution, and key components. Anyone interested in learning more about the Scrum framework and how it can be used to tackle difficult problems and produce high-quality results should enrol in this training.

Expertise enhancement

The Professional Scrum Master (PSM) course is geared towards assisting participants in becoming fully versed in Scrum and its principles and practises, allowing them to effectively implement them in their daily work. Individuals can enhance their professional skills, manage projects more efficiently, and provide customers with better goods and services by taking this course and learning to use Scrum.

Scrum is a team-based approach that places a strong emphasis on collaboration and communication; the PSM course can help individuals understand how to work together more effectively as a team, which is one of the main benefits of using Scrum. The participants of this course will gain the knowledge and skills necessary to create a productive team environment, encourage teamwork and open lines of communication, and triumph over typical problems that arise in the workplace.

Earning potential

Gaining the PSM certification shows that you have the knowledge and skills necessary to use Scrum effectively, which can help you advance in your career. By taking a PSM course and passing the associated certification exam, students can boost their earning potential, broaden their employment options, and stand out in today's competitive job market.

Individuals and teams can improve project outcomes by adopting the Scrum framework and putting its principles and practises to work. Individuals can learn how to use Scrum for project management, risk identification and mitigation, and overall product quality improvement by enrolling in a PSM course.

Summarize

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.

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.

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.

Online Nexus Guide

AKA Worrying interpretations of Scrum, pt.2 - This week I had the pleasure to facilitate two days of learning. One day was all about working towards the Scrum.org PSMI certification with a Dash of Scrum (master) practice. The other was more about Scrum & Agile basics.

Then as I was skimming through linkedin today, I saw an interesting link: Top Answers to Agile Interview Questions

Curious as I am, I clicked the link to read and hopefully learn from seeing examples of good agile themed interview questions (for example when looking for scrum masters, product owners, etc).

Then it happened. Upon reading the questions and answers, I got sad. Maybe even a little mad. I was hoping for practical tools and ideas for interview questions, where the interviewee can truly flex their Agile mindset by discussing Scrum situations from practice. But sadly the page comprised of a long list of ‘basic’ and  ‘advanced’ questions and answers of facts. And I believe that you shouldn’t ask lots of theoretical questions in interviews, but rather invest in finding someone with the right mindset, who understands the underlying principles and ideas behind Agile and Scrum.

But that is not the worst part. Having another take on Scrum theory can be a great tool to refresh. But only if the contents are correct. And as you might guess, they were not quite. Let’s look at an example of an ‘advanced’(??) interview question:

Unwritten futures will unfold (adventures in Scrum)

At some occasions we stop to look back. It happens rather irregularly in my life, although regularly in Scrum.We see the trail we left behind. We notice landmarks, missed chances, forgotten events, achievements. Small or big. We cherish that we cannot undo it. And we look ahead of us, and think of the paths we might create moving forward understanding that our current actions continually…

Scaled Scrum is still Scrum

I spent the last week of April in Karlsruhe, Germany with the wonderful and talented Scrum.org community. During that time, we worked through The Nexus Framework as part of the new Scaled Professional Scrumtraining. It was a come-together of some of the world’s leading agile thinkers, reviewing Scrum.org’s approach to the challenge of “scaling Scrum”. It was a profound experience I am grateful…