Agile Myths and Pitfalls - 2020 (ver 0.8)

Agile Myths & Pitfalls
openware
Code Garden 09.2020

Agile is Mainstream
• One of the key features of agile methods is that they
are PeopleOriented. They recognize that people and how they work
together is the primary factor in software development, and that
processes are a secondary factor. This is reflected in the first value
of the agile manifesto "Individuals and interactions over processes
and tools" and is reinforced by two principles of the manifesto:
• Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
• The best architectures, requirements, and designs emerge from
self-organizing teams.

AGILE MEANS ‘NO DOCUMENTATION'
• The adaptive and iterative nature of agile places
less emphasis on the need for documentation
compared to waterfall, but that does not mean
that no documentation is required.

• Elements of the project continuously evolve as additional
information becomes available and user needs are
defined.
• A traditional approach results in detailed documentation
at the end of each phase.
• Agile Approach: less documentation
• In agile, an appropriate level of documentation will be an
output of each iteration.

Developing adequately detailed documentation for agile is a
necessity to:
• Meet the needs of project stakeholders.
• Document decisions made.
• Support communication with external groups, including
stakeholders outside the project team or for team members that
cannot collocate.
• Support the use, operation and maintenance of the system.
• Capture lessons learned for continuous improvement and to benefit
future projects.
• Report project status and performance metrics.

• The effective management of a project should have
value-driven documentation that supports the project
team’s communication with stakeholders, and enables
the business to use the product effectively, and the
technical team to support and maintain it.
• When considering what documentation looks like in your
project, think about the value of the document or if it is
needed, what information needs to be captured, when it
needs to be captured, with whom it needs to be shared,
and how that documentation might help the team
improve.

• Agile Means Documentation that is Actually Read
• User Stories are in a form that is meaningful to all
parties, expresses business objectives.
• Acceptance Tests removes ambiguity from
requirements.
• Unit Tests describe the behaviour of methods.

AGILE IS UNDISCIPLINED
• Agile project management and system development
practices are not only demanding of the project team, but
they also require the support and a shared commitment for
success by the leaders of the organization.
• The continuous integration and test-driven development of
agile requires skill, coordination, collaboration, and
discipline from the entire project team.

AGILE IS UNDISCIPLINED
• Successful agile teams consistently deliver quality product
increments that demonstrate working functionality in short
time frames to provide value and benefit to the
organization.
• To achieve this level of delivery, the leaders of the
organization must delegate authority to the team to enable
them to make decisions rapidly; this requires a high degree
of developer and team discipline.

MYTH: AGILE MEANS 'NO PLANNING'
Agile Myths and Misconceptions

AGILE MEANS 'NO PLANNING'
• As with any approach,
planning is a vital
aspect that, if not
adequately carried out,
greatly diminishes the
effectiveness of a
successful
implementation.

No extensive planning upfront. Agile spread this activity.
This continuous planning allows a project to start much
quicker and to be more nimble to make ongoing adjustments
in strategy as new information becomes available.
Changes in business needs or priorities; project issues, risks, or
resources; and even changes in available technology.

It also provides the project team with the ability
to more easily and efficiently adapt to changes
and optimize plans as new information emerges.

MYTH: AGILE IS SHORT MILESTONES

Waterfall with many short Milestones
• Iterations 1 – 4:
Requirements
Gathering Design
Implementation
SIT/UAT
Production Support

MODULE MILESTONES
(Multiple Short Waterfalls)
• Phase 1: Ordering Module
• Phase 2: Prder Processing Module
• Phase 3: Billing Module
• Phase 4: User Management

ITERATIVE DEVELOPMENT
• It's not just about frequent deliveries.

Working software produced at
each iteration
• Progress measured by
working features
– No such thing as “X%
complete”, only done and
not done at the end of a
sprint
• Done means tested, ready
to deploy

AGILE = SCRUM
• Scrum is a popular development methodology that is
iterative and adaptive; however, Scrum and agile are not
the same thing.
• Scrum is a framework for developing and managing
work, while agile is an approach that follows a common
set of values and principles that many methodologies fall
under.

AGILE = SCRUM
Agile projects/products do not have
to adopt any particular development
methodology

AGILE = SCRUM
• Organizations must assess each development
methodology to identify which is best suited for the
environment.
• It is important to understand that the different
development methodologies all focus on understanding
and meeting the users’ needs in a flexible and iterative
way.

AGILE = SCRUM
• Some agile practices can and should be leveraged to
complement a waterfall approach also in organizations
not ready toi a full agile adoption.
• This includes those that pertain to the culture and
environment of an organization (e.g., collocating teams,
having access to business owners), or to project planning
(e.g., deploying the project over several releases instead
of one release at the end).

AGILE = SCRUM
• Agile development methodologies have a greater chance
of successfully achieving the desired outcomes when
adopted in its entirety; this incremental adoption of agile
organizational and planning practices can help lay the
foundation for a later adoption of an agile development
methodology.

AGILE = SCRUM
• Scrum is just one of many methodologies that come
under the umbrella of agile values and principles.
• Other methodologies include Scaled Agile (in many
formats), Extreme Programming and Kanban.

Agile
Pratiche Agili
Principi Agili
Valori Agili
Necessità di
rispondere al
cambiamento
continuo

Agile
Agile Practices
Agile Principles
Agile Values
Need to respond
to continuous
change

Learning
Organization
Lean
Thinking
Agile
Approaches
Scrum, XP, …
Morevalue/philosophical
Moreprescriptive
Applicability
Advancing /
Deepening /
Improving

Scrum
eXtreme
Programming
Crystal
Clear
Feature Driven
Development
DSDM
AgileUP
Lean
Development
Kanban

Agile Has Equal (or greater) Focus on
Engineering
• Early Agile methodologies were heavy on
engineering
– Test-Driven Development, Coding Practices,
Design Patterns, etc.
• Scrum originally focused on just project
management, but lately is reemphasizing
engineering

Agile Has Equal (or greater) Focus on
Engineering

MYTH: AGILE MEANS NO MANAGERS

«SELF ORGANIZING TEAMS»
• “There’s a reason we use the term 'self-
organizing' rather than 'self-organized' or 'self-
managed.'
• “That’s because it’s a process and a
characteristic, not something that is done
once and for all.”
- Esther Derby

Self-Organizing Team: Mature, responsible, self-
directed courageous people.
– Aligned with company objectives
– Solicits and provides feedback
– Productivity visible to the organization
– Works within financial and regulatory boundaries.
To get there: Different people/teams need different
management approaches.
– Maturity, culture, motivation, discipline, awareness, etc.

Agile Myths
• Il termine mito deriva dal
greco mythos, ovvero parola, discorso,
racconto.
• Il mito è una narrazione fantastica rivestita di
sacralità, che descrive l’origine di culture, di
popoli, di fenomeni, di realtà esistenti e del
mondo stesso, e che ne racconta inoltre le
caratteristiche attuali.

MYTH 2: AGILE MEANS “NO GOVERNANCE”

AGILE MEANS ‘NO GOVERNANCE'
• Within an agile
approach, the team
members working on
the project have
autonomy over
decisions about how to
meet the needs of the
user.

• Most state organizations will find it difficult to allow
project teams complete autonomy.
• Transitioning to agile may need to modify
governance practices.
• To create an environment that supports team
autonomy, the organization should establish a
governance process that meets regularly.

• Defining lightweight, fast moving, and effective
project governance is incredibly important for agile
project success.
• The key is to establish a process that is appropriately
specific, but not overly prescriptive.

MYTH 4: AGILE PRACTICES ARE NEW

AGILE PRACTICES ARE NEW
• The practices of agile have been around for the greater
part of the last century.

• In the 1930s, physicist Walter Shewhart began improving
products and processes through iterative cycles.
• This practice was later modified by W. Edwards Deming
to become the Plan-Do-Study-Act (PDSA), also known as
Plan-Do-Check-Act (PDCA), cycle for continuous
improvement and quality management.

• Up through the 1980s, the United States military, NASA,
IBM, Honda, Toyota, Canon and others continued to
experiment with and evolve concepts and practices we
recognize as agile.
• These ideas led to the publication of the Agile Manifesto
in 2001 and identification of the common values and
principles for improving the approach to system
development projects.

• Currently, several varieties of agile-based methodologies
are used in these efforts, including Scrum, Extreme
Programming (XP), and in some cases, Kanban.

MYTH 5: AGILE ONLY WORKS WITH SMALL
PROJECTS

AGILE ONLY WORKS WITH SMALL PROJECTS
• An agile development
team consists of small,
cross-functional groups
that collaborate
throughout the
development process.

• Equally effective on small projects and larger efforts to
develop complex systems, since agile teams typically
“divide and conquer.”
• For larger projects, this means that multiple teams can
be organized and focus on separate components of
system functionality and/or technical architecture.
• Feature Teams vs Component Teams
• Especially for the large and complex, continuous
integration of developed components on a daily if not
more frequent basis is a critical success factor.

• In an agile project with typically short development
iterations, parallel development efforts, and frequent
delivery of functionality, project teams must integrate
their work often to detect and resolve errors as quickly
as possible, with the ultimate goal of being able to
deploy at any time.
• DevOps practices and philosophy of Continuous
Integration and Continuous Delivery.

• If project teams delay the integration to just-prior-to-
release, they will likely run out of time to adequately
perform testing, address defects, and prepare the
infrastructure.
• Agile teams should ensure that they have the right
automated build and test tools, and the appropriate
processes in place to support continuous integration.

MYTH 7: IMPLEMENTING AGILE IS EASY

IMPLEMENTING AGILE IS EASY
• Change is hard.
• Transitioning an organization that is more accustomed to
a traditional waterfall approach to an agile approach is
not an exception to this rule.
• A significant number of organizations will not have
practices and procedures that are geared towards those
of an adaptive approach and will likely need to focus on
adapting the project team’s project management and
system development processes to the unique
characteristics of the organization, project, and people.

• To achieve the full benefits, project teams must not only
learn the best practices of agile; it is also important to
understand the specific circumstances of the
organization’s culture and the project/product.
• To start, the project team should assess the
organization’s readiness and whether the selected
project is the right fit for agile.

• Import areas of evaluation:
– organization’s existing governance structure
– project management processes
– level of management buy-in to both support and be an
agent for change

• It is important to invest the time, resources, and effort to
establish the culture, expectations, and infrastructure to
support the implementation of an adaptive methodology.
• Learning how to work in an agile way requires practice,
commitment, clear and timely governance, and learning by
doing.
• For those with little or no experience, consider leveraging
an agile approach for a smaller effort to demonstrate
success and the team’s proficiency before moving on to
something bigger.

MYTH 8: PURE AGILE IS THE ANSWER

PURE AGILE IS THE ASWER
• Employing agile practices will not be the solution to all
project management and IT development issues
encountered with a traditional approach, as agile may
not meet the varying needs of the organization.
• Doing anything new within an organization often
introduces elements of additional project risk.

• In this kind of environment, the implementation of agile
practices and principles should be done pragmatically
and take into consideration the real-world environment
in which the project is managed and the system is
developed.

• To realize benefits associated with an adaptive
methodology without an overhaul of the current
environment, organizations can moderate the degree of
change.
• A project that takes place in a government context will
likely be more successful if it integrates adaptive and user
centered practices into its traditional waterfall approach.
• This could be due to rules, regulations, or the
organizational structures and cultural expectations that are
heavily based on traditional waterfall processes.

• For small changes, organizations can consider incorporating
the following practices to be more adaptive:
– Conduct and communicate lessons learned frequently and not
just at the end of the project.
– Have short (15 minute) daily stand-up meetings to provide a
venue for project team members to communicate roadblocks
they are experiencing, and for management to help resolve.
– Manage each project team member’s work-in-progress. Set
clear and realistic expectations for what work can be
accomplished in a given period to not over-allocate resources.

MYTH 12: AGILE IS UNPREDICTABLE

Agile is Evidence-Based Decision-
Making
• Requirements of future iterations based on user
feedback from previous iterations.
• Schedules are based on experience from previous
iterations.
• Architecture based on Spikes, not literature.

MYTH 14: AGILE CANNOT WORK WITH FIXED
BUDGETS

Fixed-Budget, Fixed-Scope
• Typical Scenario:
1. Project budget and detailed requirements are set in
beginning.
2. Requirements are achieved, with plenty of overtime, and
usually delays.
3. System is unusable because of mismatch to business needs
and bugs.
4. Additional project phases needed to accommodate actual
business needs and fix bugs.
5. Repeat X times.
6. So what happened to the fixed budget?

In Agile …
• Budgets are fixed.
– Based on team composition and duration.
• Business objectives are defined.
– First to market? Win customers from competition? Reduce cost? Integrity
• of financial transactions? Reduce human error? Reduce process time?
Scope is variable.
• Deliver something early that meets business needs.
– Early ROI
• Base succeeding iterations on feedback.
– Customer uptake, stakeholder feedback, etc.
• When project ends, organization is left with a valuable, useful product,
within a fixed budget.

MYTH 15: AGILE WILL PREVENT PROBLEMS

Agile will make problems visible, early
and often
• … so that they are easier to fix.
– Expect to initially experience more problems, not
less.
• Waterfall reveals problems only later, when
they are hard to fix.

MYTH 16: AGILE WILL PREVENT PROBLEMS

MYTH 17: AGILE MEANS NO MANAGERS

MYTH 18: AGILE MEANS WEAK CONTROL

TRADITIONAL CONTROL
Status Reports
• “We are 90% done.”
– Based on what?

AGILE FEEDBACK
• Working Features
• Customer Satisfaction!
• Test Coverage
• Performance Tests
• Velocity / Burndown
Charts
• Fine-grained commits,
commit logs
• Continuous Integration
• Static Analysis
– Cyclomatic Complexity
– Coding Standards
– Common Bugs
– Technical Debt
• Web Analytics

MYTH 19: YOU’RE AGILE OR YOU’RE NOT
AGILE

AGILE IS A CONTINUUM
• No such thing as a “perfectly Agile” team.
– Constraints – other departments, maturity of team members,
clients, schedules, regulation, etc.
– Continuous improvement – always something that can be done
better
• Be iterative in your Agile adoption.
– Take small steps that will achieve quick wins.
– What one value or practice can you adopt this week/month that
will show visible gains?

146
• Puoi essere disciplinato o agile.
• Abbiamo bisogno di documentazione dettagliata di tutti i
requisiti nel fase uno, oppure non possiamo conoscere
obiettivi o sforzo.
• Tutto sarà completato entro il 1 di maggio?
• Le stime sono corrette oppure no?
• Tutti i passi devono essere predeterminati, o non possiamo
fare previsioni.
• I gruppi auto-organizzati sono anarchia.
• Dobbiamo assegnare tutte le attività alle risorse, oppure non
pianifichiamo.
• Facciamo TDD, quindi non facciamo nessuna modellazione.

dettaglio
investimento
modellazione
documentazione
continuum

Pitfall #1
Introducing agile without a clearly understood,
agreed to, and articulated need.
• Most organizations have plenty of room for
improvement in their software development
process.

Pitfall #1
• Who to Change?
– When planning the introduction of agile approaches, we
have far more than just the development team to
consider. In fact, the successful adoption depends on a
variety of stakeholders.
• Executives
– We need to win their support for the change. They are our
enablers and obstacle removers.

Pitfall #1
• Project Sponsors
– These people hold the budget and are powerful project
influencers. If we want to get approval to try new
approaches, we need to convince sponsors, too.
• Managers
– Managers are typically the resource controllers, so we
really need them on board. They can be useful allies or
roadblocks to adopting a new process.

Pitfall #2
Not engaging all the necessary stakeholders.
• You don’t need to get formal written approval from
each of these groups before introducing agile, but be
aware the success of an agile introduction goes much
beyond the development team.
• Plan to interact and communicate often to win over
as wide an audience as you can.

Pitfall #2
• What to Change?
– What may require changing is likely to be wider ranging
than you might think.
• New methods of decision-making
– Dictatorial, command-and-control decision-making does
not fit agile approaches. When the team does more of
their own local planning, we should have better ways of
gaining consensus and resolving conflicts.

Pitfall #2
• Empowered teams
– Are the project managers ready and willing to turn over
iteration planning to the team? Is the team ready?
– While iterative projects can be run as short waterfall
projects, the real benefits of agile are only realized when
we learn how to tap into the ownership, power, and
accountability of empowered teams.

Pitfall #3
Not considering the full scope of changes
required.
• Agile change processes welcome late-breaking
changes while many traditional change management
processes are really “change prevention” processes.
• However, some people will feel uncomfortable
without the two-inch-thick binder of (out of date)
requirements on their desk.

Pitfall #3
• Relating to superiors and/or staff members
differently
– The role of a project leader on an agile team is
more a servant leadership role than command-
and-control directing. Most good project
managers already know their role is to make the
project team successful. Project managers do not
add a lot of business value to software products,
so they need to support the team.

Pitfall #4
Not considering the social factor impacts of the
change.
.
• However, for some traditional project managers, this
downward-serving model and increased levels of
team planning and decision-making can feel
threatening.

Pitfall #4
• When to Change?
– We must also consider the timing of the change to
agile. Below are some potential scenarios to
consider.
• When there are problems with current processes
– The current process consistently delivers late, over
budget, or poorly accepted software.

Pitfall #4
• When new projects have unknown requirements
– A project requirement like, “We need a customer
self-service portal,” is likely to have a high rate of
requirements evolution as the details become
clear.

Pitfall #4
• When new projects occur with high technical risk
– Examples include using new languages,
unprecedented technology, and untested
interfaces. Whenever there is high technology
risk, the iterative nature of agile projects is great
for reducing risks early in the lifecycle.
• Time critical projects
– Timeboxed iterations and feature prioritization are
effective ways of ensuring the best possible
delivery for a fixed deadline.

Pitfall #5
Assuming it is always best to use an agile
approach.
• We can also look to suitability filters to help guide us.

Pitfall #5
• What to consider
– If, for example, our project has characteristics
close to the inside of the chart, then an agile
approach is suitable.
– However, if our project scores toward the middle
of the chart, a hybrid may be best. Scores around
the plan-driven periphery indicate an agile
approach may not be the best approach for the
project.

Craftmanship
openware
28.09.2020

Make People Awesome
• Steve Jobs used to ask his colleagues, “What
incredible benefits can we give to the customer?
Where can we take the customer?”
• In modern agile we ask how we can make people in
our ecosystem awesome.

Make Safety a Prerequisite
• Safety is a basic human need and a key to
unlocking high performance.
• Modern Agile elevates it to a prerequisite, a
foundational ingredient for success.

Experiment & Learn Rapidly
• You can’t make people awesome or make safety
a prerequisite if you aren’t learning.
• We learn rapidly by experimenting frequently.

Deliver Value Continuously
• Anything that isn’t delivered isn’t helping
anyone become more awesome or safe.

Agile Myths and Pitfalls - 2020 (ver 0.8)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Agile Myths and Pitfalls - 2020 (ver 0.8)

Similar to Agile Myths and Pitfalls - 2020 (ver 0.8) (20)

More from Fabio Armani

More from Fabio Armani (20)

Recently uploaded

Recently uploaded (17)

Agile Myths and Pitfalls - 2020 (ver 0.8)