- 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)
- 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.
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
No comments:
Post a Comment