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.

Common Misconception

Most people treat Sprint Review as a “gate check” forum to release the product into production. Thus, the Sprint Review ends up being a formal meeting with gate-checking checklists to go through so that the product can be sent to production.

What really is a Sprint Review?

• Sprint Review is an informal forum to seek feedback from the Stakeholders
• Intention of the Sprint Review is for the Scrum Team to find out if they are on track to meet the Product Goal, and if not, inspect and adapt the Product Backlog for future Sprints
• Scrum de-links the “go-live” or “delivery to stakeholders” and “seeking feedback”. Sprint Review’s intent is to seek feedback. The product may be delivered to the stakeholders before or after the Sprint Review

Recommendations

• Sprint Review should be a informal discussion between Product Owner, Stakeholders and Developers to discuss improvements in the product and increase the probability of reaching the Product Goal
• Sprint Review should be more like a working session instead of formalized presentations and checklists to go through
• It is better to create a separate gate check forum other than the Sprint Review. If any gate checking is done in Sprint Review, the real intent of getting feedback may be lost

Conclusions

Sprint Review is not a gate checking forum. It is a working session where Scrum Team and Stakeholders collaborate on how better to achieve the Product Goal

The post Myth – Sprint Review Being a Gate to Releasing Value appeared first on World Of Agile.

Most people think that the Product Owner being the one-point-contact (mediator) to talk to stakeholders is a great way of reducing wastage and unnecessary discussions. While, apparently it might look like a helpful  pattern but actually it turns out to be an anti-pattern .This way of working has more negative consequences than positive.

Why do people feel that the Product Owner is a mediator?

• The Scrum Guide says “The Product Owner may represent the needs of many stakeholders in the Product Backlog”. When people read this sentence, they may  feel that the Product Owner is the only person  that is allowed to interface with the Stakeholder and no one else can interface with them.
• Fear of a “Customer” or a “Stakeholder” escalating to the management has always kept the developers away from the “Customer”. Some of the common fears that hold back a developer are –

o   “What if I understand incorrectly?”,

o   “What if the customer escalates to my manager?”,

o   “What if the customer laughs at me?”,

o   “What if the customer thinks I don’t know things?”

o   What if there are any contractual implications to what I agree?

• The reluctance of the Developers (Technical teams) to interact with Stakeholders has made the Product Owner a mediator or a middle-man/woman. The developers expect that the product owner will always talk on their behalf to the stakeholders.

Negative Consequences

• Product Owner may not be able to convey what exactly Developers views

o   Developers have a unique point of view about any solution. Information may be lost when the Product Owner conveys.

o   Developers know the technical feasibility of any solution to a business problem. Product Owner may not know all the details of technical issues

• Information may be conveyed incorrectly and thereby increasing misunderstanding between stakeholder and the technical teams
• Product Owner may become a bottleneck and overloaded with work related to conveying information back-and-forth between Developers and Product Owner

 Recommendations

• The Developers should talk directly to the Stakeholders while keeping the Product Owner informed about the discussions
• Let Product Owner be the final decision maker; however, the details can be discussed directly thus preventing the overload on Product Owner
• Developers should not take decisions directly by talking to the stakeholder. Once discussion with a stakeholder is done, they can update the PO and abide by the decision taken by PO
• Trust between Stakeholder and Developers should be increased. This may be possible if the Stakeholders do not keep escalating against the developers and don’t ridicule them for their mistakes and misunderstandings. Stakeholder must understand that the technical teams are good in technology and may not be able to understand business concepts easily
• Product Owners should not have a controlling mindset. Sometimes  Product Owners who are used to the traditional way of working may initially want to control all the requirements. That usually does not work. Scrum emphasizes on maximizing the value. The Developers may have a unique point of view which may provide a better value to the product. Therefore, Product Owner can consider this as a good way of getting better value by having the Developers talk directly to the stakeholder
• Likewise, sometimes a Product Owner who is used to erstwhile command and control leadership may  feel  insecure or out of control  when  developers talk directly to the stakeholders. In such a scenario, the Product Owner may need to be coached to focus on maximizing the value . Many brains are better than one brain.

The post Antipattern – Product Owner as the mediator between Developers and Stakeholders appeared first on World Of Agile.

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do people feel that Sprint Zero seems a good idea

When the team start work the team observes these typical problems

• There is no reasonable Product Backlog from which a Sprint Backlog can be created.
• Designs are not good enough to start
• Architecture decisions are often delayed

Team often struggles to create a usable product increment during the first Sprint. Often then, the teams starts with a Sprint Zero so that a usable product increment may not be expected from the team.

At the outset, it looks to be a great idea – especially those who have come from a waterfall mindset and are used to doing a lot of preparation before beginning a project.

Negative consequences of Sprint Zero

Sprint Zero is often considered an agile-sounding term for pre-Sprint preparation work where no increment of product value is provided at all. In reality, the whole intent of the Sprint is lost. To be a Sprint, something of value must be delivered in a clearly time-boxed fashion.

What could be done instead of Sprint Zero

• In Agile, we believe in just-in-time work. However, in reality this may increase the risk. Hence we should start thinking about the work (which includes designs, architectures, refinement of PB) 2-3 sprints in advance. Not too early, and not too late.
• Weak product management results in this anti-pattern. Agile does not mean that we don’t have planning. There is a lot of planning in agile. However, the planning is done such that the team has enough work for the next 2-3 sprints. Not having decisions ready, not having a product backlog ready often causes the team to resort to this type of anti-pattern.
• Critical Architecture decisions, critical design decisions, critical business decisions need to be identified. They may become show-stoppers later and the team may not have enough work for the next sprint.

The post Sprint Zero – An Anti Pattern appeared first on World Of Agile.

It is a common mis-conception that Scrum is only useful for small projects.

The real fact is that Scrum is used for solving complex problems. Complex problem is a problem where there are “unknowns” about requirements or the solution.

For solving complex problems, the decisions have to be taken based on what has been done in the recent past. It is extremely difficult to base your decisions based on long-term assumptions. This way of solving problems is called Empiricism or Empirical process control. Scrum is a framework based on Empirical Process Control Theory and therefore, used for solving complex problems.

A complex problem may be big or small. Therefore, the size of the problem has nothing to do with usage of Scrum or other frameworks/methods. A few examples of massive complex problems

• Merger or separation of a bank – When two banks merge or separate, there are a lot of unknown factors on the products in the resultant merged or separated bank. For example, one bank may be a risk-taking bank have an investment product based on a mix of equity, commodities, and derivatives, whereas, second bank might have a more conservative approach based on fixed-deposits, company-fixed-deposits of blue-chip companies and debt market involving only government securities. Now what would be the product applicable for the new merged bank? Would both products be offered by the new bank or would they be another combination product, or if the merged bank carries the image of the conservative bank then should it even offer the risky product? There are a lot of unknowns here. Would the image of a new merged bank be conservative or risk taking? Would the customers of the risk-taking bank accept the conservative products? Would the customers of the conservative bank accept the risky products or accept a risky profile of the new merged bank? This is an example of an unknown scenario. Unless things are tried out, there is no way you could take decisions. As a business, you may try various combinations, but the answers are possible only after trying different products and taking feedback from customers.
• Development of a medicine or vaccine for an unpredictable disease – The whole world grappled with the Covid-19 pandemic in 2020. The solution to solve this problem was two-fold – either develop a vaccine to prevent the disease or develop a medicine to kill the virus if anyone gets infected. Both were big unknowns. How the infections spread was unpredictable and also how the disease affects the patients was also unpredictable. Scientists and researchers had no option but to use the trial-and-error approach based on the past knowledge of various viruses. However, the majority of the decisions were based on what was the result of the trails done on various animals and eventually on human beings. Again a complex problem where decision can only be taken based on what has been done in the recent past. The decisions cannot be taken based on long-term planning.

Naturally, the approach for solving these kinds of problems is to shorten your planning horizons, try out things, if things do not work then try something else, if things work then try something else to make the solution stronger. So isn’t Scrum a way of solving such problems? Scrum shortens the planning horizon to maximum one month, then uses the inspect-adapt cycles (at the bare-minimum) through Sprint Reviews, Daily Scrums and Sprint Planning. The implementation of the Product Backlog is in-fact a way of adapting the requirements as you move forward and as more is known about the problem you are solving.

Therefore, it is a myth that Scrum is for small projects.

Conclusion

The size of the project has nothing to do with the use of Scrum or not.

• Scrum is based on Empirical Process Control Theory.  Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.
• Scrum combines four formal events (Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective within a containing event, the Sprint) and three Artifacts (Product Backlog, Sprint Backlog and Increment) to implement empiricism. These events work because they implement the empiricism pillars of transparency, inspection, and adaptation.
• Thus, Scrum is being used for solving complex problems (unknown requirements or unknown solutions) for small as well as large projects where constant inspection and adaptation is necessary and decisions have to be taken based on what is observed. Scrum Team observes what is happening based on the feedback received and adapts to the changes.

The post Myth about Scrum only being useful for small projects appeared first on World Of Agile.

Common Misconceptions and negative implications

Some teams treat the Sprint Backlog as just a smaller version of the bigger plan (Product Backlog) and start creating baselined Sprint Backlogs for multiple future Sprints. The negative implication of this practice is that the “Inspect and Adapt” cannot happen. This becomes just disguising the waterfall and calling it Scrum.

Recommendations

• There should only be one Sprint Backlog. This represents the forecast for the current Sprint. At the end of the Sprint, the Sprint Backlog is emptied. All remaining items are taken back to the Product Backlog. All completed and done items are taken into Increment. The reason why this is done this way is to give opportunity to the Product Backlog to be re-ordered if needed.
• It is possible that the Product Backlog item changes the order since there might be change of business priorities. If the Sprint Backlog is baselined for multiple sprints at the start then an important opportunity for inspection and adaptation is lost.
• The discussions in the Sprint Planning result into a new Sprint Backlog based on the business objective to be achieved this Sprint. Even during the sprint, the Sprint Backlog emerges – more details get added and new things get clarified.
• To see how to handle changes in scrum please click here

The post Myth about creating multiple Sprint Backlogs before first sprint starts appeared first on World Of Agile.

Common Misconceptions and negative implications

• Definition of Done is directly compared with Quality Criteria which was used in waterfall. Because of this teams tend to baseline the definition of done before starting the project
• By baselining the definition of done, product teams and delivery teams don’t get to iterate the quality criteria as they go-along
• Lot of time then gets wasted in trying to get the product too precise and the releases get delayed

Recommendations

• Definition of done should be emergent. That means the definition of done should get more and more stringent as the product maturity increases.
• There is no point in trying to make the Definition of done too stringent upfront. Instead one can always start with “the bare minimum” definition of done.
• As the product matures, it is often necessary to make the definition of done stronger. It makes sense then to make the definition of done stronger as you go along.
• However, one must understand that if the Definition of Done becomes stronger, then there may be undone work associated with the product and the product must be brought to the current definition of done. That means, all the undone work must be identified and put back into the product backlog.
• For example : One could start with a definition of done as
  1. Acceptance criteria for functionality is met
  2. User Documentation is completed 
  3. Integration testing is done
  4. Regression testing is done
• As the product matures, lets say, after 6-8 months, the volumes increase drastically and product becomes slow. Then it may be required to add performance testing into definition of done. So the new Definition of done could become.
  1. Acceptance criteria for functionality is met
  2. User Documentation is completed
  3. Integration testing is done
  4. Regression testing is done
  5. Performance testing is done
• So now one must understand that because Performance Testing is added to the definition of done, it is now required to add the “undone work” associated to the last 6-8 months of product that was already completed. And that means, we may have to dedicate some time in the upcoming sprints to get the product to the current definition of done.
• By doing this, it avoids a lot of initial wait time before we get the product into the market. In the above example if we would have added performance testing initially, a lot of time could have been wasted trying to do performance testing when it was not required. We could have missed the window of opportunity. Our competitors would have released the product earlier than us.
• It is not just the scope which is iterative and incremental in Scrum. Definition of done (Quality Criteria) is also iterative and incremental.

The post Myth about Definition of Done being baselined before project starts appeared first on World Of Agile.

The Increment is the sum of all Product Backlog Items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done” which means that it should be in a useable condition and meet the Scrum Team’s definition of Done. It must be in a useable condition regardless of whether the Product Owner decides to actually release it.

Potentially Releasable Product Increment

Scrum asks that teams deliver “potentially releasable software” at the end of every sprint. To me, potentially shippable software or potentially releasable product increment is a feature(s) that can be released, with limited notice, to end users at the product owner’s discretion. Products that can be released to end users with two days can be reasonably said to be in potentially shippable state. Ideally, potentially shippable is equivalent to the Definition of Done.

Example of Potentially Releasable Product Increment

Let us take a simple real-life example to understand this term. Let us say you are interior-decorating your house. You could do the work in multiple ways:

1. You could change the tiles of the entire house, then fix the paint of the entire house and then you could move-in back into the house
2. You could complete one bedroom, then another, then the kitchen and finally the living room.

In the first example, you thought about the entire product (interior decorated house) as one chunk and thought about it in a traditional way. Let us think if we can deliver this in the second option. The second option gives you a way in which, if required you could get incremental value of the product. Potentially Releasable Product Increment is about getting incremental value for your product. Whether you really move-in after completion of the bedroom (in the above example) is your call, however, you have an option – just in case you want to move in.

Let us see the above Cake piece. I can bet that a child would enjoy the piece of a entire Vertical Slice of cake instead of only icing or only chocolate or only cake. Potentially Shippable Product Increment or Potentially Releasable Product Increment is a vertical slice which gives incremental value to the customer.

The post Product Increment appeared first on World Of Agile.

Sprint Backlog consists of

• Sprint Goal (WHY)
• Product Backlog Items selected for this Sprint which will help meet the Sprint Goal (WHAT)
• Plan to deliver the Product Backlog Items (HOW)

It is common practice that the Sprint Backlog is represented on a task board which provides a constantly visible depiction of the status of the items in the Sprint Backlog. Also included in the Sprint Backlog are any risks associated with the various items. Any mitigating activities to address the identified risks would also be included as tasks in the Sprint Backlog.

Once the Sprint Backlog is forecasted (based on metrics such as Velocity), the team should make constant changes to the Sprint Backlog as more is known about the Product Backlog items selected. The changes made to the Sprint Backlog should be such that the changes does not compromise the Sprint Goal selected. If major changes arise during a Sprint, they are added to the overall Product Backlog and included in a future Sprint.

Representations of Sprint Backlog

In its most basic form, a Sprint Backlog is represented as a task board and can be drawn on a whiteboard or even a section of wall. Using electrical tape or a dry erase pen, the board is divided into three columns labeled “To Do”, “In Progress” and “Done”. Sticky notes or index cards, one for each task the team is working on, are placed in the columns reflecting the current status of the tasks.

The task board is updated frequently, most commonly during the daily meeting, based on the team’s progress since the last update. The board is commonly “reset” at the beginning of each Sprint to reflect the Sprint Plan.

To see how to handle changes in scrum please click here

For myths around Sprint Backlog, refer to following articles

• Myth about Sprint Backlog being a commitment
• Myth about creating multiple Sprint Backlogs before first sprint starts

The post Sprint Backlog appeared first on World Of Agile.

“What” needs to be done in Scrum are called Backlog. Product Backlog is everything that is yet to be done and not necessarily the activities that the team has fallen behind.

The product backlog is an ordered list of requirements that is maintained for a product. It consists of features, bug fixes, non-functional requirements, etc.—whatever needs to be done in order to successfully deliver a viable product. The product backlog items (PBIs) are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc.

The product backlog contains the Product Owner’s assessment of business value and the Developer’s assessment of development effort.

The product backlog and the business value of each backlog item is the responsibility of the Product Owner.

The size (i.e. estimated complexity or effort) of each backlog item is, however, determined by the Developers, who contributes by sizing items. Product Backlog is everything that is yet to be done and not necessarily the activities that the team has fallen behind.

• The product backlog is an ordered list of requirements that is maintained for a product.
• It consists of features, bug fixes, non-functional requirements, etc.—whatever needs to be done in order to successfully deliver a viable product. The product backlog items (PBIs) are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc.
• Items added to a backlog are commonly written in story format. The product backlog  is what will be delivered, ordered into the sequence in which it should be delivered. It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the items on the backlog for the Developer to choose.
• The product backlog contains the Product Owner’s assessment of business value and the Developer’s assessment of development effort, which are often, but not always, stated in story points. These estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items.
• The product backlog and the business value of each backlog item is the responsibility of the Product Owner. The size (i.e. estimated complexity or effort) of each backlog item is, however, determined by the Developers, who contributes by sizing items, either in story points or in estimated hours.
• Scrum advocates that the role of Product Owner be assigned. The Product Owner is responsible for maximizing the value of the product and the work of the Developers. The Product Owner gathers input, takes feedback and is lobbied by many people, but it will ultimately make the call on what gets built. Product Owner is solely responsible for the management of the backlog.
• Ideally the Product owner needs to have clarity of all requirements that need to be taken up in the next 2 or 3 sprints. The rest of the stories could be kept at a fairly high level. The Backlog Grooming Sessions during the Sprints are used to get clarity on the backlog items which are not clear.
• A Backlog is a live document or list that the Product owner continuously updates

In short any work that team could do for the customer should be routed thru the Product Backlog.

Elements of Product Backlog

Product Backlog is not just the functional items. Product Backlog may contain many other types of requirements,

• Infrastructural Items
• Architectural elements
• Technical Debts
• Non Functional elements
• Security elements
• etc

A Video on Product Backlog Metaphor – Iceberg

Product Backlog is a Dynamic List – It Emerges

Product Backlog Items are dynamic. That means they keep emerging as clarity comes. Remember, Scrum is based on Empirical Process Control. Unless and until once tries, how can clarity emerge. The reason why we use Scrum is to handle complex work – and complexity means unknownness. To see how to handle changes in scrum please click here

Multiple teams working on same Product Backlog

The post Product Backlog appeared first on World Of Agile.