Question : What are different metric to show to stakeholders the progress. ?

Question : Do we have board to maintain the PI Objective . ?

What if we discover later that there is gap and we cannot deliver the PI objective
in middle of iteration 2 . ?

If we pick a feature start analysis and create US before the PI then where this
US should keep it because we cant add it to our team backlog without the Team
PI Objective is decided ?

PM states the priority features based on some mechanism team will pick off the
feature they wish to do and refine the same and story level estimation before
coming to PI.

If PM is distributing feature from Program backlog to the team then how does
Agile team has any freedom to select the item? How can we avoid a clash
between team on selection of US.

Question : Saket How do we measure the life time impact of the feature?.

Agile Release Train : Essential SAFe Terms - 2 of 7

https://www.youtube.com/watch?v=ezVImcbS4Ew

RTE: (Realese Train Engineer) : Is more like a chief scrum master responsible
for overall removal of impediment, transparency of the ART . If something
Scrum master cant solve will go to RTE. All the agile team need to apply system
level thinking to overcome the issue by having close interaction.

PM (Product Manger or group of people ) : It can be considered as someone who are

working with business owner and stakeholders in order to identifying value adding feature at
ART level.

PO are at team level who maanges the Feature which are sliced from Program backlog to
Team backlog.

PM news to mentor the PO.

System Architect :

Person responsible to facilitate compatible technology architecture between the team.

They added Enables to Program backlog which gets sliced ton the teams

Business Owner :

These are like key stakeholders responsible for particular ART . They collaborate with
PM and work with AGile team to share the business perspectives. They also helps in
prioritization of the work.

We need a team working horizontally ensuring system level integration of work

ensuring overall development of work in an integrated way which does technological
assessment , work which ensures on a periodic or daily basis we have integrated
products which can be evaluated and feedback can be fast.

Thus an ART is a group of tema having common leadership, common goal, common
program backlog, they collaborate commonly in order to achieve integrated solution.

We should not think that we have a project so we need to build a ART rather we should
think that team is formed and we keep getting new requirement and we keep allocating
the requirement to the ART .Its a long lived train where requirement keeps coming.
For Safe we need ART

4. Program Backlog : Essential SAFe Terms -

https://www.youtube.com/watch?v=MvBinEmvtWo
Program Backlog : It is a common back log for entire agile release train. We can have
multiple ART and each may have its own backlog which is called a program backlog.

Program backlog : It is a list of work items which is acting as input to an agile release train which
will deliver the value to the end customer.

ART is expected to work on Program Backlog , It can also can be called as ART backlog.

In PI planning we decide which particular piece of Program Backlog we are planning to achieve
in PI.

PB: it can have two types of work item

a. Feature : A product Manager needs to work with Business, Stakeholders to discuss what
king of feature needs to be developed in upcoming time. These are features

b. Enablers : A System Architect is responsible for enablement of the compatible architecture.

And for this some technological oriented work need to explored by the agile teams which is
know as Enables.

Something which has reached to program backlog needs to be well refined unlike other backlog
where upper items are refined than lower items.
When does this refinement occurs ? We may have a kanban process which is creating a feed
for this PB. We will have various stage which are focusing on ideas, analysis where we add
things which act as acceptance criteria .

We will maintain WIP limit for backlog refinement process in order to get just in time ready
program backlog items.

Product Manager is the role who is facilitating this whole discovery.

We should not think that we have an ART which is expected to deliver a particular product and
we need to prepare the program backlog or release train backlog and give it to them .this
should not be the expectation as PB are expected to be JUST IN TIME defined or explored. We
are not expected to place many features and enablers and it should have only those which are
going to be part of 1st or upto 2nd PI thus defining the WIP limit.
Rest all ideas are suppose to be rested as part of idea, analysis stages as based on various
demos, learning we are expected to discover new information as we go along thus we only want
JIT defined items are part of Program backlog.

Question : where do we keep items which are not part of Program backlog.

WSJF : It is an ROI based prioritization which is facilitated by Product Management in

collaboration with various client, business owners. Thus the items which go up are part of the
upcoming PI meeting.

5. Program Increment PI Planning Meeting :

https://www.youtube.com/watch?v=yssQ3hNGYkw
➢ PI planning helps us to balance the capacity and demand.
➢ Suppose we have 10 weeks of PI. We have a defined PB , we have Kanban Process to
provide feedback and we have PB which is refined using WSJF.
➢ We need to plan which portion of PB can be planned in upcoming PI.THe ART
works in Iteration.
➢ The PI planning Meeting comes in between the WSJF and the duration of 10
weeks. The last interaction will accommodate the PI meeting time box which is
going to help us to determine which item can be picked for the next PI Timebox
of 10 weeks.
➢ Input of PI planning = is top level requirement from PB . This needs to be
discussed with the team during the last innovation and planning iteration where
refinement and understanding happens which are going to come in further PI
planning meetings. PM states the priority features based on some mechanism
team will pick off the feature they wish to do and refine the same and story level
estimation before coming to PI. There could be some deviation that a work was
picked by other teams.
➢ The team also needs to understand their capacity, the current state of product
with the help of Demo of previous PI Timebox output.
➢ If there are any improvement items from previous PI planning that too can be
input to PI planning. Team needs to reserve some capacity for those suggestion.
➢
Output = each team knows what they need to contribute in a given PI time box.
➢ In PI Planning :

Step 1: Deep briefing where stakeholders ,PM talk about big picture, Program
Vision, Upcoming Milestone, Business opportunity or one can say requirement
related bigh picture.
Step 2 : Technology Related Briefing by System architecture .Some common
guidelines to the team, if there is change in DOD, any new discovery of enablers,
improvement required in automation or integration. Any security related deep
briefing, Data related or UX related .
Step 3: The Agile team will have their break out session of 3 to 4 hour where
they prepare their part of the plan. Based on allocation of features they come up
with plans for their PI. They evaluate the capacity, need of the feature ,
estimation of US., external dependency, uncertainty. ANd finally they are able to
plan what will go in Iteration 1, 2, 3 which are tentative things. Like 15 US is
broken as 5 US per Iteration. If needed they can collaborate with other agile
team.

Step 4: Then each agile team will give there presentation to ART. Thus we can
know the gap and take some feedback as note thus we collaboratively work.
Step 5: Thus demand and capacity is managed, issue are resolved before we get
started and we have a committable plan and thus an integrated plan where
dependencies are taken care of.
Step 6: THe business is part of the planning and they need to agree to the same
. Although it is democratic meeting but someone need to agree on the PI feature
accepted .

OUTPUT of PI :

The output is PI objective which is taken by different teams also can be called as
Team level PI objective.

Program Board (Dependency Diagram): It presents two information

a. How incrementality the Team Level PI Objectives will be taken care of. Like
1st week we will do xyz feature and next week abc feature.

b. Dependency , Integration and delivery timeline of PI objective are also

explored with help of Program Board .
 Team whatever they have agreed during the PI meeting will dump into the team
backlog and they will keep refining the same , iteration after iteration to complete
the PI objectives.

Question : Do we have board to maintain the PI Objective . ?

What if we discover later that there is gap and we cannot deliver the PI objective
in middle of iteration 2 . ?

If we pick a feature start analysis and create US before the PI then where this
US should keep it because we cant add it to our team backlog without the Team
PI Objective is decided ?

PM states the priority features based on some mechanism team will pick off the
feature they wish to do and refine the same and story level estimation before
coming to PI.

If PM is distributing feature from Program backlog to the team then how does
Agile team has any freedom to select the item? How can we avoid a clash
between team on selection of US.

6. Team Backlog : Essential Safe Terms

https://www.youtube.com/watch?v=_AN5WR8RtYg
Team Backlog : It is one agile Team working together on team backlog. Its a disaggregation of
a program backlog items which is prioritized by PO for a given team. In the upcoming Pi this
becomes your input for your team. Team member is expected to participate in product
refinement session which helps to come up with workable team level backlog. We can maintain
the backlog for upcoming PI and doing this team backlog item incrementally in each iteration
and producing a workable demo for it helps to finish the PI objective. As delivering Tema
backlog in turn helps to deliver the Program backlog.

In PI planning each team took their objective while doing so they divided the features into US.
SUppose Team A takes 2 features which are divided into multiple US in order to find out can
they really deliver this feature in the upcoming PI time box.
US is a small slice of feature which can be done in a given iteration. So each vertical slice we
create of Feature becomes a US. You can create this US before pre PI planning or during the PI
planning breakout session also as a team A as this is feature associated with you and you
create these US.
Based on the size of US we committed the delivery timelines or overall the estimation of the
dependency during the pi planning.
Now the US will become as Item within team A boundary . Thus Team backlog is maintained for
each team. Each Team PO will lead this Team backlog.
Enables can also become part of Team backlog.
7. Innovation and Planning Iteration :

The three Demos of 3 interaction are showed on top which represent Commo Integrated Demo
which is output of complete ART .

Innovation and planning iteration can be seen as planning iteration for upcoming PI. The team
comes to know the probable feature that will come to them. PI planning meeting (max 2 Days)
is also happening in this iteration.

IPI :
➢ We can keep few time for left over work of previous iteration. (in 1st week)
➢ Space to the team to share knowledge , infrastructure , provide some KT and
innovation (1st week )
➢ Team comes to know about the features and break the features , estimates the
same before the PI planning. (1st week)
➢ PI level demo is a half day event where complete ART will look into state of
system.Thus before PI everyone should know where we stand. We do have
team level retrospective but this is at ART level.
➢ Finally we have PI Planning.
SAFE :

When we start a network then the entrepreneur at center interact with client directly .
However when we grow into a scalable business then we have hierarchy.
And slowly we realize the network structure which we started with has been collapsed
and more like hierarchy we have moved into then the speed of network or
connectedness to the customer goes down .

Here the level 3 are interacting with customer thus the top level is not interacting with
customer.

Thus as we move towards scalable model we start having less interaction with
customers.
We need a system which supports continuous delivery (sustainable structure for existing
product) and innovation (entrepreneur level) .

THus in Dual network system we have speed of network which interact with hierarchy and the
hierarchy network system is designed for efficiency and network.

Now how does it links up with SAFE ?

SAFE is your entrepreneurs or network operating system which will interact with hierarchical
functional system which is providing an operational stability so this entrepreneur network system
is based around value stream .it focus on customer need and how can we keep delivering
changing customer needs at faster pace.
Thus it is not just the dev team but the whole organization that is ready to deliver for a changing
customer requirement this is business agility.
So everyone should look at system level rather than just focusing there part of work.
We cannot attain agility directly but when we work into these competencies in integrated fashion
and organization is ready to adapt to the change of business needs.
We should keep customers at the center . this is a business agility way of thinking.
Not so business agility is like we exist to earn money or to make provide ROI to the stakeholder
. So a good business agility should be to solve customer problems.
As leadership of the organization we should create an environment such that business agility
can grow. Leaders have bigger influence on the policy , system .So we need to create a culture
of self organizing team who likes to take initiative rather than a team who are afraid or
suffocating team who fears to commit.

************************************************************************************************
Leaders promotes experimentation,empower teams so that team can achieve growth mindset.

****************************************************************************************

When we have success then we start limiting our thought to maintain the current success. The
organization also promotes this that we should not disturb the system. THe issue with this
approach is environment will keep changing then we are left isolated so its better to keep
exploring.
So it's important for the network system which keeps the entrepreneur spirit alive so that
system should have growth mindset.
**********************************************************************************************

The leadership influences the whole organisation together and each section even if the
hierarchical structure will have there way of doing things that why there are some foundational
ideas which can be cultivated across. That why leadership emphasize about values so that
middle management level or team level they can know what action they need to do to comply to
the values.
Hence whatever we are doing its all about generating the value to the customer , stakeholders.
Thus leadership promotes culture of respecting people etc and thus environment of continuous
delivery, innovation and space for improvement.
**********************************************************************

Safe principle are founded on lean, kanban, devops, agile body of knowledge.
Its like things which are important for large business solution agility and they provide directions
for thinking. Thus they influence our thinking. Apply system thinking is that we should look at
organization level and should not just look at small portion of system.
Thus we need to apply overall organization level thinking which produces overall inspect and
adapt capability for the organization.
Assume Variability : in case things go differently then we need to preserve options to handle
it.
Milestone: SHould be based on something tangible working solution and system rather than
something based on status report.
Visualize and limit : It says about the kanban process , we should have a vision of what is
happening and we should limit our WIP. We should not start too many things together and keep
the thing in a small size so that it keeps passing through the queue and things should not get
clogged.
Apply cadence, Synchronize with cross domain planning: It means apply thing inn rhythm
and synchronize with multiple rhythms .
Unlock intrinsic motivation : the member should be motivated with the vision
Decentralize decision making: everything should not be decided by one person.
Organize around value : We need to organize everyone around value delivering.So we can
see this is how we are delivering the value to the customer and the people and the systems who
are involved are together . I don't have to depend on someone who is in a different group.

*************************************************************************************************

Team Agility :

So if a team is agile, organized and technically competent to deliver then this will enable
business agility . So even if leadership has great ideas still a good team is required to fulfill it.
So team competency describes critical skills which are lean agile principles and practices for
high performing agile team. It discuss how we organize team.
There can be a scrum team or Kanban Team. We should have cross functional team which can
pick up item from backlog and deliver it. So end to end work is done by the team and they are
not dependent on anyone else. There can be feature team or there can be a component team
which job to create component which make other features successful.
There can be Enablement team, agile business team which support overall business.
***************************************************************************************************

➢ Its like virtual organization of multiple teams. ART is a teams of Agile teams. So
basically suppose we group people of 10 member s a team then in a 100 member we
will have 10 teams part of ART . if the number is too high then we need to create another
ART.
➢ All the teams of the ART need to syncronise like scrum of scrum meeting.

➢
We need to discover what the customer needs rather than they tell us what they need and then
we develop on cadence and release on demand thus technical agility comes in picture. Thus we
have mechanism to develop an integrated work done by the different different teams and that is
why we achieve agile product delivery.
We also create practises which makes deliver faster like devops and continuous delivery
pipeline so that if something valuable is ready we can push it frequently.
**********************************************************************************************************

Technical agility is like are we building thing right whereas product agility is are we making the
right thing.We know this only when we relate to customer and these design thinking body of
knowledge gives tool and technique to do that so customer centricity is a mindset, it a way of
thinking whereas design thinking gives the practises which helps one to make a customer
centric thinking.
Like we spend time with customers to understand their requirements.

The problem diamond box here has a diverse step followed by converse. So in the case of
diverse we first look in a broader way by not asking customers what feature is needed rather
than more wise observations and question like how can we make your day better in the product.
Once we get the idea then we converse them into Features.

The other diamond is Solution Space so its about what alternative path we can take to solve
these problems and we close it by converging and coming with small small workable items so
that team can do continuous delivery.
Lastly, it should be sustainable.
******************************************************************************************************
In ESD : Its all about how can we make multiple ART work together.What kind of competency
make them aligned and ready for the change so that we can apply lean system and solution
engineering space for the large thing this is ESD.
Thus multiple ART having there own Pi coming together for delivery.
Its about integrating work products of different different trains , having quality management
system which promotes large solution, working with overall solution intent which initially might
be little variable and as we start taking decision part of it becomes fixed.
Having some mechanism to work with suppliers.

*******************************************************************************
Strategy Agility : It is to identify new customer and take organization to next level.
So in this we suppose we have already invested here and we are in pressure that we should
make it work so idea of organization or strategic agility is we need to focus how much will go
before we can get result.
THis more can we put it somewhere else to get more money so rather than just keep thinking
about I have already invested this much I need to focus on how incremental Investment I need
to make and what returns I am going to get out of it. If I do some mistake i should not do it
again.

It helps you to evolve as the market is evolving.So we should learn at individual, team ,
organization level. Keep experimenting even if we fail.
SAFe® Principles | # 1 - Take an economic view | SAFe® Framework

Everybody want to take economic view as we want to maximize the economic benefits by
reducing cost generating more profits. But sometime we may end up taking
process views , we look what is the process and we follow it. We need to ask ourselves in a
given context or day is it right way to do economically or do something using which we can
make more economics.
Habit View : We may develop a habit by doing things in a particular way and during some time
that becomes a habit which may be good thing to do 6 months ago but now things has changed
but there habit has not changed. So some of team members are taking habit instead of
economic view.

Emotional View : Emotionally some people thinking that this is the best way to do or the best
framework to work on and best approach to work on and are emotionally connected to it.

Hence it should be reminded when we are looking at scale agile framework is that economic
view is better.
We need to have agreement on how we can evaluate the various economic views.
When we need to trade off between time to market over risk. Time to market over cost and
multiple competitive parameters.
We need to make decision that should we innovate more than start the deliver
Hence the system and context and various parameters helps us decide.

As scrum master we can make a decision that a bug which can be fixed later as money, benefit
may be associated with it.
Although it is said the cost of fixing the issue increases exponentially as we delay it
It could be decision related to merging the code or validating something in the scrum events so
that the team thing economically.
As PO when we refine PB then we need to think economically, the risk involved.

2 - Apply Systems thinking

Thing about big picture . We should think end to end rather than solving small part of
the problem.
One of example is dividing an elephant does not produces small elephants. Generally
we have idea to divide the problem into smaller pieces and then we try to solve those
pieces but in reality what happens is that we miss the complete picture as we may fix
that small piece but the problem gets shifted. Hence we need to apply system thinking .

There are trade off which needs to be taken care of , As a PM we need to understand
the system dependency we may choose to build the best performance of the piece of
solution but it may impact the overall solution usability. Hence we should try to achieve
optimal system level performance.Hence we need to look into interconnection,
interdependence of the system

The people building the software are also part of system. So different team working
together also creates organization system , so if one team go slow then it may impact
other team which may create a replicating effect on the complete system which can
derail the overall solution goal. We need take responsibility as overall ART to produce
our committed solution, a customer delivery value which can help us achieve overall
goal. Hence we need to manage all the team to the common solution goal. Thus we
need to apply system thinking at solution level as well as team level in order to
promote system level goal over small component or team level goal .
Lastly we need to think end to end delivery of the development value stream so we
need to optimize the requirement till delivery level of the flow and remove any
blockages. We need to optimize the point from where the feature comes into PB
preview till it is delivered to customer. So we need to optimize the complete end to end
development value stream so that we apply a system view here. For the value to be
realised the gap between feature getting created and customer use should be less.

We may want to do a complete value stream analysis of our development. A tool

where we see how many steps we take before we deliver a value to our customer.

One of the way to do it keeping track of the time .

SAFe® Principles | #3 - Assume variability; preserve options | SAFe®

We need to preserve option for any uncertainty. For this we have a timeboxed approach
so whatever variability is coming it is limited to a particular timebox . So after variability
is limited to that time box then we all stakeholders come together and review it and
learn from it. Hence we are not planning everything ahead rather for a shorter time
duration.

We can take a set based approach that is rather than having one solution or sequential
path we may have multiple solutions which are Option and we can start reviewing and
dropping out some options which are not relevant . This will speed our development as
we assume there is variability. Thus we start working on multiple option rather than
sticking to one.
We may not commit to 100% of our capacity
Frequent Inspect and adapt helps us to minimize variability .

Question : Should we implement parallel solution to same problem when we have

options?
SAFe® Principles | # 4 - Build incrementally with fast ,integrated
learning cycles

If we need to develop a large system we need to start small and finish end to end for
that small piece , take a feedback , take the learning and incrementally add more part to
the small piece again finish the whole cycle take the feedback and this is how you
incrementally increase the product.
We may not have complete knowledge of technology,customer we actually acquire that
knowledge by building product incrementally , it gives us opportunity to learn about
those uncertainties

In safe environment we may have multiple teams working with us involved in doing
development and the team may start thinking that we may need to work on only our part
of the work and may start delaying integration with other team and if we do that we are
violating the principle. Hence we need to build whole system incrementally.

When we apply system thinking on safe environment then we focus on continuous

integrating our work with other teams, continuous feedback on our integrated system .

SAFe® Principles | #5 - Base milestones on

objective evaluation of working systems

We should have working system which is continuously incrementally integrated shared

to stakeholders for evaluation rather than just showing some report. So we have team
level or ART level demo to stakeholder so that they can se working piece and give us
the feedback.

Question : What are different metric to show to stakeholders the progress. ?

SAFe® Principles | #6 - Visualise and limit WIP,
reduce batch sizes, and manage queue lengths

Visualise and WIP : We should apply visialization at team level. Program level, portfolio level
so that everyone has clarity of what is going on where we are stuck and this whole process also
improves by applying WIP Limits.

Visualize : helps in having same understanding , we can use Kanban board for the same.
It helps in creating empathy i.e someone working in one area knows what work is going on other
level.
Visualization also helps to identify the impediments and how we should unblock so that we
achieve the flow so we need to decide the whole visualization considering is this visualization
helping us in exposing the problem and helping us in making decisions.

1. We create swinlines to focus on priority of work

2. We have different icons to recognise the US, epic .
3. We can have a red sticky or some kind of Info with the item which is blocking a work.

WIP : It is agreement which may evolve to ensure that we should not have lot of things ongoing
before we move to the completion stage . I should have moved certain set of work to next stage
before I can pick some more items.
So if the slot is full then we will not take any new work until unless some items are pushed to
the next slot.
The value will only come if we are pushing work to the next stage Hence we need WIP limit so
that we do this activity.

Total

3.16 Zone 2.34

Reducing Batch Size : Our goal is to do small work and we incrementally build the thing.
Hence we need small batch size else many of the things will start falling apart. If we don't have it
then we wont be able to take decision, evaluate the situation , discover the variability preserve
option . We will end up with partial completed work which are difficult to evaluate. Hence we
need to work in small batches.
At the same time we need to consider the economic views . So the question is how much we
should reduce the batch size as the industry are different hence it depends .

We have Items in batch is on x axis , Cost is on Y axis :

There are type of cost which is reduced if we increase our batch size.

Lets look at problem : Suppose we have to ship one bread to retailer shop then the cost will be
more however if we ship large amount in one instance then the cost will be less . Hence the cost
for transportation is high if we transfer single bread as transaction cost is high. In terms of IT we
can say we have a feature which is ready and we want to deliver that feature to the end
customer which involves data migration, regression, manual update and compliance and it
takes 5 days for the same then for the next item also it will take roughly the same amount of
time. Hence if we do 10 items in one go then per item the distribution of those activity
transaction cost is reduced.
But one may say the whole idea was to reduce the batch size but here we are increasing the
batch size well that's true but we also need to look at economic exploration .

There is another cost involved know as Holding Cost : What I am losing by not delivering the
item. For example : SUppose the retailer is having old bread then the customer will not wait for
the next day for fresh bread, they will simply buy something else. Hence we are losing money or
the opportunity of selling so there is cost associated with holding the breads. As bread needs
better storage . Hence holding bread needs maintenance .

Hence with increase of the batch size we are delaying the delivery hence the Holding cost will
increase.

Lets have a look in the IT world we have have various benefits of it as I validate my
assumptions by putting the feature into the production and by realizing it to the end customer, I
deliver the value , I mitigated the possible technical risk which one may discover if we d not
learn about the behavior of the products . Hence Delaying the batch or rather when we increase
the batch it reduces the learning as customer feedback is delayed and in turn reduces the ability
to adapt and finally reduces the ability to deliver the value frequently.
We always focus on transactional cost however its difficult to estimate .hence we we need to
optimize both of it .

For example in e commerce the holding cost is much as customer will be attracted to other
vendors. Hence Ecommerce releases the feature fast than companies who have monopoly .

Optimal Batch Size : It is sum total of these two curves . As per image we observe, midway is
the optimal cost.
Now if we can reduce the transactional cost incrementally, then we can shift the batch size to a
smaller value that is towards the 1 number in the graph. For example we purchase solar drones
to distribute the breads hence the distribution costs has been taken care of .Hence we don't
have to wait for a big batch for transport. In the IT industry we can compare it with
AUTOMATION which reduces the transactional cost .

QUEUE LENGTH : Suppose we have our requirement list at Point A and deliverables to
customer at Point B . We might not be committing everything to the customer however the
queue may be growing. Hence if we have a feature which was requested to the team 1 year ago
and now we are exploring the same and asking the stakeholders about the feature . This may
not be a perfect situation.

a. Hence we need to balance capacity and demand.

b. We may need to drop out some work from backlog.
c. Hence we should limit WIP at upstream level . Hence we need this limiting at portfolio
level , the project and the initiates keeps getting approved and things land at team
backlog level and then team start to apply WIP. Hence we should better apply WIP
at the upstream level also so that demand and capacity balance is maintained.

M
SAFe® Principles | #7 – Apply cadence, synchronise with
cross-domain planning | SAFe®
https://www.youtube.com/watch?v=CSg1D1IVQPE

Cadence : It is like a rhythm so in Agile we have time boxed events . We can also have
non time based cadence . For example A doctor who is eye specialist and patient
goes to hospital and the process which the hospital has is making list of the people who
needs the doctor and then contacting the doctor and back to the patient it is then a
complicated process. Instead what doctors can do is Hospital publish a cadence of
doctor or rhythm of doctor. Like this doctor is available every wednesday 6 -7 p.m so if
we need consultation we can book the slot. Hence there is rhythm set and we can
decide which wednesday will be good for me. Of course for emergency section we can
walk anytime which is exception.
Cadence also makes wait time predictable and any uncertainty is limited to this
particular duration. Hence if there is any variance then that is limited to that particular
iteration. We learn from it and decide what to do better next time. So if we want to have
fast integrated cycle then there should be some kind of pattern to it. We need to
measure the progress based on objective evaluation of the system.More like a
schedule iteration with stakeholders and getting the team ready based on the rhythm.
Or one can say having iteration .

Synchronize with Cross Domain planning : Lets assume there are support staff for the
doctor so both parties' rhythm should be synchronized. Like both should be available
same time. So we need to synchronize different different domain area so that the
pattern starts matching. Like having feedback, integrated Plan.
Hence we have multiple team and there cadence should synchronize to have system
level view to know where we stand at a given point of time .
Hence Iteration start and end of different teams who are participating in same group as
ART are expected to be same so that they can do joint planning, learning as both teams
are ready at same time.

Team A and Team B should be synchronized in Planning .

Hence PI Planning is best example of the same.

SAFe® Principles | #8 – Unlock the intrinsic motivation

of knowledge workers | SAFe®

Process cannot take care of everything.We can make someone come to office but we
cannot make that person think creatively solving a problem. A person may or may not .
So we need to create an environment which promotes creativity , which promotes
people taking ownership which promotes people want to do challenging stuff.Hence we
need to focus on intrinsic motivation.
If we pay people enough then they need something else to motivate.So rewards , bonus
alone cannot motivate the person should have motivation, interest in the work which is
like intrinsic motivation.

➢ Providing the System VIew,

➢ Claririty of Work.
➢ Purpose of the work.
Involving various level of developers in the organization who are working in solving the
problem is something helps us aligning towards the purpose of our work. So giving
visibility and the meaning to the work is something a leader can provide to the team.

PI Planning is an example.

Team needs to be self organized so the team can give their estimation and also find a
better way to do the work. Team should be given autonomy.

Team should have ability to innovate and master the craft. Hence leaders should give
time and space to individual for innovation.

SAFe® Principles | #9 – Decentralise decision-making | SAFe®

We need to identify at what level decision is to be made. We should focus on making as many
as possible at the lower or decentralized level. We need to take economic and context in making
such plan.

Decentralist group are the team level

Centralized are at lean portfolio group or senior management group taking decision related to
those particular areas .
In Safe in order to identify the level we have Roles. Like at team level we have product
Owner,Portfolio Role etc. so this is decision distribution at team level versus portfolio level.

We can decide on decision which requires local information which needs to be taken fast so its
better to keep them decentralized we don't want to wait for approval for things which is expected
to get done within an hour and if the consequence of not doing within an hour is high then
something should be done at decentralized level.

Things which has large economic impact that we are committing some amount of money for that
and which may not happen that frequently and may require strategic and long term view may
be taken at centralised level.

Suppose in coffee shop we don’t like the coffee then serving person can change the coffee
without the manager approval. However if we want to partner with the coffee shop in business
then we need to talk to the owner of the coffee shop.

Decentralised Team Level : Should we fix this defect , should we move it to next iteration.
Story level decision can happen here.
 Program Level : Should we create this app , initiative or feature level as it has to be
understood which person and customer we are targeting. And more people need to be involved
.

Lean Portfolio Management : Where Ideas and Epic level decisions need to be made.

We need to make the team self organize, remove yourself as a bottleneck.

SAFe® Principles | #10 – Organize around value | SAFe®

➢ Rather than creating functional team at a small team level as well as agile release train
level what skill agile is promoting and i think general agile approach is also promoting is
creating cross functional team and that's whole idea of organizing around values.
➢ So if a customer is looking for some value , the team should be organized in such a way
that they can take a customer input and they can deliver the value in themselves. What
could be reverse of it is that you only do a part of the job . We do some thing and team is
over and other team takes care of it so there is a hands off like we are responsible for
creating and then someone else is responsible for packaging, and other team is
distributing.
➢ Whereas an organized team will take the order and work as one team there may be
different skills getting applied but the management structure, reporting , the
performance are one.
So here in this diagram we observe that suppose a requirement flows from Requiremetn
Analysis team to Dev team and there is a misunderstanding then the Dev team is not ready to
accept the change as it may impact his performance so RA team will go to his boss which in
turn talks to Dev team boss adn there is loss of time so at end of day its customer who is loosing
the value.
Solution is to create a value stream so that there is one big boss governing all the team and
hence there are less chances of conflicts.

➢ Operational Value stream : The value delivery to end customer may happen through
operation so let say I am bank and I am running a credit card operational value stream
which might be earning money by selling credit card products .
➢ and Development Value stream : Inside the operational value stream they might be
using various system to take care of there work so we may have group of individual who
may be taking care of enabling people to enroll to a credit card so there could be an
application which facilitates enrollment to a credit card and this particular application
require 100 people which can be grouped together as ART. This team has the clarity
that they are taking care of onboarding, new credit card customer related application.
The business User will give you a request everything needed for this application is part
of our group ,we design them, we develop them , we validate them, we test them , we
deploy them and we takke care of whole work that what we are focusing on and that also
 gives clarity on what kind of value we are delivering at the end. Thats whole idea of
development value stream.
➢ Cross functional team is old idea however here we observe that multiple team are
getting aligned to one goal.
➢

DAY 2 :

Customer Centricity : Scaled Agile Framerwork

https://www.youtube.com/watch?v=bMUAHmZXZIg

➢
We should be customer centric, where we find what kind of relationship our customer
are looking from us.Instead of We having something from customer we should find out
where our customer may get stuck while using the product over a period of time. How
can we assist them and what kind of expectation they have have from us.
So we should bring customer in the center where profit is something which supports
this.At same time we need to be profitable to serve the customer.
Weighted Shortest Job First (WSJF) in SAFe® - iZenBridge
If the size of two feature are same then we can pick that feature which has higher cost
of delay.

But a scenario where the Size of the Item is different then lets examine below scenario.
So we do first A in 5 days followed by B in 1 day and lastly C for 5 days so we observe
the total COD = 91

If we apply WSJF formula then we observe if we do B first then we are getting higher
WSJF thus helping us in having less cost of delay.

Let us look with the image to prove the theory the overall cost is 76 now.
Let us look into the way how SAFE comes into play.

The problem is that its not that easy to estimate COD and many times it requires good
amount of data collection. Hence we need to identify a relative faster model which helps
us in identifying relative cost of delay and Safe gives us that model to look into 3 D.
Instead of using duration one can replace it with Job size to identify it.
Cost of delay has 3 Dimension as below
User : Business Value

What is lifetime benefit of the feature, What kind of revenue we are going to get by
doing something.

Time Critically : How business value gets achieved over period of time.Job A has higer
business value but it declines over a period of time with less steep curve whereas Job B
its business value declines drastically .
So Job B is time critical if we dont deliver on time its value will decrease. So we need
to understand how business value of feature will decline over time. I.e if we do this
feature before christmas you make money.
Risk Reduction : Do we have a feature which may reduce the risk exposure. By doing
that feature at early stage we can mitigate things to be done at a later stage. Hence that
feature will go up in risk reduction.
If by doing a certain feature it increases our opportunity of achieving something in future
that too will go high into space.
Suppose we want to experiment with customer behavior and we want to add this feature
and this may not have business value in future but it helps me in learning something
which enables me to achieve different features so it enables the opportunity hence
those features will also go high in opportunity enablement.
Business Value is estimated life time impact of the feature

Question : Saket How do we measure the life time impact of the feature?

The way we look at the planning procrastination and development team size the work
so similarly the product management and the business owners who come together and
invite people who have insight on the business value and they are discussing in the
form of Wideband LC (Not sure on this term) or some other ways to come up on
numbers where they have agreement.

Now we move to TC: Is there anything which we need to do now so that overall
business value of that particular feature will evaporate so in a way in this particular case
we can assume none of them is TC so we put 1 across all.
RR-OE : We figure out which one is least impacting you . so we observe check out
may not mitigate any risk but user profile helps us enabling a lot of opportunity
because i can start learning about user in advance so this give me a lot of opportunity
enablement
Flexible search feature :We have pure performance criteria in place and there is
possibility that we may end up changing architecture if we don't achieve those flexible
performance criteria so doing flexible search mitigate the architectural risk which might
occur because of not having proven search mechanism so we can say this is little
higher as this helps in reducing risk and thus we can give 5 equivalent to User Profile
feature.

COD : We just need to sum the respective rows.

Job Size : It is a relative thing so need to find which one is smallest job. We have
system architect supported by selected team member or the people who have technical
knowledge and the product management plays a role in identifying the job size and
they discuss on various possible things which can go in this particular thing and based
on that the values are calculated.

WSJF : COD / Job size. Thus we observe that User profile is the first job to be done
.THus our overall goal is reducing the COD .

Enablers in SAFe (Scaled Agile Framework)

➢ It enables efficient development and delivery of future business requirements.

➢ There are different types of Enablers
a. Exploration Enablers : this are type of work which we do for learning
like prototype, proof of concept, SPIKE . Its something like we want to do ,
learn and throw away the code means we do not want to use the code as
it is but we want to use the learning. So coding guideline is not followed
but it provides the guideline. It can even be end customer behavior.
b. Architectural Enablers : It supports preparing or doing the work which
will be consumed by future business requirement .THis helps to create
foundational code which will exist in your application and they will support
future business requirement.
 c. Infrastructural Enablers : It helps in doing cleaning work or make our
development efficient . Suppose we want to do better way of integration
we may want to refine our build preparation scripts, we may want to
prepare tools which we are using or upgrade the version of the
development toolkit so infrastructure enablers helps us by creating
something which is not going to be our main code however helps to
improve software development.
d. Compliance Enablers : This are work which we do for external
compliance requirement like verification or validation in order to satisfy a
type of compliance need or it could be documentation need which gets
done for some compliance need

In SAFE enablers are implemented incrementally , they get sized ( we put Story point) ,
They also get counted in velocity, capacity of our work be to the team level or at
program level. Enablers can exit at any level .
Enablers Epic : The type which are big in nature and they exist at portfolio level.
Enablers Features and Capabilities : These are contained and stored at program
level and stored in Program backlog .
Enablers Stories : At team level we can call it Enablers stories.

➢ We need to agree upfront what percentage of work enables will take and what
percent feature is going to take.
➢ The priority is decided by system architect.
➢ Finally based on economic of work the priority is set.
Development Value Streams (1 of 3)

https://www.youtube.com/watch?v=cNMWfWMwfoQ
Technology management is our key area to look into. Here we need to apply safe

Operational Value stream (OVS) are the sequence of activities needed to deliver a
product or service to a customer
In the below image we have credit card value stream , Loan value stream and there are
different sequence of activities involved to generate a value stream like compliance, risk
management, finance.

**********************************************************************************
So we see the different operational value streams when a customer wants to have a
credit card system. In order to support this process Bank needs to have various system
which will support delivery of value to the customer . These services are supported by
set of system/solution like system in order to track the application. Hence whole
Operational stream is supported by set of systems.
There are group of people maintaining that system and that is development value
stream

Hence in this diagram we have 4 system which are managed by 3 development value
streams who maintain, support , improve the system.
Hence development Value stream is supposed to have completely end to end visibility.
So people who are exploring the requirement , people who are putting the things in the
release and are also evaluating are we really making sense or desired value are all
part of one group and thats how it becomes different from generic development
group.
Some people need to buy loan so they are potentially customer and inorder for them
to be captured we need a development team which creates an application so that we
can promote the loan. So these are people who discovering what needs to be done to
attract the leads so deve team work o multiple channel like web , IVR, ATM , Mobile .
We give advertisement to someone buying atm.
This is supported by one ART and it is working closely with business owners who are
coming from marketing, branding ,communication ,compliance ,legal and loan.
ARt is working with business stakeholders who are working in rest of the bank.

So there are 3 group in bank other than technology group one group wa focusing on
retail customers,another group on corporate customers and third was generic corporate
centeres. Which were working across branding, and communication and these all are
interacting closely from these areas with this particular development value stream
which is supported by ONE AGILE TRAIN.

We need to create one group to deliver to identify system which supports business.
Thus having common group common management , common goal,to the whole group
starting from identification till fulfillment . Thus having one group as a ART.
LA Lead acquisition, LMS loan management system , PM : Project management group.
On the right we have la as process integration group

Solution Vision (2 of 3)
On Boarding University is Epic and all are epic except Integration APi are enablers
.(which do not provide direct business Value) . Having open format APi so that we can
use it for other university.
Explained with a Bank Example: Epics and Features (3 of 3)
Lets look at lean business Case .
EPIC -> Feature -> US

So we have onboarding University as an epic and that epic will get implemented
incrementally with the help of feature and that epic is part of overall solution vision.
The solution is ultimately solving our business problem.
SAFe® PI Planning : Program Backlog
Readiness - 1 of 7
At the analysis stage we have a benefit hypothesis to be done. Then we add functional
as well as non functional acceptance criteria. These need to be elaborated enough
which helps us to estimate that particular feature.
Then estimates are done on a high level by the PM or architect and not at story point
level.The purpose is to ensure that it fits into one PI . Is it small enough to get into
program backlog or should we need to split it. So it helps in identifying how big the item
is and does it require further refinement before we put it into the program backlog.
Using WSJF we prioritize the item in the backlog.

Program backlog are list of refined item which are ready to be discussed In Pi
Planning.We need to put some size Limit so that it does not pile up.

So using Program Kanban board we understand that in the process of continuous

delivery we need to do continuous exploration such as Funnel , Analysing, Backlog and
then when we are developing we are focusing on continuous integration and when
deploy then continuous deployment similarly release on demand .
For a 10 week PI by 8th week we should have the program backlog ready to be
discussed in next Pi .Also we should not do it in 1 st week itself so that there are
chances to integrate the feedback or in case if portfolio makes some strategic change.

Readiness with Agile Teams - 2 of 7

➢ During Innovation and Planning Iteration , each team will get the first week for getting
ready for a PI Planning meeting.
➢ In second week all these teams will participate in PI Planning meeting.
➢ Suppose we get 10 feature which are expected to get in PI planning meeting.
➢ SO PM may do a collaboration with team level PO. where they identify the feature and
tentatively which team will work on which feature.
➢ Based on ART composition and history we can identify the team which is going to take
 the feature.
➢ So in the first week Team A , works on the backlog by picking the features and they also
consider the acceptance criteria while breaking them into User Stories. This is
coordinated by team level PO.
➢ Team are also required to estimate the US this is the bottom most level of estimation.
➢ Please note the estimation done at Program backlog refinement was to estimate that if
the feature is good enough or not to fit in the ART for one PI. But here we are doing at
base or bottom most level i,e US level. This estimation the team will use during the PI
Planning meeting. If there is any change then it can be done at 1st week of PI Plnning,
during Pi Planning and also at team level backlog refinement so total 3 stages as A, B,
C.
➢ Thus After point A, in Point B that is Pi Planning we get more insight on the feature , its
dependency so we may revisit the story size, Now at point C when Us is at team level
we may discover need of enablers or breaking further US in the team Backlog. Hence its
not necessary to have a very well defined US at point A.
➢ The acceptance criteria may be added at B or C level.
➢ These feature get implemented incrementally with the help of User Story.