Friday, August 31, 2018

scrum interview questions


What is “Agile”

It’s a set of guidelines that helps you deliver useful, valuable increments of software to customers at the end of each sprint (like two weeks). It is done by constantly re-prioritizing the backlog of requirements and reviewing incremental progress with the product owner.

What are the differences between Agile and traditional project management (Waterfall)?

Agile encourages that a little of everything, including design, development, and testing is done at the same time. Conversely, the traditional approach to projects closes and completes one phase before the next begins. Agile encourages short, frequent feedback loops and embraces changes to requirements. In Waterfall, feedback is usually not collected until the very end of the project, and changes are discouraged

When should you use Waterfall over Scrum?
Use waterfall if the requirements are simple, predictable, fully defined and understood, and will not change.

Name some other Agile frameworks.
such as Kanban, Test Driven Development, and Feature Driven Development.

What are the most important components of Agile?

    Daily stand-up meetings.

    CRC (Class Responsibilities and Collaborators) cards

    timeboxed task boards.

    TDD (Test Driven Development), Continuous Integration, regular code reviews, pair programming, automated builds, continuous deployment and delivery, etc.

    You have iteration planning meetings and carry out iterative development.



How study Board can be defined in agile?

A Story Board is a visual representation of a software project’s progress. There are generally four columns ‘To do’, In Progress’, ‘Test’, and ‘Done’. Different colored post, its notes are placed in each column indicating the progress of individual development items. A story board is typically used in agile development.



What do daily stand up meetings entail?

This meeting addresses SCRUM’s three questions listed below.
– What have you completed since the last meeting?
– What do you plan to complete by the next meeting?
– What is getting in your way?

What is the Daily Stand-Up?
Every day, preferably in the morning, the team meets for no more than 15 minutes to answer three questions:
What did you do yesterday?
What do you plan on doing today?
Are there any blocks or impediments that keep you from doing your work?
This Scrum ceremony is not meant to be a status meeting for stakeholders, but a way to energize the team and get them to set focus for the day.


What is a Release candidate?

A Release candidate is a build or version of software that can be released to production.

Further, testing such as UAT may be performed on this version of the product.



What is difference between Epic, User stories & Tasks?
Epic is a group of related user stories.
User Stories define the actual business requirement. Generally created by the business owner.
Task: To accomplish the business requirements, development team create tasks.



Explain Velocity in Agile?
Velocity is a metric that is calculated by addition of all efforts estimates associated with user stories completed in one iteration. It predicts how much work Agile can complete in a sprint and how much time will it require to complete a project.

What is velocity?
Velocity is the average number of points from that past 3 – 4 sprints. It is used to help predict when backlog items will be delivered.

How the velocity of sprint is measured?
If capacity is measured as a percentage of 40 hours weeks then
completed= story points * team capacity
If capacity is measured in man hours then
completed story points / team capacity.


Have you ever tracked velocity? How would you determine a teams Sprint velocity?
Team velocity is tracked, using the number of estimated story points, over the actual completed story points.
This can be measured on the burndown chart. You can guess your team velocity overtime, from the previous sprints

Explain what is a product backlog in Scrum?
Before the scrum sprint initiates, product owner reviews the list of all new features, change requests, enhancements and bug reports and determines the priority.

What type of metrics or reports have you used?
Sprint, release burn-down and burn-up charts are standard reports

What does a scrum burn down chart comprise?
A scrum burn down chart should consist of
    X-axis that displays working days
    Y-axis that displays remaining effort
    Ideal effort as guideline
    Real progress of effort

What is a burn-down chart?
A burn-down chart displays the amount of work a team has burned through—such as hours during the sprint

What is a retrospective?
A retrospective is a meeting to inspect and adapt the process

What is Scrum Sprint?
A Scrum Sprint is a regular, repeated work cycle in scrum methodology during which work is completed and made ready for review.
Generally, scrum sprints are less than 30 days long.

Describe what happens in the Sprint planning meeting.
In Sprint planning, the Product Owner presents the goal of the sprint and discusses the high priority product backlog items. The Delivery team then chooses the amount of work for the next sprin

What are the roles in Scrum?
Scrum prescribes only three roles: the Product Owner, Scrum Master, and the Delivery Team.
These roles should ideally be cross-functional and not shared among other projects.

What is the role of the Scrum Master?
The Scrum Master serves the team and shields them from any distractions that could prevent them from completing a sprint goal.
They also remove blocks, teach the team to become self-organized and serve as a coach who teaches Agile and Scrum values and principles

How many Scrum teams have you managed at one time?
Notice the use of the word “managed” versus “led.”  Scrum Masters do not manage, they lead teams.you may be required to lead more than one team

What are the artifacts of Scrum process?

Sprint backlog – The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment

Product backlog – The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

Velocity chart- A velocity chart shows the sum of estimates of the work delivered across all iterations

Burn-down chart – It is a chart that shows how quickly you and your team are burning through your customer’s user stories. It shows the total effort against the amount of work we deliver on each iteration.



https://intellipaat.com/interview-question/agile-scrum-master-interview-questions/
https://www.glassdoor.com/Interview/us-project-manager-scrum-master-interview-questions-SRCH_IL.0,2_IN1_KO3,31.htm
https://easybacklog.com/
https://www.simplilearn.com/agile-scrum-master-interview-questions-article


  • What is Kanban? 

Kanban is a method for managing the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.
Kanban is based on 3 basic principles:

    Visualize what you do today (workflow): seeing all the items in context of each other can be very informative
    Limit the amount of work in progress (WIP): this helps balance the flow-based approach so teams don€™t start and commit to too much work at once
    Enhance flow: when something is finished, the next highest thing from the backlog is pulled into play

https://www.versionone.com/what-is-kanban/

Scrum


  • Scrum (software development)

Scrum is an agile framework for managing work with an emphasis on software development.
It is designed for development teams of between three to nine members who break their work into actions that can be completed within timeboxed iterations, called sprints (30 days or less, most commonly two weeks) and track progress and re-plan in 15-minute stand-up meetings, called daily scrums

Scrum is an iterative and incremental agile software development framework for managing product development.
https://en.wikipedia.org/wiki/Scrum_(software_development)


  1. Product Backlog: an ordered list of the work to be done in order to create, maintain and sustain a product. Managed by the Product Owner.


Sprint Planning: time-boxed event of 8 hours, or less, to start a Sprint. It serves for the Scrum Team to inspect the work from the Product Backlog that’s most valuable to be done next and design that work into Sprint backlog.

Sprint Review: time-boxed event of 4 hours, or less, to conclude the development work of a Sprint. It serves for the Scrum Team and the stakeholders to inspect the Increment of product resulting from the Sprint, assess the impact of the work performed on overall progress and update the Product backlog in order to maximize the value of the next period.

Daily Scrum: daily time-boxed event of 15 minutes, or less, for the Development Team to re-plan the next day of development work during a Sprint. Updates are reflected in the Sprint Backlog.

Sprint Retrospective: time-boxed event of 3 hours, or less, to end a Sprint. It serves for the Scrum Team to inspect the past Sprint and plan for improvements to be enacted during the next Sprint.

Sprint: time-boxed event of 30 days, or less, that serves as a container for the other Scrum events and activities. Sprints are done consecutively, without intermediate gaps.

Scrum Team: a self-organizing team consisting of a Product Owner, Development Team and Scrum Master.

Scrum Master: the role within a Scrum Team accountable for guiding, coaching, teaching and assisting a Scrum Team and its environments in a proper understanding and use of Scrum

Product Owner: the role in Scrum accountable for maximizing the value of a product, primarily by incrementally managing and expressing business and functional expectations for a product to the Development Team(s).

Burn-down Chart: a chart showing the evolution of remaining effort against time. Burn-down charts are an optional implementation within Scrum to make progress transparent.

Velocity: an optional, but often used, indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team

Increment: a piece of working software that adds to previously created Increments, where the sum of all Increments -as a whole - form a product.

https://www.scrum.org/scrum-glossary


  • scrum framework

https://s3.amazonaws.com/scrumorg-website-prod/drupal/2016-06/ScrumFramework_17x11.pdf


  • The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.

Scrum Teams are self-organizing and cross-functional.
Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team
Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team
https://www.scrum.org/resources/what-is-scrum


  • Professional Scrum Developer™ (PSD) is a 3-day course where students make up an entire Scrum Team where they concurrently do requirements engineering, design, development, testing, integration and deployment within a single iteration.


Course Topics

    Using Scrum
    Working within a Scrum Team
    Definition of Done
    Development Practices
    Test Driven Development
    Pair Programming
    Code Review
    Using ALM tools with Scrum


https://www.scrum.org/courses/professional-scrum-developer-java-munchen-2017-10-18-7795


  • The Scrum Events

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum
All events are time-boxed.
Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.
    Sprint
    Sprint Planning
    Daily Scrum
    Sprint Review
    Sprint Retrospective

Scrum Artifacts
Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation.
    Product Backlog
    Sprint Backlog
    Increment
https://www.scrum.org/resources/what-is-scrum


  • iceScrum is a web application for using Scrum while keeping the spirit of a collaborative workspace. It also offers virtual boards with post-its for sprint backlog, product backlog and others.

https://github.com/icescrum/iceScrum


  • Planning Poker® is a consensus-based estimating technique. Agile teams around the world use Planning Poker to estimate their product backlogs

To start a poker planning session, the product owner or customer reads an agile user story or describes a feature to the estimators.
Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.
The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.
If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.

The poker planning process is repeated until consensus is achieved or until the estimators decide that agile estimating and planning of a particular item needs to be deferred until additional information can be acquired.

How does poker planning work with a distributed team?

Simple: go to PlanningPoker.com.  A product owner, ScrumMaster or agile coach can log in and preload a set of items to be estimated. A private URL can then be shared with estimators who log in and join a conference call or Skype session. Agile estimating and planning then proceeds as it would in person.

https://www.mountaingoatsoftware.com/agile/planning-poker


  • What’s a Spike?


Sometimes a story is too large or overly complex. Perhaps the implementation or a 3rd party tool or library is poorly understood. The team can’t estimate the story. Perhaps we’re unsure if we’ll be able to complete the story due to some potential blocker.
In these cases, we might want to build a functional or technical experiment to figure it out. We might want to look into something for a day. We might want to look up alternatives. Do some googling. Do an experiment with some other library or software package. Consider alternative refactoring paths.
In these cases, we might want to build a functional or technical experiment to figure it out. We might want to look into something for a day. We might want to look up alternatives. Do some googling. Do an experiment with some other library or software package. Consider alternative refactoring paths.
https://www.leadingagile.com/2016/09/whats-a-spike-who-should-enter-it-how-to-word-it/


  • The first sprint


Now that the prep work?whether in the form of a DAD Inception phase, a "sprint zero," or a "project before the project"?has been completed, it's time for that first sprint.
Your first agile sprint is a baseline and getting everything "right" isn't as important as getting the team to understand the general spirit of agile. The iterations are short so the team should be able to quickly gather feedback and continue to adapt and improve over time.

https://techbeacon.com/your-first-agile-sprint-survival-guide



  • Weighted Shortest Job First is a technique for a) assigning a weight, or value, to each job, and then b) dividing that by the length of the job, in order to c) determine a relative ranking

https://techbeacon.com/prioritize-your-backlog-weighted-shortest-job-first-wsjf-improved-roi

 Weighted Shortest Job First (WSJF) is a technique for backlog prioritization recommended by Dean Leffingwell. The calculation involves measures for User Value, Time Value, Risk Reduction / Opportunity Enablement Value, and Job Size::

WSJF = (User Value + Time Value + RROE Value) / Job Size
https://www.scrum.org/forum/scrum-forum/5509/weighted-shortest-job-first


  • Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.

https://www.scruminc.com/velocity/

  • Large-Scale Scrum (LeSS)

a lightweight (agile) framework for scaling Scrum to more than one team.
LeSS consists of the LeSS Principles, the Framework, the Guides and a set of experiments. The LeSS framework is divided into two frameworks: basic LeSS for 2-8 teams and LeSS Huge for 8+ teams.
https://www.agilealliance.org/resources/sessions/introduction-to-large-scale-scrum-less/

Scaling Scrum starts with understanding standard one-team Scrum. From that point, your organization must be able to understand and adopt LeSS, which requires examining the purpose of one-team Scrum elements and figuring out how to reach the same purpose while staying within the constraints of the standard Scrum rules.

LeSS provides two different large-scale Scrum frameworks.
The two frameworks – which are basically single-team Scrum scaled up – are:
    LeSS: Up to eight teams (of eight people each).
    LeSS Huge: Up to a few thousand people on one product.

In LeSS, you will find:
    a single Product Backlog (because it’s for a product, not a team),
    one Definition of Done for all teams,
    one Potentially Shippable Product Increment at the end of each Sprint,
    one Product Owner,
    many complete, cross-functional teams (with no single-specialist teams),
    one Sprint
https://less.works/less/framework/index.html


  • Scaled Agile Framework® (SAFe®) empowers complex organizations to achieve the benefits of Lean-Agile software and systems development at scale.
    SAFe is designed to help businesses continuously and more efficiently deliver value on a regular and predictable schedule.  It provides a knowledge base of proven, integrated principles and practices to support enterprise agility.
https://www.scaledagileframework.com/

The Scaled Agile Framework (abbreviated as SAFe), is a set of organization and workflow patterns intended to guide enterprises in scaling lean and agile practices.
https://en.wikipedia.org/wiki/Scaled_agile_framework
  • In traditional scaling frameworks, specific practices (e.g. daily standups) are how the framework is executed, whereas the Spotify model focuses on how businesses can structure an organization to enable agility.

Key elements of the Spotify model

Squads
Similar to a scrum team, Squads are cross-functional, autonomous teams (typically 6-12 individuals) that focus on one feature area. Each Squad has a unique mission that guides the work they do, an agile coach for support, and a product owner for guidance. Squads determine which agile methodology/framework will be used.

Tribes
When multiple Squads coordinate within each other on the same feature area, they form a Tribe. Tribes help build alignment across Squads and typically consist of 40 - 150 people in order to maintain alignment.Each Tribe has a Tribe Lead who is responsible for helping coordinate across Squads and for encouraging collaboration.

Chapter
Even though Squads are autonomous, it’s important that specialists (e.g. Javascript Developer, DBAs) align on best practices. Chapters are the family that each specialist has, helping to keep engineering standards in place across a discipline. Chapters are typically led by a senior technology lead, who may also be the manager for the team members in that Chapte

Guild
Team members who are passionate about a topic can form a Guild, which essentially is a community of interest. Anyone can join a Guild and they are completely voluntary. Whereas Chapters belong to a Tribe, Guilds can cross different Tribes. There is no formal leader of a Guild. Rather, someone raises their hand to be the Guild Coordinator and help bring people together.

Trio
The Trio (aka TPD Trio) is a combination of a Tribe Lead, product lead, and design lead. Each Tribe has a Trio in place to ensure there is continuous alignment between these three perspectives when working on features areas.

Alliance
As organizations scale, sometimes multiple Tribes need to closely work together to accomplish a goal. Alliances are a combination of Tribe Trios (typically three or more) that work together to help their Tribes collaborate on a goal that is bigger than any one Tribe.

Squads may have ceremonies like sprint planning and retrospectives, but the focus of the Spotify model is on how teams organize around work. It’s up to Squads to figure out the best way to get the job done.

The benefits of the Spotify model

Less formal process and ceremony

More self-management and autonomy
The Spotify model focuses on decentralizing decision making and transferring that responsibility to Squads, Tribes, Chapters, and Guilds.

The challenges of the Spotify model

Some organizations experienced more success than others, but it’s likely no organization experienced the same success as Spotify. The reason? Like any way of working, an organization's current culture and structure need to be taken into account. The model is simple, but the environment it's implemented in is complex.

To some, it may seem like a simple matrix organizational structure where people report to a functional area (Chapter), but work with a cross-functional team (Squad).
Although it may look like a matrix organization, the key cultural elements of the model need to be in place to allow the structure to thrive, such as trust and autonomy.
If an organization doesn’t shift its behaviors (and ultimately its culture), the benefits of the Spotify model will never be realized. 

Spotify model best practices

Don’t copy the model
Seek to understand the structure, practices, and mindset behind Spotify’s approach. With that understanding, tweak the aspects of the model to fit your own environment. Your goal is not to be Spotify, but to leverage their model to improve how your organization works together.

Autonomy and trust is key
Allowing teams to pick their own development tools and modify another team's code are just some examples. Within your organization, determine if there are decisions that can be pushed to the teams instead of being mandated by parts of the organization that are disconnected from the day-to-day work.

Transparency with community
Establish your first Guild around the Spotify model adoption and encourage participation from everyone in the organization. Build trust by creating transparent, inclusive ways to gather feedback, and gain alignment on how your organization wants to work in the future.

Encourage mistakes
Spotify doesn’t leverage the original implementation of the Spotify model anymore; they evolved and adapted the model to fit their changing organization. Trios and Alliances are actually newer elements in Spotify as they were brought about to solve new problems the organization faced as it grew larger. 


https://www.atlassian.com/agile/agile-at-scale/spotify

  • Dunbar's number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships—relationships in which an individual knows who each person is and how each person relates to every other person

https://en.wikipedia.org/wiki/Dunbar%27s_number


  • Scaled Agile Framework (SAFe): 
The current version is SAFe 5.1, which got revised in February 2021. It has four constructs — Essential SAFe, Large Solution SAFe, Portfolio SAFe, and Full SAFe. It would be best if you had either portfolio or full SAFe to achieve business agility through SAFe. The SAFe structure grows when you move from one level to another by adding new roles and responsibilities.

Large-Scale Scrum (LeSS):
It developed by taking Scrum and trying many different experiments to discover what works. In 2013, the experiments were solidified into the LeSS framework rules.
Opposite to SAFe, LeSS talks about descaling Structure and organizational complexity to enable simplicity at scale.

Spotify Model Framework:
Spotify model talks about Squad, tribe, chapter, and gild, where the squad is a cross-functional team designed based on the customer journey.
The tribe is a collection of squads, and the chapter is more like a community of practices. However, the definition of chapter and tribe has changed a lot lately, where it gives a feeling of a matrix organization. The Spotify model doesn’t have any rules or guidelines publicly available like SAFe and LeSS. It gives many organizations a quick win because of multiple factors, including renaming the existing team as a squad. In the Spotify model, teams usages LeSS, SAFe, Scrum, or Kanban at the squad or tribe level.

Nexus Framework
Nexus is similar to LeSS from outside minus nexus integration team. It is a framework build upon Scrum but keeps Scrum untouched. If multiple teams work on the same product and experience coordination chaos, then Nexus may be helpful. A Nexus is a group of approximately three to nine Scrum Teams who work together to deliver a single product; it connects people and things. A Nexus has a single Product Owner who manages a single Product Backlog from which the Scrum Teams work. Unlike LeSS, Nexus doesn’t come up with its principles and uses the Scrum framework’s principles.

Look at some simple parameters to decide:

    Is it about product development or service delivery?
    Are you talk about program/portfolio or products?
    How difficult to change the core system?
    Are you a multi-site, distributed team?
    Do you have challenges with alignments?
    Is it a coordination problem because of silos?
    What’s your priority? Innovation or Improvement?
    Are you running some digital transformation?


https://agilemania.com/safe-vs-less-vs-spotify-or-nexus-to-be-agile/


        


  • Assessment of 6 approaches to scale Scrum

LeSS stays closest to Scrum’s purpose 

Scrum@Scale is Scrum scaled for the whole organisation

Spotify Engineering Culture may be a best fit for component teams

SAFe puts the purpose of Scrum under heavy pressure due to it’s top-down approach, additional layers and as a result additional roles, events and artifacts.


Spotify allows for a lot of autonomy for the teams to work according to Scrum. The focus on small decoupled systems however is a different perspective than Scrum’s perspective of optimizing the value of a product. Spotify can be your scaling approach of choice if you don’t have the concerns of systems vs product.
https://medium.com/serious-scrum/assessment-of-6-approaches-to-scale-scrum-46319fcbca1a

  • SAFe®  vs. Scrum@Scale

The Scaled Agile Framework
It is essential to note that SAFe®  is intended to accommodate DevOps, a process frequently deemed for future-proof Agile organizations.
It is most desirable for large organizations to retain as much organizational and process structure as possible while reaping the advantages of a decentralized Agile method.
SAFe®  is not as efficiently customizable as Scrum at Scale

Scrum@Scale
The Scrum@Scale structure is easily manageable but hard to master. It is made up of 2 cycles, the Scrum Master cycle and Product Owner cycle, and 12 components necessary to execute Scrum at scale.


SAFe®  vs. Large-Scale Scrum (LeSS)

Scaled Agile Framework
Benefits of SAFe®
SAFe®  separates business strategies into actions, then features, then stories of work at the team level, and maps the pathway.
Drawbacks of SAFe®
The implementation pathway is required to be tweaked to meet the requirements of your organization

Large Scale Scrum (LeSS)
A necessary characteristic of LeSS comprises redirecting team awareness over the entire organization.
Limitations of LeSS
    Scaling only works for an organization which has an extensive Scrum foundation    
    LeSS is formed around Scrum and is not a straightforward extension of other methodologies.    
    A single Product Owner may attempt to control multiple teams


SAFe®  vs Spotify

Spotify: a lightweight framework
Unlike SAFe®, the Spotify model is not considered an extensive toolbox. The Spotify model contributes a relatively lightweight framework that stresses the necessity to generate many interactions to limit the silo side formed by teams.
It would be essential to determine how every team must work in a standard way or have 100% freedom provided to the groups. Moreover, the Spotify model doesn’t deliver any solution to control the Portfolio like SAFe®.

SAFe®  a heavy framework
Unlike the Spotify model, everything is already fixed, and only an expert can be expected to have the imagination to improve it.

Challenges of scaling agile principles and practices

The Scaled Agile Framework discusses the obstacles encountered when scaling agile beyond a single team.


https://www.knowledgehut.com/blog/agile/safe-vs-scrum-scale-vs-less-vs-spotify
scrum team becomes squad team
scrum is an agile development approach
agile > scrum
scrume master becomes agile coach
servant leader > process master
autonomous squad
cross-functional squad
self-organizing squad
# members < 8
autonomy is what to build
autonomy is how to build
autonomy is how to work together to build 
loosely coupled squad
tightly aligned squad
alignment vs autonomy graph sections 1,2,3,4 detailed
section 1 - low alignment low autonomy
section 1 - micro management culture
section 1 - shut up and follow orders
section 1 - no high level purpose
section 2 - high alignment low autonomy
section 2 - leaders are good at what problems need to be solved
section 2 - leaders tell people how to solve problem
section 3 - high alignment high autonomy
section 3 - leaders focus on what problem is solved
section 3 - leaders let the team figure out how to solve the problem
section 1 - low alignment high autonomy
section 1 - teams do whatever they want
section 2 tells how to solve, section 3 lets people decide on how to solve
alignment enables autonomy
leader's job is to communicate what problem needs to be solved and why.
tribe is a group of squads
team member is  squad and chapter member
guild - communicating via mailing list
infra squad
client app squad
feature squad
infra squad is on CD, operations, tools for squad, monitoring etc
self-service model
infra enables teams serve themselves
feature toggle is unfinished hidden feature
feature toggle is for A/B testing, integration testing
unmerged code hides problems
feature toggle reduces the need for code branches
fear kills trust and innovation

fail fast - learn fast - improve fast - long term strategy
driven from below, supported from above - continuous improvement
limited blast radius via decoupled architecture
lean startup - idea/problem - narrative + prototypes - build Minimum Viable Product - Release
toyota improvement kata

  • This practice of practicing a routine until it became a refined habit now extends beyond martial arts and into business. 
the Toyota Motor Corporation developed continuous improvement through practiced patterns.
This technique, called Improvement Kata
Improvement Kata is a method where team leaders and members continually practice a kata routine that develops and channels their abilities to problem-solve. Over time, the practices become second nature.

 It seeks to do so with a four-part model:

    Understand the direction or challenge
    Grasp the current condition
    Define the target destination
    Move toward the target iteratively, which reveals obstacles to overcome


These techniques are particularly helpful when the route to a destination is unclear, as experimentation can help you better understand the problem and find unique solutions. 

What are the benefits of Improvement Kata? 

Teams aligned toward a single goal 
Experimentation leads to results 
Reduce waste significantly 


What are some examples of Improvement Kata?

Say you want to build a new service based on an idea, but you’re not sure whether it will work. Rather than trying to get every layer perfectly worked out and incrementally expanding it until it’s feature-complete, try picking a target that delivers some value and brings you closer to the system you envisioned. You’ll probably have lots of unknowns, but you can learn a lot from challenges, and experiment with different ideas to find one that works. Once it does, reevaluate where you are, pick your next target, iterate, and reflect on your progress.


What are the differences between Improvement Kata and lean?

Kata and lean are different, yet compliment each other. Kata and Lean are different in many ways. Lean refers to processes to be implemented while kata refers to techniques to be practiced. Thus, kata became a mainstream business practice when Toyota adopted it into its lean production system. When combined into a unified approach, these concepts provide powerful results. 


https://www.atlassian.com/agile/agile-at-scale/using-improvement-kata-to-support-lean