As part of the Introduction to Scaled Agile Framework series, this article with cover the Scaling Conetx and Some Basic Concepts like where scaling fits and how it works.

Let’s first understand what Scaling is?

As a word, Scaling means there are multiple teams working on a Product (Value Stream). 

Scaling Agile refers to the process where the established Agile methods (Scrum/Kanban) are applied to other layers of organization.

Look at the Matrix below to understand the layers of the organization. 

In any Project organization the ratio of Product and Teams is:

• 1 Team working on 1 Product
• 1 Team working on Many Products
• Many Teams working on 1 Product
• Many Teams working on Many Products 

The Matrix above shows the context of Product v/s Teams.

• When we define a Product – here we define an Independent Value Stream which makes sense from a market perspective.
• When we talk about teams, here we are talking about Development Team of Scrum which is 3-9 team members. This team excludes the Product Owner and Scrum Master.
• Scrum Only defines “One Team – One Product” Context. Scrum does not define the other contexts. Scaling is out of scope of Scrum.
• “Many Products – Many Team” context is defined by portfolio management, which is out of scope for most of existing scrum frameworks – SAFe is one of the most prevalent scaling framework that helps with
• “One Team – Many Product” quadrant is for Staff Pools who do heterogeneous type of work. Generally involved with ticketing systems in organizations. Kanban may work in this quadrant and the focus is here on resolving bottlenecks and getting heterogeneous work done without bottlenecks.

Context of Scaling and De-Scaling

When we think of larger products, we can think about descaling – that is, dividing the larger products first into smaller units of independent value streams (Products).

For the above product, the Scrum Context is that for each product (an independent value stream) there has to be a single product backlog, a single product owner and a single development team. Like the below diagram, each team works as an individual Scrum Team with their own “descaled” Product Backlog. There will have to be some considerations made to co-ordinate among the various dependent product backlogs. The diagram shows how the descaled products work.- Spotify is an example of framework which works on the principle of descaling

Context of Product Backlog and Product Owner

There is always a one to one relationship between a Product and Product Backlog and Product Owner. The context of the product backlog is shown below

The following structure where one is NOT OK. The accountability on the Product will go down if the following is implemented. It is better to descale the product instead of having a structure as shown below:

Context of a Product Owner and Development Team in Scaling

A Development team will always look up to Only one Product Owner.

A Development Team looking up to multiple PO means, the accountability is not central and conflicting decisions may come to the Development Team.

The post Scaling Context – Some Basics Concepts appeared first on World Of Agile.

What is Kanban?

• Start with what you know – Don’t try to reinvent the wheel right away. Visualize what you have now.
• Pursue incremental, evolutionary change – Once you can see the current state of your work, visualize how to improve it.
• Respect the current process, roles, responsibilities & titles – Don’t make drastic, sweeping changes without getting buy-in from the rest of your team. Remember, Kanban is a collaborative process.

• Visual workflows – You can’t understand what you can’t see.
• Work-in-progress (WIP) limits – Limit multi-tasking. By limiting your work in progress, you can actually get more done and do it better.  Multitasking, and especially task switching, may make it seem like you are getting more done, but in fact you are wasting a lot of time between tasks, forcing your brain to refocus.  Kanban is a great way to see the work needing to be done and systematically work on just one or two of the most important things until they are done.
• Enhanced workflows – Continuously improving the way you work makes you more effective and more happy.
• Agreement on process policies – Decide how you want to manage your team’s kanban using feedback from the team.
• Data-driven collaborative improvement – Changes should be made based on the scientific method instead of “gut” feeling.

What is Kanban WIP Limit?

• The project is of 13 user stories to be implemented (A thru M) by a team of 3 people.

• Suppose there are No WIP limits on the implementation, all 13 may be considered by the team with a average of 4+ user stories per person. The concept is that, if there is too much context switching, the 13 user stories might get delayed because the 3 developers may not be able to focus on any of the user stories.
• Thus now WIP limits are introduced as shown below. A WIP limit of 2 in TODO means that only 2 user stories should be short listed for development. A WIP limit of 3 in development means that there can be only 3 at a time in development cycle.
• Please notice that D is Done (and therefore there may be a slack with this developer) but still development is not started on G/H. If G/H is taken for development, the backlog for testing will increase and nothing will get completed. Instead the developer who completed D can either share some tasks of E,F or help in testing of C before taking up G/H.

The post What is Kanban? appeared first on World Of Agile.

Kanban Boards or Task Boards

The post Kanban Boards or Task Boards appeared first on World Of Agile.