Agile Gnostic

Introspection to Lean, Agile, DevOps and Project Management !

Monthly Archives: August 2015

Introspection to Nexus Framework – Scaled Professional Scrum


Nexus

Recently, August 2015, Agile expert and founder of Scrum Ken Schwaber and Scrum.org published Nexus™ Framework. Nexus Framework is another addition to already available many Scaled Agile frameworks such as – Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DaD), Large Scale Scrum (LeSS) etc. While reading through the first version of framework document, I could think of some interesting aspects to it and thought to share my views. Before diving into what’s good and what’s ambiguous in this Framework, let me highlight some key aspects and changes from the Scrum Framework. You can read original document in details, which is available on Scrum.org website; here I summarized it very briefly –

Framework in Nutshell…

  1. It’s based on Scrum Framework’s building block for scaled software product development.
  2. ‘Nexus’ signify the unit of development in Scaled Professional Scrum.
  3. Framework scales to 3 to 9 Scrum Teams and a Nexus Integration Team working on single product’s development.
  4. A framework based on philosophy to reduce dependencies among multiple teams that are caused due to – a) overlapping requirements and it’s manner of implementation, b) team members’ functional and technical domain knowledge, and c) shared codebase and test suites artifacts.
  5. By organizing the team structure, roles, events, artifacts and techniques; framework reduces inter-teams dependencies and increases inter-operations to optimize productivity for delivering Integrated Increment at the end of each sprint.
  6. New role introduced – Nexus Integration Team, which consist of Product Owner, Scrum Master, and Nexus Integration Team Members. This team is accountable to Integration Increment and have main functions to coordinate, coach and supervise the application of Nexus and operations of Scrum.
  7. The framework describes having single Product Owner accountable to define, order and refine single Product Backlog so that maximum value is derived from Integration Increment.
  8. Scrum Master in Nexus Integration Team is responsible for enacting Nexus Framework and she can be part of another Scrum Team partially.
  9. Nexus Integration Team Members are skilled in implementing tools and practices of software engineering, who should coach and guide Scrum Teams on development, infrastructural, or architectural standards. These team members can also be part of other Scrum Teams partially.
  10. New artifacts introduced – Nexus Sprint Backlog, Nexus Goal, and Integrated Increments. Single Product Backlog is maintained for entire Nexus, which is owned by Product Owner.
  11. Nexus Sprint Backlog is composite of all individual teams’ Sprint Backlogs; maintained and updated daily during Nexus Daily Scrum. The purpose is to increase transparency and highlight dependencies and help monitor the flow of work from a single artifact.
  12. Nexus Goal is the sum of all Sprint Goals of individual Sprint Teams in Nexus.
  13. Integrated Increment represents the integrated work completed by Sprint Teams in Nexus, which should meet Definition of Done and should be potentially releasable.
  14. Four new events introduced – Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review, and Nexus Sprint Retrospectives; which extends the existing events Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective meetings.
  15. Lead by Product Owner, Nexus Sprint Planning is held along with representatives from all Scrum Teams to review and validate the refined backlog items; make adjustments to backlog items and resolves cross-team dependencies. The outcome is single Nexus Product Backlog with formulated Nexus Goal and purpose for each Sprint Teams for the given sprint.
  16. All teams’ representatives together hold Nexus Daily Scrum event to identify any integration issues or newly discovered cross-teams dependencies and any other constraints impeding Integration Increment’s consistent delivery. Resolution works identified are taken back to specific team’s Daily Scrum for planning and actions.
  17. Joint Nexus Sprint Review is conducted after every sprint to inspect and review Integrated Increment along with Product Owner and Product Backlog are updated.
  18. All teams’ representatives together hold Nexus Sprint Retrospective to identify shared challenges impacting cross-team functions to make it transparent. Follow-up actions to address these issues are formulated during individual teams’ Sprint Retrospectives and then jointly make a final call to adapt and track identified actions.
  19. Product Backlog Refinements are done at many levels for – granular decomposition of backlog items, remove or reduce dependencies, prioritize, sequence and allocate them to teams who can deliver in upcoming sprints.
  20. The Nexus Integration Team is responsible for defining ‘Definition of Done’ for Integrated Increment and ensuring adherence among Sprint Teams.

What I liked…

Some of the important aspects that make this framework more relevant and adaptable.

  • Simplicity – the framework model has been kept very simple without any complication, which would be very easy to adapt to a Scrum practicing team.
  • High level of transparency, communication and collaboration achieved through multiple Nexus events, artifacts and roles. Up to date Nexus artifacts improves transparency alignment, and decision making to minimize risks and maximize value delivery.
  • The framework enables various teams’ alignment to common program/project level vision and goal. Having Nexus Goal, Nexus Product Backlog helps achieve this purpose.
  • New roles, artifacts, and events inherit their purpose and intent attributes correspondingly from Scrum.
  • Not having too many new roles – In spite of scaled level, the framework does not stress upon having any specific need for management roles and a leadership hierarchy. Many scaled frameworks (like SAFe) introduced too many roles, layers, and hierarchy. The organization may define roles and position as required or can keep Nexus structure simple to the inherent spirit of Agile Scrum on self-organizing teams.
  • A lot of emphases given to resolve inter-teams dependencies and interoperability to produce single aggregated Integration Increment ready to release and deployment.
  • Backing from Ken Schwaber and Scrum.org team. Base Scaled Professional Scrum already in practice.

What’s missing and ambiguous…?

The framework does not clarify on the following aspects whose importance cannot be under-valued in a large scale Agile teams setup. These points are debatable and with all due respect, I would like to highlight them here.

  • The framework does not clarify on Nexus performance evaluation, program/project execution assessment, program level velocity, release planning and delivery cadence etc.
  • How the key roles like Architects, UX, System Teams, Quality Analysts, Integration, Operations etc. should be organized. Ideally, these roles should form part of Nexus Integration Team, but the framework does not clearly specify this.
  • With so many Nexus level events, Framework does not specify how these events should be conducted effectively in case of distributed teams who are working from different geographical locations and multiple time-zones.
  • Single Product Owner for the entire Nexus Scrum Teams setup would be highly loaded and alone might not be able to do justice. There should be subordinate Product Owners associated with each Scrum Teams, who can represent teams in Nexus Integration Team.
  • Even the synchronization of large Product Backlog, individual teams’ Sprint Backlogs, Nexus Sprint Backlog and updating them might be overhead to a single Product Owner.
  • Framework talks about refining the Product Backlog items to a thinly sliced piece of functionality and also identify early which team would do that piece of work. It’s quite ambiguous, if teams are organized based on product Features then during the Nexus Sprint Planning, teams should be able to collaboratively select their own backlog items to work as required.
  • Usually integrating and testing working software available from Scrum Teams after each sprints requires significant time and effort. Backed by extensive automation, Nexus Integration Team would be able to perform and overcome integration challenges to great extent. But, framework does not explain when and how the Integration Increment should be available for Nexus Sprint Review, usually it would be challenge to make it available immediately on completion of every sprints. SAFe recommends review of Program Increments with a gap of one-two weeks delivered after each two weeks iterations.
  • Not much resources and information available on Nexus and Scaled Professional Scrum, Framework is at very preliminary stage.

Key Take Away…

More or less Nexus Framework appears to be alike Scrum-of-scrums where significant prevailing practices have been considered and bundled into framework with defined roles, events, artifacts and rules. It’s more than old-wine in new bottle with new branding and packaging . With already available many scaled frameworks; only time will tell its actual industry acceptance and adaption. It also depends on how this framework is refined and advocated to better suitability and application in software development.

%d bloggers like this: