Welcome to triksbuddy blog. He we discuss on different technology, tips and tricks, programming, project management and leadership. Here we share technology tutorials, reviews, comparison, listing and many more. We also share interview questions along with answers on different topics and technologies.
Stay tuned and connected with us and know new technologies and dig down known ones.
In this video, I will show you how to email large files with Gmail, Yahoo or any other email. Every email services has a maximum size limit for sending attachment files in an email.
Gmail’s attachment limit is 25MB, yahoo also limited to 25 MB where as other email clients have less size limit. However when you really need to send large size file to someone how you will do it? This video gives you a solution using sendtransfer.com. Sendtransfer.com allows us sending upto 10 GB file in single transfer without registration.
Send Transfer site: https://www.sendtransfer.com/
if you are interested with google services than I have another video on how to sent large attachment in gmail using google drive: https://youtu.be/ct0FCuZ2k2A
Please watch till the end of the video, I hope you will enjoy it. If you have enjoy the video, please go ahead and like it.
Write us in comment how helpful this video for you. If you think this might be helpful for your friends, Please share the video with your friends.
If you have any question, regarding the video, Please write us through comments.
Please join in our community through subscription of channel and subscription of video notification.
In triksbuddy channel, you will get different interesting tech stuffs that will help you enrich your technology knowledge. Please subscribe our channel to get updates of our videos.
Subscription link:
https://goo.gl/GE4g8v
Please subscribe in below link and like our video.
Subscription URL: https://goo.gl/GE4g8v
Channel URL: https://goo.gl/VYi58K
Most Recent Videos: https://goo.gl/hXFN4w
Most Popular Video: https://goo.gl/7u7B1x
This video show 5 difficult landing video in Madeira Airport. Some are failed landing and some are very hard to land.
Cristiano Ronaldo Madeira International Airport, commonly known as Madeira Airport or Funchal Airport, is an international airport in the civil parish of Santa Cruz in the Portuguese archipelago and autonomous region of Madeira.
The airport is located 13.2 km (8.2 mi) east-northeast of the regional capital, Funchal, after which it is sometimes informally named. It mostly hosts flights to European metropolitan destinations due to Madeira's importance as a leisure destination, and is pivotal in the movement of cargo in and out of the archipelago of Madeira. It is the fourth-busiest airport in Portugal.
The airport is named after Madeiran football player Cristiano Ronaldo.
The airport is considered one of the most peculiarly perilous airports in the world due to its location and its spectacular runway construction. It received the Outstanding Structure Award in 2004 by the International Association for Bridge and Structural Engineering. The History Channel program Most Extreme Airports ranked it as the ninth most dangerous airport in the world and the third most dangerous in Europe. Pilots must undergo additional training to land at the airport.
Madeira, an autonomous region of Portugal, is an archipelago comprising 4 islands off the northwest coast of Africa. It is known for its namesake wine and warm, subtropical climate. The main island of Madeira is volcanic, green and rugged, with high cliffs, pebbly beaches and settlements on deltas of the Fajã River. Capital Funchal has botanic gardens and is known for its harbor and a large New Year's fireworks show.
Uganda is an East African country known for Lake Victoria, mountain gorilla habitats & vibrant capital Kampala.
Here is the list of top 10 tourist destinations in uganda:
1. Queen Elizabeth National Park
Attractions: Ugandan national park, with Lake Katwe, hippos in the Kazinga Channel & leopards on Mweya Peninsula.
Queen Elizabeth National Park occupies an estimated 1,978 square kilometres (764 sq mi). The park extends from Lake George in the north-east to Lake Edward in the south-west and includes the Kazinga Channel connecting the two lakes.
Queen Elizabeth National Park is known for its wildlife, including African buffalo, Ugandan kob, hippopotamus, giant forest hog, warthog, Nile crocodile, African bush elephant, African leopard, lion, and chimpanzee. It is home to 95 mammal species and over 500 bird species.
2. Murchison Falls National Park Uganda
Attractions: Ugandan national park, known for Murchison Falls, Lake Albert Delta & Kaniyo Pabidi mahogany forest.
Murchison Falls National Park is a national park in Uganda and managed
by the Ugandan Wildlife Authority. It is in north-western Uganda,
spreading inland from the shores of Lake Albert, around the Victoria
Nile, up to the Karuma Falls.
Together with the adjacent 748 square kilometres Bugungu Wildlife
Reserve and the 720 square kilometres Karuma Wildlife Reserve, the park
forms the Murchison Falls Conservation Area.
3. Bwindi Impenetrable National Park
Attractions: Forested national park in Uganda, home to endangered mountain gorillas, plus birds & butterflies.
The Bwindi Impenetrable National Park is in southwestern Uganda. The
park is part of the Bwindi Impenetrable Forest and is situated along the
Democratic Republic of the Congo border next to the Virunga National
Park and on the edge of the Albertine Rift. Composed of 321 square
kilometres of both montane and lowland forest, it is accessible only on
foot. BINP is a United Nations Educational, Scientific and Cultural
Organization-designated World Heritage Site.
4. Lake Mburo National Park
Attractions: Wetlands with lodging & safari tours
Lake Mburo National Park is a national park located in Nyabushozi County, Kiruhura District near Mbarara in Uganda.
5. Lake Bunyonyi
Attractions: Island-filled lake with canoe tours
Lake Bunyonyi is in south-western Uganda between Kisoro and Kabale, and
it is close to the border with Rwanda. The lake appeared from 2004 to
2009 on the 5,000 Ugandan shilling note under the title "Lake Bunyonyi
and terraces". Scientific literature generally quote a maximum depth of
40 m, but some tourist guides and locals insist that it much deeper,
about 900 m, which would make it the second-deepest lake in Africa.
Towns on its shores include Kyevu and Muko, while its 29 islands include
Punishment Island and Bushara Island.
6. Rwenzori Mountains National Park
Attractions: Africa's third highest mountain peak and many waterfalls, lakes, and glaciers.
Rwenzori Mountains National Park is a Ugandan national park and UNESCO
World Heritage Site located in the Rwenzori Mountains. Almost 1,000 km²
in size, the park has Africa's third highest mountain peak and many
waterfalls, lakes, and glaciers. The park is known for its beautiful
plant life.
7. Bulago Island
Attractions: Safari, lake, and honeymoon
8. Ndere Centre
Attractions: Folk dance
9. Itanda Falls
Attractions: Scenic Spot
The Itanda Falls are rapids on the White Nile river in Uganda. They are a
challenge for kayakers, being graded at the highest level of difficulty
Large Scale Scrum (LeSS) takes a completely different approach to
scale. In fact, the term that LeSS uses is NOT scale, but De-Scaling as
the pinnacle of the scaled organization for Scrum and Agile.
Where other frameworks look to align the Agile approach to teams
within a Traditional Organization, or show how those people can now
"fit" within the organization; the LeSS approach is to say 'no.' No more
"pretend Agile" or "Fake De-Scaling" where all the parts of the
products that come together are considered independent and managed
independently.
This leads to trap where teams try to act as independent teams within an organization:
"Independent Teams" need a portfolio manager to ensure alignment of efforts, because otherwise they'll diverge
Portfolio Management leads to integration and dependencies,
Dependencies re-introduce the need for the Program Management Office (PMO) to institute rules of coordination
Rules remove ownership and power from the Scrum teams, and quickly lead to additional complex teams to manage them
To avoid all this, the LeSS system provides two types of scaling of Products to remove other potential roles:
LeSS - used for up to eight (8) teams of eight
LeSS Huge - used for up to thousands of teams delivering products together in single increments
This way the organization can avoid unnecessary "dotted lines" that
take away power and control from the Scrum Teams which in turn zaps
productivity and pride of workmanship.
The LeSS system provides two types of scaling of Products to remove other potential roles:
LeSS - used for up to eight (8) teams of eight
LeSS Huge - used for up to thousands of teams delivering products together in single increments
This
way the organization can avoid unnecessary "dotted lines" that take
away power and control from the Scrum Teams which in turn zaps
productivity and pride of workmanship.
According to the philosophy behind LeSS, Scrum works as it is
designed for one team. And it shouldn't be changed for one team. No
matter the complexity of the product, it should remain that there are
three roles:
Product Owner (PO)
Scrum Master (SM)
Development Team Member (DT)
And in the LeSS these roles persist and remain the only roles for up
to eight (8) teams. It's important to note that LeSS suggests that teams
be aligned to features to maximize their ability to "specialize" on the
architecture of a product and work independently.
Beyond eight (8) teams only one additional role is added to support
the Product Owner. This role is the Area Product Owner, and they are
needed because of the pressure on the Product Owner to manage such a
large backlog is too great:
Area Product Owner (APO) - provides a buffer of work definition and
act as intermediaries to help manage an "area" of requirements
Product Owner (PO) can have up to ten (10) APOs working with them to manage requirements, forming the Product Owner Team
Can manage up to eight teams
Cannot override the prioritization of the product backlog items - this still belongs to the PO
At this point there is enough "scaling" that it can handle global
operations of product development. Sites can have multiple teams, and
areas can include anywhere from five to ten teams. When multiplied this
allows a single Product Owner to manage up to a thousand or more team
members.
But why create such large structures of Scrum?
The answer is using Large Solutions to De-Scale the organization.
Organizations looking to create smaller, more independent teams to Scrum
will drive towards an model that performs "Fake De-Scaling." These
ideas are as follows:
We create "independent" teams with internal and external markets, everyone has customers and are consumers of Agile teams
For
larger products, "independent Teams" need a portfolio manager to ensure
alignment of efforts, because otherwise they'll diverge
Portfolio Management leads to integration and dependencies because there are real-word physical dependencies in products
Integration and dependencies drive the need for rules so teams can stay independent
These rules re-introduce the Program Management Office (PMO) to control coordination
Rules remove ownership and power from the Scrum teams, and quickly lead to additional complex teams to manage them
So what does the organization then look like for the LeSS company?
For those that there will be an enabling leader who is the "Head of
Product." This person will provide coordination and support using the
Servant Leadership model of management. The responsibilities include
managing:
Site Locations - ensuring the teams are supported with facilities, people, etc.
"Undone Departments" - those departments that are still functionally aligned or separate from Scrum Teams
Support Teams - these teams provide a lean service of support to the large teams (such as delivery or DevOps)
Product Owner Team - led by the PO in charge of the product, this team develops and prioritizes the backlog
Competence & Coaching - the functions of training and coaching to ensure continuous improvement
Higher levels of management are intended to provide similar types of
"servant leadership" support for the organization. The goal being to
enable teams to work according to the LeSS principles:
Large-Scale Scrum is Scrum - LeSS is just dealing with the unavoidable scale of some products, but remains scrum
Empirical process control - processes should be subordinate to the product and market needs
Transparency - required to drive fear out and improvement into the workplace
More with Less - gain better teams, ownership, and reduced waste with less process and control
Whole-products - focus on the product in delivery, not just the part of the product, so efforts are aligned
Customer-centric - by focusing on the customer, everyone aligns to
the priorities and needs while reducing waste of other distractions
Systems thinking - understand that the system is the focus, not the
local performance of a team, so waste is reduced and flow is optimized
Lean thinking - continuous improvement and the Go See approach to
management drive a respect for workers and continuous improvement
Queuing theory - understanding that long queues increase cycle time,
reduce feedback speed, increase variability, and result in
multi-tasking
Disciplined Agile Delivery attempts to answer that question with the Disciplined Agile Framework.
The ideas in the framework is simple: every team in the organization should be Agile.
This means that teams such as Marketing, Sales and Finance should be
Agile. So should the Legal, Human Resources, and IT Governance teams.
All Development-Operations (what are called "Support Teams" by many or
"Systems Teams" in SAFe) should also be their own agile teams.
This requires that the organization can create products that are
consumable by the other parts of the organization. And it means that at
all levels the whole organization is learning. However, this also
requires that each team be Enterprise Awarea
core tenant of the Disciplined Agile framework. In total there are a
select number of key Disciplined Agile considerations that expand on
Scrum, with an ultimate goal of having Scrum work over time, locations,
size of teams, and the variety of teams needed to run whole
organizations.
Key questions to consider as you think about Disciplined Agile Delivery, are as follows:
What would an Enterprise Aware team of teams look like?
How would you prioritize the work across the organization?
How could teams manage their dependencies if they act as semi-independent Agile teams?
How could learning and "flow" of value needed for continuous operations at scale be incorporated?
Disciplined Agile Delivery starts from one single premise: being Agile doesn't permit teams to be undisciplined.
Disciplined Agile Delivery (DAD) grew from origins in Extreme
Programming (XP), Scrum, and Lean. As it's original forms were being
codified it was clear that Agile was being used by many teams to avoid
good practices of sustainable development. "We don't do that, we're
Agile" was a common phrase that frustrated many in the Enterprise. DAD
offers a compromise that many people today find extremely valuable in
fitting into the organization.
The key characteristics of Disciplined Agile Delivery are:
People first
Learning oriented
Agile
Hybrid
Goal-driven
Delivery focused
Enterprise aware
Risk and value driven
Scalable
In order to achieve these goals, the Disciplined Agile Delivery
process uses a hybrid framework with stages that align with the
Traditional Stage-Gate model, from concept to retirement (disposal).
It's focus in generally on very large solutions that are required for
organizations or developed within large organizations that roll out a
product line.
The key difference between this model and the typical Scrum Model
that starts when a team is initiated with funding is as that DAD uses a
startup phase called "Inception." During this phase many important
things happen to help scale:
Modeling of the solution
Proof of concepts are explored
Shared architectures across teams are initiated
High-level release planning and feature roadmaps are established
During this phase the teams often work in functional and
cross-functional groups. This startup phase allows for a shared
understanding going into the solution development or "Construction
Phase."
Disciplined Agile also believes in many more roles than Scrum does:
Primary Roles:
Stakeholder - these are the same as in Scrum - anyone who is impacted by the solution being built (owners, support, customers, etc.)
Team Member - focuses on producing solutions for stakeholders, the Scrum "generalizing specialist"
Team Lead - servant leader that coaches and helps organize delivery, and often considered an "Agile Project Manager"
Product Owner - provides the "voice of the customer" as either the representative, actual customer, or business line expert
Architecture Owner - can be simple as the "senior developer" or an architect; with the goal of reducing technical debt risk at scale
Secondary Roles:
Specialist - may be the specialist in a certain technology or tool that's used in the solution
Domain Expert - provides detailed domain expertise on critical topics for parts or details of complex solutions
Technical Expert - can be experts in key non-functional areas (user interface, security, databases, etc.) needed for performance
Independent Tester - can be required for complex solution environments or for regulatory requirements (such as government)
Integrator - can be a separate role for integration and delivery mechanisms in complex solutions, such as DevOps teams
Disciplined Agile Delivery works by always having the Primary Roles
(although sometimes the Architecture Owner and Team Lead are the same
person). Then it adds the Secondary roles as needed.
In order to scale across teams, DAD uses the "team of teams" model,
building on the "Scrum of Scrums" concept invented by Jeff Sutherland.
DAD Agile teams meet in Daily Standups
DAD Team Leads meet separately to coordinate delivery, as the Product Delivery Team
DAD Architecture Leads meet separately to coordinate architecture and remove dependencies, as the Architecture Team
DAD Product Owners meet separately to coordinate planning, as the Product Management Team
These teams of teams models are then coordinated, as needed, by an overall Program Manager role.
From this basic scaling model, Disciplined Agile then extends these
concepts to the organizational level. How can we mature the organization
into a "Learning" organization. In fact, the ideas are that the Agile
model is a startup model for Disciplined Agile that can be used to
eventually create a lean-agile organization that continuously performs
the "stages" of development as needed.
Concepts that are built in are the idea of scaling the "Supporting
Cast." Those in the secondary role can become their own Agile teams that
produce products used by the Disciplined Agile teams to delivery new
product. Support teams include everything that could be considered
"Development-Operations" or DevOps:
IT Operations
Customer Support
Security
Data Management
Release Management
These teams are then further scaled up into the total Product
Management realm, deemed the "Disciplined IT" realm including Governance
and Reuse of products (COTS, GOTS, FOSS), as well as Enterprise
Architecture, People Managemenet, and Portfolio Management.
Then Disciplined Agile goes one step higher, suggesting that the
entire Enterprise can behave in an Agile manner. Every part of the
organization can be its own Agile team or team of teams. This applies to
Sales, Marketing, Legal, and Finance, as well as other organizational
areas.
To keep the entire organization aware of its own structure, there is a
need for "Organizational Assets" and the "Knowledge Base." This means
that the Organization becomes its own market for consuming products both
internally and externally. By managing a central portal to access the
key information and tools needed to run the organization, each team can
run without being directive to the others.
This is the actualization of the ideas of a adaptive learning organization. The stages of which are below (shorted from longer forms you can find at http://www.disciplinedagiledelivery.com/dae/):
Tribal - impulsive, and driven by urgency; management "preys" on its employees
Traditional - Authoritarian, driven by protocols and formal roles and hierachies
Scientific - Profit or growth-oriented, driven by innovation and meritocracies of ideas
Post-Modern - Consensus driven, with values-based decision making
Living - Cellular models of management with an evolutionary purpose
Do these ideas make sense to you? What kind of organization do you
work in? You can learn more about the concepts and ideas of Disciplined
Agile Delivery here: http://www.disciplinedagiledelivery.com
SAFe offers a means of scaling Agile very quickly within an
organization that is currently highly Traditional in nature, and large
in scale. The key principles being a blend of Lean and Agile thinking.
SAFe looks to blending the ideas behind Lean and Agile to provide answers to the questions:
How does management give up control, when it's still responsible?
How do we develop products for hundreds or thousands of customers?
How do we coordinate work across teams when the work requires dependencies?
How do we fund, architect, and implement large hardware and software systems with enormous dependencies over years?
In fact, SAFe has three four levels of implementation to help answer these ideas:
Essential SAFe - basic SAFe with only Business Owners managing as executives often on a single Agile release train (ART)
Portfolio SAFe- includes a portfolio management function to align funding across teams or trains
Large-Solution SAFe - Introduces the concepts of having Suppliers that integrate delivery along with multiple ARTs on a Solution Train
Full SAFe - Includes a Portfolio Management function above the Large-Solution when managing across Solution Trains and other ARTs
SAFe
introduces many new roles to the Agile framework beyond the Scrum's
three main roles of Product Owner, Scrum Master, and Development Team
member. These roles considered essential to manage the integration and
flow of products across many Agile teams running concurrently.
System Teams- those that manage delivery and integration of products produced by individual Scrum teams
Architecture Teams- manages and promotes the shared architecture framework across teams
Product Manager- leads the Product Owners as the primary person in charge of targeting features and EPICs
Release Train Engineer- leads the Scrum Masters on each of the Scrum teams, and conducts the large team or team ceremonies
By
adding these essential teams, and others when needed, many teams can
work together. These teams help make up what is termed the "Agile
Release Train" or ART.
ARTs
are how many agile teams work together on a single product or part of
the business. For instance if there is a Financial company that wants to
develop a new mobile banking application for loans, then all Agile
teams working on that application might be on the same Agile Release
Train. There then might be a separate Agile Release Train or "ART" for
developing internal accounting software.
SAFe
aligns ARTs to the business Value Stream. By modeling the business as a
Lean process (remember Week 2), the organization can then continuous
improve how it delivers value to customers using the Plan-Do-Check-Act
(PDCA) cycle. ARTs are the teams that build and deploy changes to each
step in the business value stream.
Agile Release Trains (ARTs) align to one or more similar parts of the Business Value Stream
ARTs are limited to up to 120 people, keeping on the lowside of Dunbar's number
ARTs work together through the Sprint process, with shared ceremonies at the Release boundaries
This
introduces the need to coordinate very large groups through the typical
Sprint processes of Planning, Development, Review and Retrospectives.
One of the most prominent aspects of SAFe is what's called the "Big Room
Training" and "Big Room Planning" during Release Planning. Each Release
is called a "Program Increment" and usually takes four to six sprints.
Program Increments (PI) Planning:
All Agile Teams get in a room (can be up to 200 people, when accounting for stakeholders and Systems Teams)
The Release Train Engineer organizes and coordinates the Planning Day
The Product Manager provides a shared vision, set of features, and priority for the next Release
Product Owners and Scrum Masters each play their role to execute Planning
Points are considered absolute (at least at first) to compare across teams with one point equal to one person for one day
Teams commit to complete PI Objectives, instead of stories (which belong to the team)
PI Objectives are given business value points by Business Owners
Teams identify their dependencies across each other during this planning
The Program Board captures all work and dependencies across teams
The Teams "ROAM" risks: Resolve, Owned, Accepted, or Mitigated
Everyone gives a "vote of confidence" on whether they can meet the
objectives, and keeps going until the whole team puts up "5 out of 5."
Program Increment Inspect and Adapt (IA):
System demo is performed across all teams
Often includes the Project Sponsors (Business Owners)
Humanizes management
Business Owners give feedback on achievement of business value points
Retrospectives are run briefly to identify the most important problem to solve
Problems are then addressed using workshops that include Business Owners, with clear outcomes and support by leadership
A couple of the principles that make SAFe work are:
Take an economic view- Instead of just responding to customer wishes, work is evaluated in terms of cost of delay (CoD).
Plan on cadence, release on demand- All teams must plan together, but they can release whenever work is ready.
Base milestones on objective evaluation of working systems- The work is only considered done when it is fully demoed at the system level
Visualize and limit WIP, reduce batch sizes, and manage queue lengths -
leverage the Lean principles of limiting WIP and managing queues with
small batches helps prevent turning independent teams back into
departmental-like groups
Another issue that SAFe addresses at scale is the need to
continuously explore, develop, and deploy new solutions. This is
embodied in their ideals of "Continuous Everything;" which promotes the
movement of potential work, work-in-progress, and done work through
Value streams.
SAFe has three four levels of implementation to help answer these ideas:
Essential SAFe - basic SAFe with only Business Owners managing as executives often on a single Agile release train (ART)
Portfolio SAFe- includes a portfolio management function to align funding across teams or trains
Large-Solution SAFe- Introduces the concepts of having Suppliers that integrate delivery along with multiple ARTs on a Solution Train
Full SAFe- Includes a Portfolio Management function above the Large-Solution when managing across Solution Trains and other ARTs
To learn a little more about SAFe, check out these great videos as well that can help guide you through the
We're going to present all the basis you need for deciding the best
framework for you and your organization now, by giving the the context
and insight you need into all the major frameworks, including:
Watch out for the shameless plugs we've purposefully put in this
course to asking you to verify for Applied Scrum. We've done it because
you really should verify! Not only do you get a certificate from UMD
proving your excellence, you'll also get access to lots of free content
and tools to start applying these lessons right away.
The last lesson, Pitfalls and Benefits ofAgile,
is especially focused on helping you consider the best way to continue
and not get stuck while starting to apply Agile on your team. More of
these ideas are discussed in greater detail in the verified content (yes
that's another plug, but it's true!).
We hope you continue to stay engaged, have fun, and be curious as you
explore the world of Applied Scrum at it's most applied: the Agile
Frameworks. Time to actuate and pick what kind of Scrum you'll use.
It is official across multiple surveys: roughly half of all projects are now, at least in part, Agile in nature.
And, of those types of projects almost ALL the projects in the
organization use Scrum or some hybrid of Scrum at its base. The reason
being that Scrum is so effective with small teams that it forms the
team-level model for nearly every Agile framework. The four largest
"Agile Scaling" frameworks all use the Scrum model as their basis:
Scaled Agile Framework (SAFe)
Scrum of Scrums
Disciplined Agile Delivery (DAD)
Large Scale Scrum (LeSS)
Both the Project Management Institute (PMI), which has been very
Traditional in nature ("Predictive" as they call it); and the Verizon
One "State of Agile" report across industries that over 50% of
organizations are using Agile.
Note these surveys are very representative across industries of all
sizes. In fact, over half the respondents to the PMI survey had
organizations worth over $500M in total annual revenue.
According to PMI's Pulse of the Profession:
23% of projects use Hybrid (Agile and Predictive/Traditional) methods
23% of projects used Agile
7% used "other" approaches
Only 47% were Predictive / Traditional projects
71% of organizations report "Agility" as being essential to staying competitive
According to Verizon One, who also surveyed a similar distribution of
companies (although skewed towards technology and finance):
56% of all projects used Scrum
75% used either Scrum, Scumban, Scrum/XP, or Kanban
Therefore, the World of Agile has arrived. Now it's time to figure out which framework fits you best!
Scrum in the World of Agile Summary Points
The World of Agile is HERE!
According to PMI's Pulse of the Profession:
Only 47% of projects use Predictive / Traditional approaches
Almost 1/2 of all projects are now Agile in nature
Half are "pure Agile" and usually Scrum
Half are hybrid Agile
Most organizations see Agility as essential to staying competitive (71%)
This means that you've made a great investment learning Scrum,
because no matter what you're likely going to need these skills in one
out of two projects you conduct professionally. In fact, if we look at
the primary reasons why projects fail we see the likelihood that Agile
will continue to grow.
Here are the top reasons why projects fail according to PMI's Pulse of the Profession:
Change in the organization's priorities - 39%
Change in project objectives - 37%
Inaccurate requirements gathering - 35%
And these were all tied for fourth at 29%
Inadequate vision or goal
Inadequate, poor communication
Opportunities and risks were not defined
When you review these aspects, who do they align to the Agile
Manifesto? How do they align to the benefits we've discussed in Week 3
on how Scrum works?
The reality is that Agile addresses the primary challenges facing
projects today directly: objectives, requirements, and communication.
Understanding that Agile continues to grow, we also see in Verizon One's State of Agile report that most projects use Scrum:
56% use "pure" Scrum
75% use Scrum, Scrumban, Scum/XP, or Kanban methods
This is because Scrum is simple, works, and is great for small teams.
But as we've reviewed, there's no greater "organization" in the Scrum
model. So what about Scale? How do these organizations that use Scrum
scale their Agile approaches?
There are four major types of scaling methods used today, according to Verizon One's survey:
Scaled Agile Framework (SAFe) - 29%
Scrum of Scrums - 19%
(Internally Created Methods) - 10%
Disciplined Agile Delivery (DAD) - 5%
Large Scale Scrum (LeSS) - 5%
This accounts for the major majority of methods used. Often we see
that internally created methods tend to look like Hybrid methods. In the
next sections we'll explore SAFe, DAD, and LeSS. Each has the following
items in common:
All use Scrum as the base model for managing teams
All have Product Owners, Scrum Masters, and Development Teams
All differ on how to mange "Support Teams" and how to make an organization Agile.
The simplest means of understanding Agile at Scale is to look at the two methods originally used to Scale Agile:
Scrum of Scrums - teams coordinate work through sending representatives to have Daily Stand Ups across teams.
Hybrid Methodology - teams are coordinated by using Predictive or Traditional controls, such as stage gates, to manage delivery
Scrum of Scrums:
Scrum of Scrums Stand Ups: Teams send a representative, although usually this is a Product Owner or Scrum Master
Can take literally just a long as a standard Daily Stand Up
Focuses on reporting out completions and blockers
Opportunity to identify need for coordination among team memebrs
Scrum of Scrums have a Scrum Master
Usually a senior person in the organization
Responsible for facilitating the coordination of work
Responsible for overall productivity of the Scrum of Scrum Teams
Scrum of Scrums applies when two teams have potential dependencies
Share resources (people, services, etc.)
Shared product in development
Shared goal or vision
Originally this was proposed by Jeff Sutherland, one of the founders as Scrum and signatories of the Agile Manifesto in 2001
"Agile Can Scale: Inventing and reinventing SCRUM in Five Companies" - Jeff Sutherland, Cutter IT Journal, 2001
Provides story of using Scrum of Scrums at IDX, where weekly product line Scrums and Monthly Management Scrums occurred.
Some teams became "hyper-productive," a state of Scrum teams that Jeff Sutherland talks of being 4 to 5 times more productive
Scrum of Scrums offers a very simple, and yet elegant means of
scaling Scrum. In fact, the practice has been used by many very large
scale organizations to achieve organizational agility.
In the HBR Article, Agile at Scale (2018), there are examples of
Scrum of Scrums spanning hundreds of people in less than one hour:
Saab's aeronautics business has over 100 agiel teams for its Gripen fighter jet ($43M project)
Daily Stand Ups occur from 7:30 AM to 8:45 AM
By the end of the the Stand Ups using Scrum of Scrum approaches, the
executive team knows the critical issues it needs to address
That's over 500 people fully reporting using word-of-mouth in less than 90 minutes
This model is having a resurgence now among many Agile practitioners.
Especially as many organizations are expanding their understanding of
Agile and using Hybrid means or SAFe to transition into becoming an
Agile organization.
The Hybrid model that is most commonly used by organizations is rather simple:
Traditional means are used to control major decision points
Stage Gates are leveraged especially for Requirements, Design, and Operations (Deployment)
This offers a chance for the Traditional / Predictive leadership to approve the next "Stage" of the project
Agile (Scrum) methods are used to rapidly and iteratively develop products in each stage
Whole teams are used to develop Requirements, Designs, Development, and Verificatoin
Whole teams are able to prototype and create reusable document
Requirements are managed as User Stories
Stories are generated in Requirements, refined in Design, Implemented and closed in Development
Development is often still iterative and incremental for speed and learning
Development may have multiple releases to a "staging" or "pilot" environment
Verification is run for system-level requirements against use cases
This effectively looks like iterations between stage-gates; and is
often more successful in organizations that resist Agile. Since
organizational resistance to Agile and misunderstanding of Agile are the
primary reasons for Agile failing (according to Verizon One), this
makes sense for many new entrants learning Agile for the first time.
When looking at the major reasons that Agile fails, we see the following:
Organizational culture at odds with agile values - 53%
General organizational resistance to change - 46%
Inadequate management support - 42%
Lack of skills/experience with agile methods - 41%
These statistics show why the Hybrid model is so popular among about
half the practitioners of Agile in more traditional organizations. For
this reasons "Internal Agile" is a great means of proving the
effectiveness of the method when there's no upper management support.
However, the only means of truly achieving agility is to have leadership
support and good Agile training.
So how do we convince the leaders who are disbelievers in Agile? Show them the data:
Reasons for Adopting Agile
Accelerate Software Delivery - 75%
Manage changing priorities - 64%
Increase productivity - 55%
Better alignment of business and IT - 49%
Increased software quality - 46%
Benefits of adopting Agile (percentages show counts, not impact)
Better management of priorities - 71%
Project visibility - 66%
Alignment of business and IT - 65%
Delivery speed / time to market - 62%
Team productivity - 61%
And in terms of impact, the benefits can be four to five times the
productivity and value output; as seen in the Ambysoft survey in 2013.
Now that you understand the Scrum in the World of Agile, and you know that world is here (!):
What framework will you choose?
How will you achieve the benefits (speed and innovation)?
How will you manage the change (leadership and control)?
The other lessons in this week will try to help you answer the first
question. To answer questions 2 and 3, we highly recommend you sign up
for the remaining courses in the Agile Project Management Certificate.
Just like in this course, if you Verify you'll get tools, additional
resources, and insights that go beyond these lectures and notes to
enable the change in your projects.
See the Switzerland's most beautiful villages, mountains, waterfalls and many more. A short video I put together of a typical day living in this dreamy part of Switzerland. Switzerland is a mountainous Central European country, home to numerous lakes, villages and the high peaks of the Alps. Its cities contain medieval quarters, with landmarks like capital Bern’s Zytglogge clock tower and Lucerne’s wooden chapel bridge. The country is also known for its ski resorts and hiking trails. Banking and finance are key industries, and Swiss watches and chocolate are world renowned.
TravelEx channel shares travel videos. Please subscribe for enjoying more interesting travel videos. If you like the video share with your friends.
This video Landing in Entebbe International Airport Emirates Airways. During landing in entebbe airport the sky was cloudy. So you can enjoy how airplane run through the cloud.
Entebbe International Airport is the principal international airport of Uganda and supporting the country to connect the world. The airport is located in the shore of Lake Victoria which is one of the worlds largest lake. During the take off the aircraft fly over the lake that allows to capture amazing view of Lake Victoria. The destination was Dubai International Airport (DXB) which was about 5 hours fly from the base of departure.
Entebbe International Airport is the only international airport in Uganda which is located in lake city entebbe. It is near the town of Entebbe, on the shores of Lake Victoria, and approximately 40.5 kilometres by road south-west of the central business district of Kampala, the capital and largest city of Uganda.
Different world renowned airlines are operating flights to and from Entebbe International Airport. The list includes Qatar Airways, Turkish Airlines, BidAir, Ethiopian Airlines besides Emirates.
TravelEx channel shares travel videos. Please subscribe for enjoying more interesting travel videos. If you like the video share with your friends.
Sprint Planning is one of the most exciting parts of any Sprint.
It's an opportunity to imagine and explore the needs of the customers
and stakeholders. Everyone is involved and the Development Team really
gets ask all the detailed burning questions needed about the
requirements they're preparing to implement.
The key steps in this process include:
The Product Owner presents the Updated Product Backlog
The Development Team selects User Stories for a Product Increment
The Development Team refines User Stories enough to estimate and finalize selection
In completing this process, there are couple of key tenants:
All voices need to be heard
Everyone has to agree on the Sprint Backlog
You need to get all planning completed quickly!
How would you quickly get all of this accomplished to plan work for
two weeks or four weeks? Think of all the points of discussion on one
User Story, let alone a team's worth!
Sprint Planning Summary Points
Sprint Planning has three key objectives:
Product Owner presents the updated Product Backlog
Development Team selects and refines User Stories
Development Team is able to commit to the Sprint Backlog
However, to ensure the authenticity of those objectives are met the following must happen:
All voices must be heard
Team must review and elaborate all User Stories in the Sprint
The Team must be able to size and select those stores within the timebox of the Sprint Planning!
The "timebox" for sprint planning is usually half a day for a
two-week sprint, or a full day for a four week sprint. The same applies
for Team Retro and Reviews. This allows for one day out of two weeks
(1:9) ratio to be spent on planning and review.
To do this correctly, the team must avoid:
Getting into long, drawn-out discussions on requirements
Conflicts that can destablize the planning meeting
Not having the information needed to plan
The key to making a good Sprint Planning Work is two-fold:
Great User Story writing by the Product Owner (and/or Development Team in variations of Scrum)
Planning Games
Great User-Story writing means that the Scrum Master and Product
Owner need to work together to ensure User Story quality. This is
especially important when the team has a new Product Owner, who hasn't
worked on a Scrum team or THIS Scrum team. Story writing is extremely
cultural.
The use of Planning Games is essential because it helps to facilitate
and elicit creativity from the team. Often this is when many teams will
ask, "why not just talk about the stories?" The key reasons for NOT
using unfacilitated discussion or "open discussion" is that it's NOT
open:
Loudest voice in the room wins
There's no timebox or time limit on discussions
There's no way to tell when consensus is reached
There's no way to improve without structure to improve upon
For this reason we use games in Scrum. The most common is the Planning Poker Game.
If an outlier exists (more than one step from the mode), then discuss
(Optional) After two rounds take an average, and validate with a "yes/no" team vote
This process is used to accomplish three things:
Validate that the size of the story is correct
Validate that the User Story is well understood
Ensure all voices are heard equally when disagreements occur
Many times there are disagreements about how to develop a point scale.
There are valid reasons, especially when Story Points are misused by
team members or management outside the team. Here are some key points to
consider:
Points are a relative metric
Points should consider more than effort
Complexity - how hard is it?
Uncertainty - how certain are we know the business reqs and potential technical solution?
Effort - how much total work?
Points should be consistent across Sprints, but not necessarily across teams
Please note that many types of "Scaling Frameworks" disagree, with
basis, on whether User Story points should be an absolute metric, or at
least shared across multiple teams. For Scrum and it's variations this
is not important. Story points are solely to help the team know how much
work can be accomplished and if the team is getting faster Sprint after
Sprint.
We continue to explore these concepts of how to use scaling of points
and measurements of team performance in the Agile for Control course in
the Agile Project Management Curriculum. As well as briefly in next
week's lessons on Scaling Frameworks.
Finally there are few additional items to consider for Planning:
Work iteratively through picking Stories prior to Sprint Planning
Select Stories that combine to form a cohesive "Product Increment"
It's best if the Product Owner has something in mind already
This Product Increment should be written down as a "Sprint Objective" to help focus Planning
Work one-by-one through User Stories when performing the Planning Poker game
This is fastest, because everyone is focused on the same story at the same time
This is easiest because you only have to think about one story at a time
Make sure to leave a little buffer on your first Sprint
Make sure that everyone commits to getting the work done - don't let
everyone leave without a clear "confidence" vote from the team
You will end up refining the Product Backlog and identifying potential dependencies in this process - that's okay!
When updating the Sprint and Product Backlogs - do it now. Don't lose those moments of insight that come in planning
Make sure that the tools you use are simple and effective to make this go smoothly
Finally, be sure to prioritize the Sprint Backlog so the Development
Team knows which User Stories to start on first the next day.
By following these guidelines your planning will be faster, more
inclusive, and more accurate than any group discussion or interview
process could hope to achieve.
Sprint Development
Sprint Development is upon the team. It's the first day and a
Sprint Backlog of User Stories fresh in mind awaits the team. Time to
Stand Up and start delivering!
Sprint Development is much different than the type of work
experienced in Traditional environments. Every morning the team meets,
rain or shine, good day or bad day, and they discuss the
work-in-progress. To ensure that no team member is stuck many tools are
used, some of which we've discussed briefly already:
Daily Standups
Kanban or Scumban boards
User Stories
Face-to-Face meetings
Focused time at your desk! (Imagine it!)
The goal of these tools is to reduce the time spent in meetings to
the essential. Teams will open up less work than the whole team could
work on concurrently as individuals. Why? Because that way when someone
needs help there are people to help. Everyone isn't "too busy" to jump
in and solve problems together.
Also, there is no "i" in team, and the "m" and "e" are always
preceded my "t" for team. The team comes first because the whole team is
evaluated on performance together, and no one person "owns" the work.
Team ownership means everyone has a shared interest: completing the
Sprint Backlog.
Imagine removing all "coordination" meetings with a five-minute
standup. Imagine having help whenever you ask for it. Imagine getting
work done during the day
Sprint Development Summary Points
To begin, it's important to review the principles of Sprint Development:
Daily Stand Ups - daily face to face communication so there's no "scheduling" of coordination
Whole Teams- Everyone knows what the work is (we planned it together), and works on it together
Team Ownership - Multiple team members working on the same User Story
Limit WIP- limit the Work-In-Progress (WIP) to achieve faster, predictable development with focused time
When we look at these principles we see a lot of the Agile Manifesto Values restated within them.
Individuals and Interactions over Processes and Tools Daily
Working Software (Systems) over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan
Daily Stand Ups
Two types of daily standups
"Scrum Standup" - each team member reports on what they did, what they plan to do, and any blockers
"Forward-Looking Standup" - facilitator asks about work-in-progress, team self selects what they'll be doing
Whole Teams
Whole team is available to work on closing User Stories
Product Owner provides input on features as developed, and is available to close stories
Scrum Master facilitates meetings, workshops, and ensures quality through good User Stories, Story Closing, etc.
Development Team collaborates to complete work, which may mean switching to help others
Continuous Planning
As product takes shape, Product Owner consults with stakeholders to gather feedback
Scrum Master ensures feedback is facilitated and efficient
Scrum Master works to engage other stakeholders as necessary, or other teams at scale
Product Owner write stories, which are audited by the Scrum Master
Team Ownership
Teams know what work needs to get done, each supporting as needed
Sometimes that means three Development Team Members work on one User Story
First gathers user interface (UI) and process requirements from stakeholders, and builds UI
Second begins working on technical solution for middle (logic layer) and backend (data management)
Third designs and builds tests based on Acceptance Criteria (automated tests)
Scrum Master might facilitate meetings with stakeholders or UI rapid prototyping
Product Owner will validate the final product
If one User Story begins to fall behind, then pair programming or "war rooms" can be established to solve the problem
Team members know the work, and can jump in to help
No individual ownership removes issues of "pride of authorship"
Team reduces risk of failing to deliver critical functionality
This "Team Ownership" ensures progress on the highest priority work, which also carries the most value for stakeholders
Limit WIP
Limiting work-in-progress (WIP) enables all processes to work faster
Reducing WIP means team members are available to support as needed
Reducing WIP means fewer meetings and coordination activities
Reducing WIP means clear, small tasks that can be accomplished and reviewed quickly
Reducing WIP means more time spent getting work done, and less time organizing multiple acitvities
Primary means of reducing WIP is to use a Kanban or "Scrumban" board
Kanban board - manages stories as work items, moving Stories across the value stream of a states
Stories may have three or more states, often requiring five states (Planned, Ready, In-Development, Testing, Done)
Each state is limited in terms of the number of stories allowed (such as only two in Testing at once)
Limiting the WIP in each state ensures that work must be completed before starting new work
Scrumban Board - manages tasks as work items, moving tasks and then Stories across a value stream of states
Like Kanban, there are three or more states that tasks and Stories can be in, often five (Planned, Ready, In-Dev, Testing, Done)
Stories can only move forward in states in the Value Stream once all tasks have moved forward
Stories are only "In-Development" if all tasks are "In-Development" or further in the Value Stream (e.g. "Testing")
Stories and tasks are managed in their own row or lane
Scrumban may also include "fast lanes" for high-priority tasks
Note that many of these techniques are borrowed from Lean approaches;
especially the Kanban board for limiting WIP. This is because once
Stories are planned the team should operate like a well-oiled machine
cranking through work. The goals of continuous improvement and reducing
waste definitely apply.
However, one key aspect of Scrum that differs and remains Agile is
the fact that the Product Owner is on the team, and they can accept work
incrementally. Also with the full transparency of the Sprint Backlog
showing what work the team must accomplish by the end of the Sprint, the
Development team can decide to manage their time based on those Sprint
Requirements. These Stories also combine to form a meaningful, shippable
increment.
For these reasons, Agile offers sustainability, purpose, mastery, and
autonomy to the Development Team not offered in pure Lean approaches.
These elements have been proven to be the most motivating for teams of
knowledge workers.
