The document discusses transitioning to an agile organization in the digital age. It provides definitions and explanations of key concepts related to agility, including that an agile organization can quickly identify and deliver customer needs. It also discusses agile development methodologies like Scrum and challenges with implementing them. The document advocates that true agility requires changes across the entire organization beyond just development teams.

1. Transitioning to become an Agile
Organization in the Digital Age
Musings by Richard Ellis PMP PRM PMI-ACP
CSM SSGB
President Agile Consultants LLC

2. What is Agility
• An Agile Organization is one that can quickly identify and validate
customer needs and deliver them to the market quickly.
• Agile Development is the ability to discover new products or
features for existing products that are valuable to a customer (that
they will pay for) and deliver them to the market quickly.
• Agile Processes are processes that can quickly adapt to changing
customer needs.
• Agility applies to Projects, Iterative Development and Processes.

3. • You don’t do Agile, you are Agile

4. Project versus a Process
• Projects – Have never done this before.
• A Project has been defined as a set of interrelated tasks to be executed
over a fixed period and within certain cost and other limitations. In other
words, a sequence of activities that have a beginning and an end. Projects
create change. Projects are where innovation takes place.
• Processes – Do the same thing repeatedly.
• An Process or Operation creates value by repeating work that a
customer(s) wants in a predictable way.
• Processes can be experimented, tested, optimized, refined and
institutionalized. Properly designed processes are more efficient,
predictable and effective than one off project work streams. Processes
resist change.

5. Waterfall Projects
• The waterfall model is a
sequential design
process in which
progress is seen as
flowing steadily
downwards like a
waterfall.
• Projects move through
phases of identification,
initiation, analysis,
design, development,
testing and acceptance.
Customer
Orders
Product
Requirement
Specifications
Approvals Technical
Development
Design
Validation
and Approval
Technical
Design
Verification
and Testing
Delivery to
Customer
(Months to
Years later)

6. Iterative Projects
Iterative
development
projects (which may
or may not be Agile)
turns individual
projects into
processes which can
be honed for
efficiency (Lean) and
repeatability (Six
Sigma). Test and
Deliver
Product to
Customer
Develop
Product or
Feature
Estimate and
Decompose
Requirements
Reevaluate
Requirements
send Team
more work
Customer
Evaluates and
Accepts or
Rejects

7. Agile Development, The Customer
Centric Model
• Agile development takes advantage of the short
cycle of the iterative development process to put
the Customer front and center.
• Customer feedback influences, if not defines, the
product for the next iteration.
• Regular incremental releases lets the Customer
shape the product from early in the development
cycle and alerts the team if the product is failing
to provide value to the Customer.

8. Digital Transforms how Businesses
Deliver Services
• Digital Transformation refers to the application of new
technology to create new Digital processes that
replicate complex existing processes that may have
many discreet process steps. The new streamlined
processes focuses on the customer while at the same
time dramatically reducing cost.
• Digital also enables new entrants to Disrupt mature
businesses with innovative delivery models that serve
customer need far better and at lower cost than the
market’s existing model.

9. Why is Agility important
• Agility allows organizations to quickly respond to changes in the market.
• Agility is a key factor for success in any Digital Transformation. The new (last five
years) capabilities of Digital open the door to many sales, service and delivery
functions to be transformed, delighting the customer at dramatically reduced cost.
• Disruption requires Agility. Without the ability to adaptively refine plans, projects
will always miss the needs of the customer by the time they hit the market. You
are moving into uncharted territory, nobody has the answers, you must find out as
you go along. If you wait for the results of your last projects you will miss
opportunities by the time you are able to regroup.
• All businesses have at least some elements that are ripe for Digital Disruption. If
your business does not do it, someone else will. And they will take your most
profitable market segments with them.
• The best one to Digitally Disrupt your business is YOU. You know more about your
clients, market and product than any startup. Take advantage of it or else.

10. Product development has
traditionally been done in internal
corporate silos. The choice of what
products to pursue was often driven
by internal forces such as available
production capability, product
designer’s and management ideas
rather than validated and tested
customer demand. Even where
products were focus group, test
marketed or sample tested, this
approach rarely produces
transformational products.
Agile development is focused
directly on the customer. Ideas can
be quickly tested, delivered to the
customer and validated. Those that
fail, fail quickly. Those that succeed
can be refined, quickly. Customer
value, not internal corporate goals
are the only measure of success.

11. Agile Project Development brings
Process efficiency to Projects
• Agile iterative and continuous delivery project
methodologies bring the efficiencies of repeatable
processes to Projects.
• By creating a repeatable process for delivering value,
project development can benefit from the efficiencies
and predictability of production processes.
• Teams have the opportunity to increase their velocity
(productivity), reduce waste (Lean) and defects (Six
Sigma) by improving their development cycle with each
iteration.

12. Agility
• Agile – increase feedback. The tighter the feedback loops the faster the organization can adapt to
changing customer requirements and address poor quality.
• Business Dictionary1 - The capability of a company to rapidly change or adapt in response to
changes in the market. A high degree of organizational agility can help a company to react
successfully to the emergence of new competitors, the development of new industry-changing
technologies, or sudden shifts in overall market conditions.
• Read more: HR Zone 2 - Business agility refers to distinct qualities that allow organizations to
respond rapidly to changes in the internal and external environment without losing momentum
vision. Adaptability, flexibility and balance are three qualities essential to long-term business agility.
• CIO Magazine 3 – Business agility is the quality that allows an enterprise to embrace market and
operational changes as a matter of routine.
• Directing the Agile Organisation 4 - (Business Agility is the) “ability of a business system to rapidly
respond to change”

13. The History of Agility
• The concepts of Agile and Lean come from the Toyota production
system initially developed by Taiichi Ohno c. 1948 to 1975 based on
Henry Ford’s earlier work starting in 1906.
• Over time, the principles of reducing waste, focusing on the
customer, reducing variability and continuous improvement have
evolved into the management frameworks we see in use today.
• Principles of Lean thinking appear in most project management and
process design techniques now practiced by companies and
Management Consulting firms worldwide.

14. Lean
• Lean – principles reduce latency and wasteful tasks. Lean is the practice
of continuously improving how you deliver correct, high quality
products/service to customers when they need them. This is accomplished
primarily by eliminating waste.
• Muda – refers to processes that don’t add customer value. The seven
wastes of Muda are Overproduction, Over-processing, Inventory,
Transportation, Motion, Waiting, Defects.
• Mura – a type of waste caused by unevenness in production such as
rushing to meet end of month sales or production goals.
• Muri – waste caused by overly complex processes that over burdens
workers or forces them to use inadequate tools or work with inadequate
training.

15. Six Sigma
• 6Sigma – reduce variability. Variation increases defects which
increases cost and reduces customer satisfaction.
• Six Sigma uses Statistical data to monitor processes to identify
systematic and special case causes of process variability. Processes
drift over time. Six Sigma tools realign and keep processes
accurately on target.
• The cost of poor quality is far higher than the cost of controlling the
variability of processes. While 6Sigma is based on Lean principles, it
adds the idea of using a structured data-driven approach using
statistical tools to eliminate defects.

16. Organization frameworks to create and
produce goods and services
• Those that design processes and manage projects utilize what are called
methodologies or frameworks. These are collections of tools and
roadmaps that are used to create structure and guide actions of team
members.
• Elements within methodologies are not mutually exclusive. It is quite
common for tools to be borrowed from other methodologies to suit a
particular initiative or evolve, over time, into a new methodology.
• In project management these include such frameworks as Scrum, XP,
Crystal, DSDM, Lean, Lean Startup, Kanban, RUP, RAD, FDD Spiral and long
standing or traditional approaches of PMBOK (waterfall) and Prince2.
• In process design we have Six Sigma or 6Sigma, Lean, ITIL, DevOps and an
assortment of proprietary methodologies such as CMMI and ISO.

17. Agile development Methodologies
• One of the most popular project management methodologies is Scrum. In
fact, for many, Scrum is synonymous with Agile.
• While Scrum is an Agile methodology, simply transitioning a development
team to the Scrum process does not make one Agile. The rules of Scrum
are very simple. Real improvements begin to appear when the team is left
alone to self organize without outside constraints, or impediments.
• To realize the true value of Scrum and Agile there needs to be a shift in
culture and management style above the development team level. The
organization needs to align its organizational structures and adjust its Key
Performance Indicators (KPIs) to promote Agility as a value. Only by
measuring Agility and aligning internal incentives will it be able to develop
Agile capabilities. With an Agile development team in place, this becomes
the capability to quickly identify the changing needs of the customer and
communicate that knowledge to the team via a properly prioritized and
relevant product backlog.

18. Scrum facilitates Agility
• Scrum facilitates organizational Agility. It does this by shortening
the change order cycle to a week or two but, more importantly, it
lowers the cost of changes to ZERO. Change orders and revised
project plans are not required with Scrum. With this ability, as
customer feedback points toward a better solution, the product or
service can be improved incrementally quickly and at low cost.
• Disruptive delivery modes can be developed and deployed quickly
using Scrum. Scrum speeds your ability to deploy change.
• Scrum does not inform the organization about what the customer
needs, may need or might be persuaded to need. This is the role of
those outside of the Scrum team including management, sales,
marketing, product development, etc. These needs are
communicated to the Scrum team through the Product Owner.

19. The difference between Agile Project
Management and an Agile
Organization
• There are many firms who proclaim, and in fact, believe, they are Agile
because their software development has transitioned to Scrum teams.
Scrum is a popular framework because when implemented properly it
allows teams to quickly create customer value; but only if requirements
that the customer perceives has value are accurately known. An Agile
development process dramatically improves development but it does not
make an organization Agile.
• An organization can only become truly Agile when Agile principles and
tools are employed across entire value chains from customer identification
to delivery to that customer. The organizational culture must promote,
through its values, the ability to react quickly to changes in customer
needs and be in a position to deliver those needs to the market.

20. Scrum
• Scrum is based on the principle that people work better when teams are allowed to self
organize and do their work as they see fit. The team is left alone to do their work without
interruptions. Interruptions create multi tasking. Multi tasking feels productive but it is not. It
is very seductive. In reality you are getting a little bit done many different things. However, if
you add up totality of what you have accomplished, it is almost always far less than if you had
simply stuck to one thing until completion before moving on to the next task.
• Development is done by the Scrum Team which generally consists of five to seven members
who perform the work. Good teams are constructed so that all of the tasks to complete the
work are present on the team. This means refactoring, documentation, QA, usability and
performance testing is done by the team. Work is considered complete only when it is
deployed to production, integrated to a release or delivered to the customer.
• The Scrum Master facilitates the team’s work and has two primary responsibilities. First they
manage the meetings (also called ceremonies) and facilitate the production of documents
(also called artifacts). Second, and more importantly, the Scrum Master removes
impediments that hinder the team from doing their work. These include interruptions of
team members (multi-tasking) by management or diversions by other stakeholders such as
Dev-Ops or QA. The Scrum Master also works with the Product Owner to insure the team
always has work available.

21. The Elements of Scrum
• The Product Owner is management’s representative to the Scrum team. The Product Owner
provides the development team with a list of products that customers want. This list is called
the product backlog. The development team assists the Product Owner in preparing and
maintaining the backlog which is called Grooming. Ideally the Product Backlog is maintained
as a prioritized list of User Stories that are ready for execution. User Stories are actionable
work that has a testable output and can be completed in a time boxed development period
called the Sprint. The Product Owner is responsible for ensuring User Stories are relevant, in
priority order and truly represent the needs of the customer.
• To help the Product Owner create and maintain the Product Backlog, the team breaks down
large features, often called Epics or Themes into User Stories. The team then estimates the
effort required to execute each User Story using a metric called Story Points.

22. • The Sprint is an iterative production cycle with a fixed duration, typically two weeks. For each
sprint the team selects work from the backlog to be executed during the sprint for release to
the customer. Only User Stories that have been completed and accepted by the Product
Owner count in evaluating the team’s productivity. The team is careful to select how many
user stories to take on for a given sprint.
• Development teams hone their collaborative work dynamic so over time they dramatically
increase their productivity or, in the words of Scrum, their Velocity. Velocity is a
measurement of completed Story Points per sprint. While Story Points often sound like Work
Hours, there is a difference. Hours always take 60 minutes. Story Points may start out taking
one hour but as the team matures they deliver User Stories in less time. Typically teams
increase their velocity 2x to 5x within three to five sprints.
• The Product Owner uses customer feedback on delivered products to help them select and
prioritize user stories for future sprints. This helps deliver greater value to the customer
sooner than many other project management methodologies.

23. Challenges when implementing Scrum
• Scrum is famously simple and elegant in concept but is notoriously difficult to do well. Here are
some of the things that happen when companies transition to Scrum from a Waterfall or less formal
methodology.
• Teams work on two sprints at a time. Sometimes QA is treated as a separate function. Team
members fix bugs from the prior sprint while working on the current sprint. Too much work in
process along with high team utilization rates are the biggest threats to efficiency.
• As teams get larger collaboration decreases. Recently I was asked to be the scrum master for a
team at a large financial institution. The team looked like this. There were 19 team members in
New York, led by a lead developer who had an assistant developer. There were further members in
India. Because of the size, only the two leads in New York and the one in India were allowed to
participate in the daily Scrum.
• Product owners do not understand what the team is building. The link between identified customer
value and products to be delivered gets broken. The value chain is no longer continuous or able to
form a correcting / iterative cycle.
• Management assigns the PO because they don’t want to “waste” their time being the interface
themselves. Like the game of telephone, something is lost with every communication.

24. Scrum misalignments
• When a team lives one sprint at a time they don’t have the perspective of the entire project and how the major
pieces must fit together.
• Not enough time to do sufficient sprints to create a truly usable project. Being told Agility will allow teams to do
more in less time, Product Owners and Management overestimate the results of work that has yet to be
performed.
• Development team member turnover.
• Team does not grasp time goals of project. The connection between the team and the customer gets broken.
• Institutional memory disappears in a transactional employee organization. Hiring consultants by the hour seems
like a great economy but you loose a lot when the project ends and you kick your team members to the curb.
• Product owner turnover.
• Management places other work demands on team members.
• Project Leadership (Scrum Master or Project Manager) turnover.
• Management looses interest.

25. What is DevOps
• DevOps is a difficult concept to define. Partly because it is not a Framework or a Methodology.
DevOps is more of an attitude and a collaboration between business silos (development and
operations) to shorten deployment to the customer cycles. DevOps also has commercial
proponents, each eager to articulate their view on exactly what DevOps is.
• Some say DevOps is at the intersection of Scrum and Operations. DevOps picks up where
development lets off. That DevOps puts into production software that now comes in a continuous
stream instead of neatly discreet batches that have been tested to death.
• Others say DevOps is an extension of Lean across the Value Chain from customer want to customer
experience. There is something to this. A key principle of Lean is the concept of flow. Smoothly
flowing systems utilize their resources without bottlenecks that cause delay, errors and other forms
of waste.
• My view is DevOps is about collaboration, it’s about delivering value to the business. Some say it
replaces ITSM (Information Technology Service Management). Yet Gene Kim, an early promoter of
DevOps said “It is my firm belief that ITSM and the DevOps movement are not at odds. Quite the
contrary, they’re a perfect cultural match.”
• For further insight consult The Phoenix Project and the DevOps Handbook. Both address the Theory
of Constraints and its relation to DevOps.

26. Where does DevOps fit in and why is it
an important component of Agility
• DevOps allows the deployment of software from a batch process to a continuous or on demand
one.
• Companies who implement Scrum development teams as a first step on their path to Agility often
find their improved teams turn out way more product than the organization can handle. The
organization can feel like its drinking from a fire hose.
• DevOps, short for Development-Operations is a movement to strengthen the collaboration and
coordination between the Development teams who create software and the Operations teams of IT
who deploy software into their environment and manage the organizations production IT systems.
• Software developed using Waterfall based development was usually sent to IT Operations in large
discreet chunks. IT then had the luxury of time to deploy it and integrate it into their operations.
• With the need for release on demand or continuous deployment, Operations teams have been hard
pressed to support the introduction of software so frequently. Hence, the need for something like
DevOps.

27. Kanban
• Kanban means “card you can see” in Japanese. It is a series
of visual signals to trigger and regulate (smooth the flow) of
actions.
• First used in the Toyota production, colored cards are used
to move goods from one area of production to another and
to indicate which materials were running low, triggering a
Just In Time (JIT) replacement order.
• The JIT inventory restocking model was the original
purpose of Kanban cards.
• Kanban also helps regulate flow and fosters gradual
improvement. These are Lean principles.
• The most recognizable feature of Kanban is the Kanban
Board.

28. Using Kanban Boards to help Scrum
iterations flow more smoothly
• Kanban boards helps Scrum users by visually displaying
work in process making it easier to limit bottle necks an
eliminating the problem of starting too many user stories to
complete in the current sprint.
• Developers take user stories, usually represented by a
sticky note, from the product backlog column on the left
and move it from column to column to the right as
milestones are met.
• There are strict limits on how many sticky notes can be in
any one column at a time. Backups at any one step, such as
QA, are quickly seen and prevented.

29. Principles of the new Kanban c.2005
• Visualize work – By depicting processes and work flows as columns and rows, a
quick glance by anyone will show progress and bottlenecks. Sticky notes for each
task move across the board from left to right. Anyone can contribute and easily see
backlogs, work in process (WIP) and product about to be released to the customer.
• Limit Work in Process – By limiting the amount of work at each step in the
process, the time it takes to travel through the process is reduced, primarily by
reducing “task switching” which takes the human mind a long time to fully effect.
Multi-tasking is a fraud. It feels like you are getting a lot done as you are touching
so many things when in actuality you are spending much of your time mentally
changing tasks.
• Smooth Flow – A steady flow eliminates bottle necks (wasted time and resources)
and reduces crunch times when mistakes happen as people and processes are
stretched beyond capacity.
• Continuous Improvement – Metrics generated as each work unit meets a progress
step (column on a Kanban Board) allow analysis of the system to monitor current
performance and identify points of future problems. Optimizing the first three
principles increase capacity and reduce opportunities for process failures.

30. The new Kanban – Another Fork in the
Road – Kanban without Scrum
• Kanban without Scrum further enhances Lean flow by
eliminating the time boxes that neatly separate
iterations. Products are delivered continuously on an as
completed basis or delivered on demand.
• Without Scrum sprints there are no regularly scheduled
customer demonstrations, customer acceptance, sprint
planning or retrospective meetings. Instead, these
meetings are held as necessary and as convenient.
This eliminates fixed schedules which often lead to
meetings that have too small or too great of an
agenda. Here again, flow is enhanced.

31. The concept of a Value Chain
• Wikipedia - A value chain is a set of activities that a firm, operating in a
specific industry, performs in order to deliver a valuable product or service
for the market.
• Katherine Arline1 - A value chain is the full range of activities – including
design, production, marketing and distribution – businesses go through to
bring a product or service from conception to delivery. For companies that
produce goods, the value chain starts with the raw materials used to make
their products, and consists of everything that is added to it before it is
sold to customers.
• Michael E Porter2 -Competitive advantage cannot be understood by
looking at a firm as a whole. It stems from the many discreet activities a
firm performs in designing, producing, marketing, delivering and
supporting its product. Each of these activities can contribute to a firm’s
relative cost position and create a basis for differentiation.

32. Lean Startup
• Lean Startup preserves precious capital and resources by testing customer
requirements to avoid the waste of producing something that is not valued by the
market.
• Lean Startup views the value chain as the complete process of identifying the
customer, creating and validating a product, producing it and actually selling it to a
paying customer. Free samples don’t count.
• Lean Startup seeks to conserve resources by encouraging quick failures in as small
a way as possible. Created for startups, it is equally applicable to large agile
organizations as multiple Lean Startup processes can co-exist in an Agile
organization.
• Lean Startup is based on the idea that you need to accurately identify customer
demand in order to deliver real value quickly. To do this you need to identify the
smallest product that a customer is willing to pay for. This is known as the
Minimum Viable Product (MVP). The MVP is then delivered as quickly as possible
in order to judge its value and provide feedback to be able to improve, decide to
produce or scrap the product.

33. Minimum Viable Product - MVP
• Lean Startup extends the traditional concept of the value chain to include MVP
identification and validation. You can’t have an efficiently profitable value chain
without knowing (testing) the product’s value to the customer. The customer must
be willing to pay for the MVP in some way for it to be valuable.
• The identification of a minimum viable product (MVP) is only the first step. The
MVP must be tested with the customer to determine if there is real potential value
for the product. Surveys or focus groups are often employed to validate that the
customer really wants the proposed product and is willing to pay for it. Sometimes
vapor ware, mock-ups and wire-frames are used.
• If it is not possible to test the MVP before committing to creating and deliver the
product, production is done in as small a scale as possible. Failures are best when
they are fast and cheap. Startups do not want to bet the farm on an idea that has
not been validated.
• If the customer does not validate the MVP, it is replaced with another one which is
then tested until a viable MVP is found. This is called a Pivot.

34. Lean Startup- deliver then measure
the true value of the MVP
• Deliver the product to measure the market’s actual
receptiveness. This is called “validated learning”. This
feedback completes the Build-Measure-Learn BML cycle
used in Lean Startup.
• The purpose of Lean Startup is to create value that a
customer is willing to pay for. Measurements of output and
delivery to specifications are meaningless.
• Measurements of success and failure are made using
Innovation Accounting which helps entrepreneurs measure
progress, set milestones and prioritize work. It also
measures how much value is created for the input.

35. Design Thinking unites silos within an
organization to the Customer
• To be truly Agile, customer satisfaction and customer
needs, both known and unexplored must be the central
driver of processes, process change and projects. Sadly, this
is rarely seen in heavily silo-ed companies. Product
development, sales and IT more often listen to the voice of
management rather than the voice of the customer.
Customers don’t directly sign pay checks.
• A movement to bridge this gap called Design Thinking is
helping companies improve customer journeys as
customers cross silo-ed functions. Design Thinking uses
many of the Lean Startup tools, integrating them into a
framework that turns customer responsiveness into a
competitive advantage.

36. Design Thinking
• Customer-centric design focuses the attention of designers onto the
customer instead of the product or marketers. It seeks to create a
customer experience by weaving together touch points from many
different functions within an organization. No single internal
stakeholder has a view into all of the components necessary for a
seamless and profitable customer journey. Dedicated cross
functional teams influence many internal groups to bring about the
transformational mindset changes that are required to create a true
competitive advantage.
• Customer Persona is often used to simulate customer journeys
through a customer journey map. Monte Carlo simulations can be
run to identify bottlenecks and customer frustration points. The
customer journey path tree can be optimized to improve flow and
throughput.

37. “Scaling” frameworks to expand Agile
Project Management
• Agile Scaling extends Agile Development, such as Scrum, from the team
level up to the program level. The goal is to coordinate the efforts of
multiple independent teams that each create customer value.
• In large organizations, Agile Project Management practitioners are often
challenged to integrate their initiatives with others that are going in their
organization. Multiple scrum teams work on the same or different
products, often duplicate efforts, work at cross purposes or create
blockages to each other.
• Multiple development teams experience difficulty coordinating their
production. Product Owners often serve multiple customers represented
by siloed management groups.
• Another, or complimentary approach, is Agile Scale frameworks

38. Agile Scaling Frameworks
• Agile Scaling frameworks are recent innovations but are
quickly evolving into mature disciplines. Scaling agile
development from the team level up to the program level
fosters better coordination and focus. If your firm runs
multiple scrum teams, implementing a scaling framework
will help coordinate development across silos and be more
responsive to management, and, more importantly, the
customer.
• Several authors and organizations have developed scaling
frameworks. Each one has its adherents and constituents.
As Scaling necessarily involves many people, training
courses and coaching many teams in the new framework
becomes important.

39. Scaled Agile Framework (SAFe)
• Scaled Agile Framework (SAFe) was created
created by Dean Leffingwell
http://scaledagileframework.com/author/dea
nleffingwell/
• http://ScaledAgile.com This framework has
been integrated into Rally Software, recently
purchased by Computer Associates.

40. SAFe 4.0

41. Choosing SAFe
• SAFe is a structured, process focused framework that
works well in PMO centric organizations.
• Choose SAFe if you have multiple component teams
creating technical elements that, when combined,
create a viable product. SAFe coordinates separately
developed elements into customer valuable releases.
• First developed at Nokia in 2009, SAFe introduced the
concept of Release Trains to coordinate the integration
of multiple team and multiple sprint production into a
single customer release.

42. Large Scale Scrum (LeSS)
• Large Scale Scrum (LeSS) created by Craig
Larman
• https://www.less.works
• LeSS is supported by the Scrum Alliance
https://www.scrumalliance.org/community/s
potlight/craig-larman/june-2015/less-agile-or-
less-agile

43. LeSS Framework Overview

44. Choosing LeSS
• LeSS operates on the idea that Scrum teams are
each charged with creating shippable product
features without external resources. All
components needed to create a feature must
reside within the same team.
• LeSS comes in two flavors. LeSS and LeSS huge.
• LeSS takes a minimalist approach to Scaling.
Individual teams create customer value
independently, dramatically reducing the need
for comprehensive coordination.

45. Other Agile Scaling Frameworks
• Agile Scaling Model (ASM) - Agile Alliance
http://agilealliance.org
• Scrum of Scrums – also called MetaScrum
• https://www.agilealliance.org/glossary/scrum-of-scrums/
• IBM Agility at Scale Disciplined Agile Delivery (DAD) created
by Scott Ambler
http://www.ambysoft.com/scottAmbler.html
• http://www.disciplinedagiledelivery.com/introduction-to-
dad/

46. Making an Organization Agile
• Richard (Dick) Ellis, PMP PRM CSM PMI-ACP
SSGB
• President Agile Consultants LLC
• http://www.linkedin.com/in/richardellis86
• richardellis86@gmail.com