Ā Kendis empowers you with the right tools to plan, track and manage your scaled agile portfolio, programs and teams. By instilling collaboration, innovation and feedback at the roots of its operation, Kendis makes project management an effortless task. It provides visibility in planning, managing and alignment of the agile teams towards a common vision. By using the Program Increment in Kendis, you can manage Agile Release Trains. Solution Trains and architecture runways can be seamlessly managed in Kendis. It provides you with the analytics that intelligently predict the quality of planning, feature completion rate and delay impacts. Kendis integrates with existing ALM platforms like JIRA, TFS and Yodiz. Itās a complete solution for an enterpriseās agile scaling needs.Ā
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.
What is a Solution Train? The Solution Level is where large solutions are built with the collaboration from multiple Agile Release Trains which may haveā¦
What is a Solution Train?
The Solution Level is where large solutions are built with the collaboration from multiple Agile Release Trains which may have thousands of practitioners.
Solution train builds complex solutions with a Lean-Agile approach. It organizes and coordinates multiple Agile Release Trains into one, guiding the focus of hundreds or even thousands of individuals towards achieving a common mission.
A solution train starts like a conventional SAFe Program Increment Planning session. But instead of having Agile Teams that become a part of the Agile Release Train, there are Agile Release Trains that participate. It consists of different roles such as:
Solution Train Engineer
Solution Management
Solution Architect
Release Management
System team
The teams are arranged and organized in order to achieve their business objectives by considering the business constraints and staying within the set budget. Part or the whole of the solution can be delivered in an iteration anytime. The artifacts of the solution train are:
Vision
Roadmap
Milestones
Releases
Value Stream Epics
Value Stream Kanban
Value Stream Backlog
At the end of every iteration, there is a solution demo. This is where everything that has been done is demonstrated to the stakeholders or product owners and feedback is received. It is used to evaluate the integrated solution that has been created by the Agile Release Trains in the Solution Train.
Problems faced by a Solution Train
Complex solutions often need appropriate vision, thorough analysis, design, architecture, execution and most importantly āSingle place for tracking their progressā. According to our recent study, Solution Train Engineers face these challenges.
An absence of a single simplified view to answer stakeholder queries about solution progress and risks
Due to complexity and a lack of visibility, Solution Team is unable to recognize a problem as soon as it arises.
Complex or larger enterprises have more than one Release Train at any given time. These Release Trains are often dependent on each other over the same time span. They involve multiple agile teams, suppliers and shared resources that are often split geographically affecting time to market.
Coordinating the dependencies on a high level is very difficult to maintain as it is the teams on the lower level that provide the key information on dependencies.
Solution Board
A Solution Board keeps all of the aspects of the Solution Level and its challenges, mentioned above, in mind to offer the best view across multiple Product Areas or Release Trains. This will assist managers to coordinate the delivery and ensure the value is provided incrementally. The Solution Board provides you with the following features:
All in one view for all of your release trains.
Aligns multiple and or remote Release Trains and brings them on to one page by adjusting their focus on to one common vision.
Mapping dependencies amongst multiple and or remote Release Trains
The Solution Board replicates Cadence and synchronization which keep all the objectives and the routine for the Agile Release Trains to follow.
Allows involvement of customers and stakeholders to provide their feedback.
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.
What is a Gantt Chart? Gantt Charts are an effective tool for planning, tracking and viewing the progress of any project. It visually presents allā¦
What is a Gantt Chart?
Gantt Charts are an effective tool for planning, tracking and viewing the progress of any project. It visually presents all the information about the various tasks or phases of the project, their schedule and how they are related with each other. Gantt charts can also be helpful for research and design purposes.
The idea behind Gantt charts goes way back to 1896. Karol Adamiecki, a Polish engineer, intrigued with project management, wanted a way to visualize the progress of the work done. He Ā created something similar to the Gantt chart at the time and it was known as the Harmonogram.
It was widely popularized in Russian and Polish articles. But it did not gain much recognition in the English speaking countries. Until 14 years later in 1910, Henry Gantt created his own version of the charts which were liked by the people, thus the charts were named after their creator.
How does it display information?
In the Gantt chart, the information is displayed on a chart that has horizontal bars. Different colors of the bars show different phases of the project. Length of the bar within a bar shows percentage completion. The time is displayed on the x axis and the tasks or subtasks on the y axis. The starting and ending dates of the entire project are set on the chart.
The Gantt chart consists of the following elements:
Milestones ā Marks the end of a task, sub task or any work item of the project
Dependencies ā Represented as arrows on the chart which tell that which task is dependent on what in order to complete.
Tasks ā An element of work that needs to be completed.
Sub Task ā A part of the original task that links to the overall completion of the major task.
Task Progress ā Represents how far each task has progressed visually in the form of a bar the completion of a task.
How can Gantt Charts be Made?
Gantt charts can be made physically and virtually. Although making them physically is quite a laborious task, software really smoothens the entire process. Making Gantt Charts in real time involves a lot of magnetic puzzle like blocks that have to be joined together.
Gantt charts were previously made laboriously by hand. Large puzzle pieces and strips of paper are placed on to a board to determine the progress and milestones. Using excel sheets also added some simplicity to creating Gantt Charts. But there is still a void as it does not completely cater to dealing with the drudgery of making the charts.
Who can use it?
Gantt chart is commonly used by individuals who are project managers, team leaders, CEOs, CTOs and so on.
Conclusion
Gantt Charts give an insight of how the teams are performing. They provide an instant view of the project timeline. It tells you which team is on schedule and which team is lacking behind, thus allowing you to change accordingly. It displays which resources are being used for each task.
Importance of risks cannot be emphasized enough. They can not only affect your progress but can also be a serious threat to your companyās repute,ā¦
Importance of risks cannot be emphasized enough. They can not only affect your progress but can also be a serious threat to your companyās repute, if not identified and mitigated properly. As more and more companies are advancing with agile, larger companies need effective risk management so they can tackle them before time.
Risk management has become an essential part of any companyās planning method. In this article, we will discuss the techniques used in scrum to manage risks.
Scrum is probably the most popular and common framework implemented in agile software development. The reason for its wide use is because it is lightweight, simple to use and produces large outcomes. It can be easily scaled to cater small or large teams that may consist of hundreds or even thousands of practitioners.
Many complain that there is no set method of tackling and handling risks when in fact scrum is all about handling risks. As the co-creator of Scrum, Ken Schwaber says:
āScrum is a way of controlling risk.ā
Every project has a different set of requirements. Ken suggests embracing the true essence of agile that is having an innovative and a colorful approach for dealing with risks. But we have gathered some ways in which risks can be reduced to some extent. Ā To understand how risks can be mitigated, we need to explore the reasons why risks exist in the first place. The causes are listed below:
Incomplete requirements
Lack of communication. Teams and Users are not involved
Incomplete effort
Unrealistic expectations
No planning at the organizational level and project level
No commitment to the combined goal
Complicated architecture
In Scrum, all of these issues are addressed above, can be set into three categories of risks. Ā Along with these categories, you will also know how these risks can be subdued.
What is an OKR? OKR (Objectives and Key Results) is a simple management and planning method that helps organizations define and accomplish their goals. Itā¦
What is an OKR?
OKR (Objectives and Key Results) is a simple management and planning method that helps organizations define and accomplish their goals. It is a framework that helps in achieving tasks in the shortest time possible by coordinating the teams and their leaders on to one direction to obtain their goals.
How did it come about?
This framework originated in the 1970ās. But it was promoted by John Doerr during his time at Google. It wasnāt until the idea spread through out Silicon Valley that major companies like LinkedIn, Twitter, Spotify and AirBnB started following the same method. Ā OKR was not just meant for tech companies to embrace but many companies like Walmart, Target, The Guardian and ING Bank have also followed suit.
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. 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.
Scaled Agile Framework (SAFe) has helped enterprises get a home run every time with its application. Regardless of the companyās domain, with the application ofā¦
Scaled Agile Framework (SAFe) has helped enterprises get a home run every time with its application. Regardless of the companyās domain, with the application of SAFe surely you are set on the path to success.
In this article, you will learn from real-life examples of companies like Standard Bank, Intel and Sony Playstation Network who are truly exceptional in their respective fields, achieved great status with this transformation.
These issues majorly ranged from having no clarity on agile methodologies, coordinating multiple teams and scaling difficulties. These companies understood and realized where they were lacking and with SAFe, they not only found the ideal solution to their problems that were eventually catapulted to success.
Standard Bank
Being in existence for more than 150 years, and with assets of worth $143 billion dollars, it is considered South Africaās premier bank.
To stay competitively ahead, each year the IT team at Standard Bank sets on doing 600 projects. But due to budget and time constraints, most of the projects were not completed.
The problems that they faced were:
Difficulties in scaling and coordinating their 2000 IT systems. This affected quality, their responsiveness to market and their overall sustainability.
Weak team structures.
Lacking a solid vision.
True ownership of the work done.
A change of the culture in the work.
Waterfall and other Lean-Agile Methodologies were tried but they failed to completely confront the problems they were currently enduring. Fortunately, SAFe presented the solution and addressed all the problems that they were facing. It promised a new structure which allowed everything to be easily scaled that would help them build better portfolios, programs, and teams.
The first PI was scheduled in January 2017. Two individuals from Standard Bank attended the SAFe Program Consultant Program and from there they expeditiously trained their employees. From July 2016 till February 2017, more than 1000 employees were trained to SAFe. They were transitioning into a new business model that greatly improved their work.
Cross functional teams were made that were organized into a cadence. Work was broken down into small chunks, being prioritized in the backlog that was delivered in sprints. DevOps and automation were introduced. Frequent feedback was given by IT stakeholders.
In their first PI, Standard bankās productivity increased by 50% with more than 2000 employees trained on SAFe. Dependencies had become visible which allowed better management. Since transparency was made better, the teams had insight into the entire strategic plan which helped reduce the complexity. Productivity increased by 50 percent while deployments increased to twice a year and cost reduced by 77 percent.
Teams were interacting more with each other with higher energy which produced better ideas. Communication significantly enhanced amongst senior and junior employees. Employees started to dress more casually rather than wearing suits. SAFe had in fact kick ushered in a fresh approach; a new way to perceive how things were meant to be done.
Intel
Intel. A company that has been synonymous with hardware and technology for long as anyone can remember. According to Forbes, as reported in June 2018, Intel had sales of $64 billion. It employs 100,000 globally every year and is geared towards continuously innovating and expanding. With a company of this magnitude, they have had their share of difficulties such as:
Processes were not defined
Difficulties in scaling and coordinating growing teams
Strict management that was more about dictating what needs to be done
Weak team structure
Lack of a learning environment
They sought to apply agile methodologies to improve their organizational structure.
The Manufacturing Development Organization (MDO) is responsible for releasing over 2 million lines of code every two weeks which needs to be validated. And given their current strict mode of management system, a change was definitely needed.
In 2005, Lean-Agile methodologies were introduced and with time till 2012 they had made their own recipe for Agile having a mix of various methodologies. This homemade solution was starting to create difficulties in scaling as the MDO was growing. This is where SAFe donned upon them.
A year later in 2013, MDO discovered how SAFe can tackle the problems that they faced. Ā SAFe showed how it can improve their companyās structure with properly defining their roles that would help execute processes efficiently, building an environment of constant learning and proper planning.
The journey of shifting to SAFe began when a team of 15 individuals attended SAFeās Program Consultant Certification training session. In this session, the employees from Intel learned about role mapping, principles and practices of SAFe.
Under their leadership, more than 1500 people were trained within 8 weeks for the first Agile Release Train (ART). This ART had 170 scrum teams which were fully cross-functional and committed to achieving their goals.
Cadence and synchronization helped coordinate and keep all the tasks in a rhythm in the ART. Intel had a digitized program board that allowed the teams to see all the work that was being done. Issues were now clearly identified that also enhanced transparency. The environment of the workplace changed. Rather than having tasks dictated, the teams communicated more and became conscious about helping their team members.
With SAFe, the teams were quick to adapt to change. In 2017, a new group called Manufacturing Value Engineering was formed that doubled the size of the organization. 2000 were added to 440 scrum teams into 35 ARTs Agile Release Train. This group managed to successfully deliver 65% more product variants in a year.
Sony PlayStation Network
Sony PlayStation Network is one of the pioneers of modern console gaming. It has been in existence for more than 20 years with 150 million active users globally and an integral part of every childās life growing up in the 90s.
Similar to the companies mentioned in this article, Sony at the time faced the following issues:
Poor coordination and alignment of teams. There were more than a 1000 team members that were spread across 8 different cities from Tokyo to San Diego. This resulted in not being able to roll out releases on time.
Struggling to map the dependencies
Failing to prioritize the features
Inability to scale
Waterfall and scrum were tried but ended in failure. Managing remote teams still persisted. Finally, in 2014, SAFe was unearthed. It had all the answers they needed for their enterprise. It showed the way for a greater organizational structure and clear dependency mapping.
So in February 2014, the first Agile Release Train departed followed by another after every two weeks. The roles of Program managers changed to Release Train Engineers. Feedback and demos became more frequent. Not to forget, managing teams became effortless. Their open communication and coordination significantly boosted results. Dependencies had now become clear and transparent to all which improved predictability.
More value was being delivered with 700 members that were spread across 60 scrum teams and 6 ARTs. Sony PlayStation network hugely benefited from this transition as they saved $30 million in one year.
Conclusion
Making a transformation takes time, proper guidance and patience.
Agile is centered at the roots of an organization. No matter how big or small, the foundation for agile should be strong to support its methodologies. So having clarity on how everything is meant to behave and work in agile is extremely important.
Agile coaches play a mammoth role in bringing about a change. The experiences shared by agile coaches are an excellent source for the employees to learn and relate from. Their services can be easily tailored around an enterprise to suit the companyās requirements. They help unlock the true potential of a company to attain peak performance.
And lastly, coupled with steadfastness and perseverance, the entire process of a companyās transition can be made smooth.
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.
āEverything is a learning process: any time you fall over, itās just teaching you to stand up the next time.ā ā Joel Edgerton Understanding andā¦
āEverything is a learning process: any time you fall over, itās just teaching you to stand up the next time.ā ā Joel Edgerton
Understanding and embracing this learning process is the ultimate key to success. Success is in fact at the end of a very long and twisted road which is loaded with challenges. And with every hurdle you face, lies an opportunity to truly push yourself beyond your limit to learn and grow.
In this article, you will learn from real life examples of giant companies like Huawei, BMW and John Deere who are truly exceptional in their respective fields. But had to truly struggle and had to endure enormous challenges in their organizations to get to where they are now.
These issues majorly ranged from having no clarity on agile methodologies, incomplete team structures and scaling difficulties. For solving these problems, these companies implemented Large Scale Scrum (LeSS) that not only transformed their way of working but brought a shift to the mindsets of the people working.
Huawei
Huawei Technologies Co. is a Chinese multinational company that specializes in telecommunications and network equipment, consumer electronics and services. It is based in Shenzhen, Guangdong, South China. According to IDC, Huawei has become the second largest smartphone maker behind Samsung. It has also become the worldās seventh-largest information technology company by revenue. But achieving this status took them a lot of time and a board reconstruction of their organizational structure. It wasnāt until 2016 that they embraced the agile culture purely and adopted one of its most recognizable frameworks, LeSS.
Before transitioning to the LeSS framework, Huawei was working in a traditional management style with project managers and at the same time struggling with trying an agile adoption. The problem was that they were unclear of their agile methodologies and weak team structure. This lead to issues that are described below in the list:
They tried working in iterations which eventually turned out to be mini waterfalls.
There was continuous integration where the developers thought that they integrated their code together but in reality they were just confusing it with daily build and automation.
Cross functional teams were made. Essentially these teams are meant to be self managing and self organizing. But there was no guidance on how self management was to be done. Instead, there was still a manager that would manage to achieve the goal for their teams. The team was just a mix of people in an unstable team structure with an unclear vision and weak alignment. These individuals were just focused on their respective speciality that resulted in reduced learning and adaptability and not taking a shared responsibility.
Scrum was tried but since the organization and the team structure wasnāt well defined, it did not work.
The product definition was not clearly done.
The work was scattered as there was no single backlog managed by multiple managers
Traditional program management was done instead of product management
Huawei was in dire need of guidance and restructuring. In 2015, agile coaches were hired to give proper guidance and awareness about agile to the teams.
An organization-first approach was done. This top-down adoption was done because a proper organizational structure was needed first, which will eventually pave the way for effective coaching that will solidify the concepts of LeSS.
The transition started from first defining an organizational and team structure. It was a daunting task as it challenged the power and authority of the management. Even scrum masters were baffled with the idea of having teams that were self managing without having an appointed manager. This had to be changed.
The coaching for LeSS was done in an evolutionary-increment approach. Work was arranged in programs, rather it should be organized to be product centric. Instead of just rolling out the product, the approach in LeSS dictates that product development should fulfil exactly what the customer wants. There was also a focus on improving product definition.
After a year of coaching, the concept of having a single backlog was introduced with one product owner, rather than having multiple managers with multiple backlogs. The traditional phases of development such as analysis, building and testing were replaced with one common definition of done for all requirements. All of this greatly helped Huawei escalate into the tech giant that it is today.
BMW
Bayerische Motoren Werke or Bavarian Motor Works (BMW) is a German multinational company that manufactures luxury automobiles and motorcycles. Started in 1915, it manufactured aircraft engines till 1945. And after that it shifted to producing cars and motorbikes. It has been ranked number 1 as Best German Business Brands International by Das Deutsche Markenranking in 2017 and ranked number 10 on Forbesā Worldās Best Employers List 2018.
LeSS was implemented in 2012 during the BMW iCar Project when a new Unified Sales Platform (USP) was needed to support its development. This USP had to be integrated with 30 external system interfaces that were non-agile. So to ensure uniformity and coordination across all platforms, LeSS posed an ideal solution.
The challenges BMW faced before adapting LeSS were:
Product definition was murky
Employees were not familiar with agile methodologies
Teams were not self managing or cross functional
Unclear on definition of done
No single product backlog
Considering these issues, a bottom-up approach was taken. Instead of having an organization first approach like Huawei, the BMW group went with the scrum first approach. Scrum was applied to one team. This team explored and discovered all the tools needed to set up the development environment, a system for continuous integration and defining the length of the sprints. The progress with this team showed significant difference in performance as compared to the other teams.
The other teams were still set within their traditional management style. Since requirements and priorities could change, there was still a need for a much more flexible working environment. Instead of being limited to doing one task, teams should possess the freedom to select various items from the Product Backlog to make end-to-end features.
There were multiple teams in the company, consisting of hundreds of employees. This urged a need of uniformity of the processes to be followed and coordinated across all of them. Since scrum was successful with one team, the idea was to spread it to all the teams and apply it entirely.
For transforming to LeSS, agile coaches were hired that dispensed guidance through constructive and interactive coaching workshop sessions.
These workshops would last for hours which were focused on advising and educating the employees on how LeSS works. Team building sessions were held in which team members were trained on how to share knowledge, discover impediments and ways to improve with each other.
Team vision charters were a critical part of the coaching session. Guidance was given on how to stay committed to a vision and focused on a common goal. Essence of product centric development was taught.
These workshops led the way for creating self-managing and self-organizing feature teams. And after two years, in 2014, the productivity remarkably increased. As the work became more transparent and with features properly prioritized, decision making was greatly enhanced. This also increased product predictability and reliability.
John Deere
Recognized for manufacture of its construction and agricultural machinery and being in existence for over 150 years, John Deere has been ranked as one of the Best Global Brands by Interbrand in 2018.
Similar to the weak organizational structure of Huawei, John Deere was in a serious need of a transformation. Their problems were mostly related with:
Feeble team structure
Inability to predict product delivery
Problems with maintaining quality
Multiple product owners
The transformation started by first educating the managers to become better lean leaders. During this process, there was help from senior developers and a session with Craig Larman, the co -founder of LeSS, who gave guidance on the framework. His guidance was valuable as he greatly emphasized on rebuilding the teams into being self managing and self organizing. Through team-building exercises and workshops, team members were trained on being cooperative and collaborative with each other in a team.
After six months, progress at John Deere improved considerably. The concept of having a single product owner and a backlog was introduced. With the product backlog being a single entity and the team structures being properly set, the quality and reliability of the production boosted. The essence of learning and adapting and continuously improving brought a whiff of freshness to the working environment.
Conclusion
Making a transformation takes time, proper guidance and patience.
Agile is centered at the roots of an organization. No matter how big or small, the foundation for agile should be strong to support its methodologies. So having clarity on how everything is meant to behave and work in agile is extremely important.
Agile coaches play a mammoth role in bringing about a change. The experiences shared by agile coaches are an excellent source for the employees to learn and relate from. Their services can be easily tailored around an enterprise to suit the companyās requirements. They help unlock the true potential of a company to attain peak performance.
And lastly, coupled with steadfastness and perseverance, the entire process of a companyās transition can be made smooth.
āThe beautiful thing about learning is nobody can take it away from you.ā ā B.B King
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 Disciplined Agile Delivery? Disciplined Agile Delivery (DAD) is a framework that provides context-specific guidance, that suits your enterprise needs, to produce high-quality productā¦
What is Disciplined Agile Delivery?
Disciplined Agile Delivery (DAD) is a framework that provides context-specific guidance, that suits your enterprise needs, to produce high-quality product quicker. It is a hybrid model, which is formed by a collection of the worldās proven Lean-Agile methods such as Scrum, Kanban, XP, Agile Modeling, Unified Process and many more.
How did it come about?
Agile methodologies have proved their mantle in helping companies and enterprises to achieve huge success in the least amount of time. āFail fastā is the epitome of what agile is based on as the people should make mistakes quicker in order to learn.
When it comes to developing software, scrum is an excellent choice. It is a good foundation for the majority of agile processes. But it focuses more on the construction and the development rather than the delivery. These methodologies do not, however, guide on how delivery teams should work with enterprise groups such as enterprise architecture, portfolio management, release management, operations, support, and data management. Thus the methodologies of the scrum teams conflict with the working methodologies of these other elements of the company.
This is where Disciplined Agile Delivery gives the solution. It addresses project delivery from its inception to delivering to its end users by breaking down the barriers between the development and other parts of the organization to bring everything into one single combined effort. It coordinates and aligns the scrum teams with the rest of the organization and their work so that everything remains transparent.
The Structure of the Framework
There are 3 stages of Disciplined Agile Delivery:
Inception
Construction
Transition
In order to fully understand how these three simple stages weave the disciplined agile delivery framework, you would also need to understand the four underlying life cycles that are responsible for making everything work in DAD. These life cycles act as guides to ensure that work is done in an agile way. The teams need to select which cycle suits them. This selection is usually done by the help of an agile coach who also effectively walks them through when to use the chosen cycle.
The four life cycles of development in the Disciplined Agile Delivery Model.
Agile Delivery Lifecycle: Based on Scrum, it helps in actualizing your goals into a work item list which are divided into short milestones. There is no product backlog. This cycle extends throughout the entire project.
Lean Lifecycle: A continuous stream of workflow is created that ensures that the processes are minimized and bottlenecks are reduced. Unlike Scrum where you have ceremonies like meeting daily to discuss the progress, the Lean Lifecycle suggests to meet only when necessary. This cycle extends throughout the entire project.
Continuous Lean and Agile Delivery Lifecycles: Teams deliver frequently and quickly. With timeboxed iterations and practices such as continuous integration, timely delivery is ensured. Focused mainly during the construction stage and the transition stage.
Exploratory (Lean Startup) Lifecycle: Brainstorming of new and testable solutions that upon feedback from the stakeholders become a part of the original release. This is done before the inception stage and the transition stage.
In the inception stage, the business problem is understood and a technical solution is identified. The Portfolio Management gathers the requirements and defines the features. These features are prioritized in the work item list. Thus the plan to achieve all its goals is made and the vision for the project is established. Finally, the plan is presented to the stakeholders to attain funding.
This phase should not take more than four weeks. A minimalistic approach should be applied when planning rather than confusing and disturbing your focus by giving too much attention to details.
With the plan formulated, the construction phase begins. There are cross-functional teams that are self-organizing and self-managing. They use a hybrid of agile methods such as Scrum, XP, Agile Modeling or any other agile technique that suits them for construction. All team members and their efforts are coordinated. Conventional roles of Team Lead, Product Owner, Enterprise Architect, and stakeholder exist. The project is divided into lightweight milestones to maintain focus with activities like architectural modeling, risk management, deployment, and planning. There are retrospectives, iteration reviews, and demo to stakeholders.
Transition is the final step for Disciplined Agile Delivery. It is when the solution that is made is ready for deployment. Technically, the solutions need to be extensively tested with and the stakeholders also need to be ready to accept the solution. They need to be properly guided and educated about the solution. Once you know that your solution is ready to be deployed, a strategy needs to be planned. Techniques like continuous deployment, micro deployments, toggle release, toggle release etc.
During the entire span of the Disciplined Agile Delivery, key elements as listed below support the project:
Program Management
Release Management
DevOps
Product Management
Enterprise Architecture
IT Governance
Continuous Improvement
Disciplined Agile Delivery is suitable for projects of all sizes and nature but best used for small or medium sized projects. Large projects can be made with DAD but to do so there are many challenges that you have to face such as:
Working with large teams and their geographical distribution
Technical constraints and domain limitations
Organizational distribution
Conclusion
Every enterprise is different. They have their own unique way of working. They are also constantly evolving and there as their requirements are changing, they are learning ways to adapt and evolve. With Disciplined Agile Delivery you have the freedom to adjust and tweak the framework to suit your needs. It does not have a one size fits all approach rather allows you to make choices that are relevant to your context, processes and goals.
A learning environment that is supported by the foundation of lean and agile mindset is set for the teams to work. These teams are swift to change, highly motivated and goal driven towards achieving their targets whilst knowing all the risks. They continuously explore and identify what the stakeholders need.
The teams own their processes and relentlessly improve their processes at a team and an enterprise level. There is tool learning on how to effectively use the right tools and technologies to deliver quicker as compared to a waterfall or ad hoc approach.
Overall, a discipline is instilled into the entire framework. With that being said, you need to know how to reduce the feedback cycle, deliver solutions incrementally, be goal driven, aware of the enterprise and adopt agile governance strategies.
Certification
To become a certified instructor, coach or partner for DAD, training and certifications are offered by Disciplined Agile Consortium (DAC). It is a certified body that offers training in the disciplined agile framework.
Find out more at: disciplinedagileconsortium.org
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.
When companies start to scale agile, fear looms over the company as to how they will make it happen. This fear is in the formā¦
When companies start to scale agile, fear looms over the company as to how they will make it happen. This fear is in the form of myths and speculations that often scares companies to becoming agile.
But with time and the evolution of newer technologies, agile and its processes have ceaselessly matured. Proving that the problems with scaling agile are nothing but figmental now. In this article, you will read about what the 7 myths about scaling agile are and how you should stop believing them.
1. There is no discipline in agile
Agile is highly disciplined when it comes to delivering. You have to make sure that you are consistently and continuously testing, getting feedback, shipping software on the deadlines and changing and updating the plan when needed. All of this needs hard work and coordination to achieve success. This cannot be achieved without the dedication, support and commitment from the teams and the management.
The driving force behind Trumpās election campaign was Agile, which evidently made him President. To learn more, click here.
Now that you know that agile has discipline, scaling can easily be practiced. It may seem complex but once you have a clear understanding of the core agile values and the fundamentals of this process, scaling is not a difficult task.
Tip: Agile coaches and transition experts assist companies in tailoring the process according to their specific needs.
2. Agile teams cannot Scale Up
That is not true. Countless enterprises have transformed by scaling agile to produce reliable and higher quality products. In a market where the competition is extremely fierce and where every company battling out to be the best, scaling has become quintessential.
Famous scaling frameworks like SAFe, LeSS, Spotify Agile Model and Nexus are proving to be very popular and in fact beneficial for a companyās success. The purpose of these frameworks is to guide in building a structure that lets the companies to delivering and reacting faster to any change with improved collaboration.
3. Scaling brings organizational friction and financial loss
Looking at the history of digital revolution, businesses have been often skeptical to adapting to scaling agile. And the reason for that they had to face issues in the form of organizational friction and resulted in a financial loss. But it was with perseverance and steadfastness that these businesses thrived and kept on scaling to produce phenomenal results.
The reason for their success was that these companies were good at defining company vision, analyzing their need to adopt of scaling by considering its challenges and advantages. They were ready to adjust and respond to the change that came their way.
A comprehensive study at Harvard on ING bank describes the key success factors of Agile at Scaling. It mentions that sequence of rolling out the plan is the key.
4. You need to stop working with your current ALM tool
Once agile teams start using an ALM tool that suits their preference, they become content with it. But when the business starts to expand, companies look for a tool that assists them to plan multiple releases and track work item dependencies. This is when they need an agile scaling tool that fetches data from their ALM tool, so they can utilize it efficiently to scale.
Earlier scaling tools were tightly integrated with only ALM tool that was developed by the same software provider. But now, scaling tools are very capable of integrating with the existing renowned ALM tools. So there is no need for the agile teams to switch to another tool. Hence seamlessly managing their program efficiently using a scaling tool of their choice.
5. Dependencies cannot be visualized with the tools
The higher the amount of dependencies, the higher the chances of the program becoming complex.The dependencies at the architectural design level can be described with the help of different tools. But when it comes to describing work items dependencies, then the usual solution is worksheets.
For visualising dependencies at a higher level, physical whiteboards did the job. The board would be covered with a red web spanning across the entire board mapping out the dependencies. But it was difficult to know the latest change that was made.
But now new scaling tools have made it simple for visualizing the dependencies, enabling individuals to make accurate and quicker decisions by using the latest data.
6. Program Releases have no deadlines
Quite the contrary. Agile teams work best in defined release cycles.
The release schedule of all the projects in a program are known to all the team members and the management.
Each team can push their work in a planned release. With the enhanced use of continuous integration and DevOps, each team can deliver the feature as soon it gets ready.
If there is a dependency between two team work items, then the teams still can define a way to deliver. Learn, how Spotify resolved their dependent feature releasing.
7. You do not need a program level architect
Many consider a program level architect an obsolete position. Not exactly.
In a company, the program level architect is responsible for the infrastructure, technical strategy, and the evaluation of the business needs in terms of technical stability. They create a design that keeps the long term vision in mind. The architect doesnāt necessarily enforce the design but to guides the teams in such a way that it does not disturb or alter the vision kept for the organization, even if the requirements change. A program level architect plans and synchronizes the program architecture runway with the agile team requirements and manages technical dependencies.
If the project level system experts, or architects meet to discuss the vision, system design, security, tools or platforms then the program architect may act as the scrum master.
How Kendis poses a solution to all the myths about scaling agile?
Kendis is an efficient planning tool that permits third party integration. You can plan, track and manage your program portfolio all in one place. Teams using Kendis have integrated with Jira Software, a very popular ALM tool, and are absolutely satisfied with it. Kendis provides a two way sync that gives an updated view of the teamās progress in both Kendis and Jira.
(via Complete Guide to Highly Effective Spotify Scaled Agile Teams - Simplifying agile scaling for distributed teams and programs (Agile Scaling Platform for SAFe/LeSS/Spotify))
For enterprises and companies, in this competitive market, being agile is the way forward. It proves to be very beneficial as it allows responding toā¦
For enterprises and companies, in this competitive market, being agile is the way forward. It proves to be very beneficial as it allows responding to change quickly and adjust to changing requirements. Teams create a product that is developed in iterations in less time which is better tested, delivered faster and with the lean utilization of resources.
Agile methodologies bring a wave of transformation in the mindset of the people that work in an enterprise. It enhances trust and transparency in the working environment, which breeds innovation and creativity.
In theory, this is every enterpriseās dream. But in reality, companies have to take huge steps to become agile.
In this article, we focus on the 7 key aspects that you should keep into your consideration while becoming agile. Regardless of the field of interest of your company, these tips will guide you.
