As a part of the Introduction to Scaled Agile Framework series, this article will explain “Why Industries are in Need to Adopt Scaled Agile?” –

Agile is exploding! As stated by the 15th State Of Agile Report, 94% of organizations state that their company is doing at least some work in Agile and over half of these organizations state that majority or all of their teams have adopted Agile.

Around 2010, the Agile way of working did not have this level of acceptance. In fact, there was a lot of skepticism around the Agile way of working. There used be heated debates around if there is actually any benefit in 15 minutes only “meeting” or if leaders in the real world lead by serving their teams.

Today such discussions are not very common and there seems to be a consensus within the IT industry that at least at team level, Agile way of working definitely helps.

The question then remains – if Agile is doing so well and organizations are reporting so many benefits – why do we need to scale Agile? Challenges That Persist – These are the driving factors causing companies to look at Scaled Agile

Why Industries are in Need to Adopt Scaled Agile? – Some Challenges in Single Team Agile

Even when the teams are working in Agile, there are some challenges that remain unsolved when you are working in Large Programs– These challenges are the ones which drive organizations to consider scaling Agile within their organizations

Lack of alignment with Business

In team-level Agile, there is no underlying structure which helps to  percolate the organization and/or portfolio vision down to each individual Agile Team. As a result, even when each team is operating in Agile, some of the benefits still remain elusive. Especially those that are achieved by business and IT synergy Going

Amount of Work in Progress makes a uniform way of working a necessity

The sheer amount of work being done in any organization means that there has to be a way to review and monitor all the projects. To enable objective decision making, it is critical that each project (whether Agile or not) has to share information in a uniform manner. When each team is working independently, having such an enterprise-wide working agreement becomes key to smooth operations. Organizations are looking to scale their Agile way of working in the hopes to establish these working agreements across teams.

Large Monolithic Architecture

Over the last few decades many organizations have developed a humongous piece of code that is essential to keep the organization running smoothly. Having such a monolithic architecture makes it very difficult to handle

Dependency Management

Most of the programs in a large organization require more than a single team to reach the goal in a competitive timeframe. Organizations need an established scaled agile framework to deal with complexities of multiple teams 

Sub Optimal Leverage for Specialized Roles

Many specialized skills like UX experts or Architects are not needed full time. Since these are rare to find/ niche skills, it is very inefficient to waste these skills. Also organization-wide uniformity is needed in most of these areas. Considering this, having a shared pool as a part of scaled agile way of working makes definite sense for most of the organizations

Co-Coordinating Release Windows

Since it can potentially disrupt day-to-day work, Software release is often a stressful event for any organization. When there are multiple teams working on small bits of improvements, it’s often wise to coordinate releases across multiple teams. Having a defined scaled Agile framework makes this coordination easy

The post Why Industries are in Need to Adopt Scaled Agile? appeared first on World Of Agile.

I was working for a large bank in Europe where Prince2 was already being followed. It was working alright for all waterfall projects as well as a DSDM projects (which were sort of waterfalled agile implementations!). Bank decided to later on work on Scrum and effectively implement Agile in the organization.

Sprints were executed by vendors with a shared Scrum Master roles at offshore in India and a counterpart at onsite who was also shared across teams/projects. The Main Product Owner used to be at the customer site at Amsterdam. It was customary for the Product Owner to fly down to India and work from Mumbai atleast twice or thrice a year. There usually was another Product Owner (more like a Line Product Owner) at Mumbai who used to work with the Main (Chief) Product Owner at Amsterdam.

The Prince2 structure of Steering Committee continued which was more like a Scrum of Scrum of Scrum Meeting (more like a impediment solving meeting) once every 6 weeks. This was attended by the senior management of the Bank and Vendors. I was part of this meeting every 6 weeks in a face-to-face manner either at Amsterdam or at Mumbai.

The Stage Boundary meetings continued (Scrum of Scrums) with Scrum Masters from different teams taking part in the go-no-go at domain levels. Usually this meeting was conducted at customer premises at Amsterdam unless, the customer himself was at Mumbai.

There was a separate Scrum of Scrum meeting conducted weekly. This was a impediment solving meeting where the representatives of each domains participated to voice their impediments and solve them.

The post Integrating Scrum with Prince2 Organization appeared first on World Of Agile.

Scaling the Product Owner Accountability – This article is completely updated and rewritten on 18 Jan 2024

Scrum Guide says, “The Product Owner is one person, not a committee.” However, as the Product starts to grow in size and complexity it becomes increasingly difficult for one Person to do justice to the Product Owner Accountability. Read this article to understand some ways we can scale up the Product Owner Accountability. 

As suggested by the diagram above, two important ways of Scaling the Product Owner Accountability are as below.

1. Having Multiple Team focused on the Same Product Backlog
2. Creating Smaller Independent but connected Products – also known as Value Stream Forking.

Multiple Teams focused on Same Product Backlog

In the diagram above product P1 has one product backlog and one Product Owner. Teams T1.1, T1.2 and T1.3 are working as independent Self-Managed Scrum Teams and Share the Product Backlog and the Product owner. This product Owner can then help the three scrum teams to work in a synchronized manner. However, Please do note that the three teams share a product owner. It is NOT ok to have multiple product owners for the same product backlog. You can read our article to understand why Product Owner is a Single Person and not a committee.

Some points to keep in mind when operating in such a structure are as below.

1. Avoid having multiple teams work on the Same Product backlog item at the same time. If input by multiple teams is necessary for any Product Backlog Item, consider splitting the Item so that each Scrum Team can work independntly
2. Consider having an attribute for each Product Backlog Item that indicates which team is /will be working on the same.
3.  

The post Scaling the Product Owner Accountability appeared first on World Of Agile.