Agile knowledge check-up: Busting myths on core Agile concepts

Agile Knowledge Check-up
Busting Myths on Core Agile Concepts
Rowan Bunning CST - October 2019 - LAST Conference Canberra

© 2018 Scrum WithStyle scrumwithstyle.com @rowanb
Rowan Bunning
• Background in object oriented & web development with vendors,
enterprise product development, start-ups & consultancies
• Introduced to eXtreme Programming in 2001
• Introduced Scrum organisation-wide in 2003-5
• Agile Coach / ScrumMaster at a leading agile
consultancy in the U.K.
• Have trained about 5,000 people in Scrum & Agile
• Certified ScrumMaster®
• Certified Scrum Product Owner®
• Advanced Certified ScrumMaster
• One of first Agile Coaches in Australia from late 2008
• Organiser of Regional Scrum Gatherings® in Australia
2005
2006
2008
2018
2017
2015
2010

@rowanb© 2019 Scrum WithStyle scrumwithstyle.com
The most important thing to
understand is not what or how, it’s…
Why

Knowledge-check Topics
• Agile
• User Stories
• MVP
• Demo event
• ScrumMaster

What is your organisation seeking from Agile?
Results from LAST Conference Canberra, 15 October 2019

There are many things that an organisation can be optimised for
adaptability / agility
highest customer value
lead time
management status
internal stakeholder
satisfaction
predictability
innovation
employee
engagement
shareholder returns resource utilisation
learning
profittechnical excellence

Using “Agile” for something it was not intended for is like…
…using your car as a dog kennel

If you don’t have a clear outcome…
…you will be attempting to make
important structure and culture
changes without clear direction.

If you don’t have an Agile aligned outcome
…you’ll get something other than
coherent and fully effective Agile.
“Faux Agile”, “Fake Agile” etc.
• Fixed Incremental Development
• Output productivity rather than
Outcome focus
• Water-Scrum-Fall
• Copying without understanding
• Dark Scrum
etc.

It was almost called “Adaptive”
“The top two words were agile and adaptive. We had a
round of discussion and a ﬁnal vote, settling on the word
agile. As I mentioned earlier, although adaptive has certain
advantages, agile is the word we were looking for at the
time. These days, we expect our methodologies to be both
agile and adaptive.”
- Alistair Cockburn on the Lightweight Methods Meeting at Snowbird,
Feb 2001

Jim Highsmith already owned brand “Adaptive”
1999

agility is about adapting
“Agility is the ability to both create and respond to change in order to
proﬁt in a turbulent business environment.” - Jim Highsmith (Manifesto
co-author)
“We considered a bunch of names, and agreed eventually on “agile” as we
felt that captured the adaptiveness and response to change which we felt
was so important to our approach." - Martin Fowler (Manifesto co-author)

agility is not the same as “faster delivery”
“Agile does not mean delivering faster. Agile does not mean fewer
defects or higher quality. Agile does not mean higher productivity. Agile
means agile - the ability to move with quick easy grace, to be nimble
and adaptable. To embrace change and become masters of change - to
compete through adaptability by being able to change faster and
cheaper than your competition can." - Craig Larman (invited to co-author
the Agile Manifesto)
“Agile is moving quickly and easily changing direction.
It's about steering through to the desired outcome." - Alistair Cockburn (Agile
Manifesto co-author)

Which has agility?
Source:YouTube Source: invorma.com/16-super-jumping-animals
or

Where the term “Agile” came from

Shorter Lead Time is only an enabler
shorter lead time
in order to have
agility / adaptiveness
discovery and delivery of highest value to customer
in order to have
high order capability
low order capability
lower cost of change
Assumption: this is not
achievable solely
through up-front analysis
business success
The goal of too many “Agile”
adoptions stops here

Self-OrganisationEmpiricism Time-boxingValue Focus
Principles
Sprint Review Daily Scrum
Sprint
Retrospective
Sprint
Product Owner
Product Backlog
Practices
Enablers of Scrum Outcomes
agility
Highest
Customer Value
Learning
Team
Performance
Outcomes

The “faster delivery” trap
• Increased pressure on “delivery” group
• Starved of time in the learning zone
• High utilisation, further slowing throughput (vicious cycle)
• Accumulation of technical debt, poor design, defects etc.

“Faster delivery” can be achieved by reducing batch size
Batch 1 Batch 2 Batch 3 Batch 4 Batch 5 Batch 6 Batch 7 Batch 8 Batch 9 Batch 10
Batch 1
Batch 1 Batch 2
Batch 1
Batch 2 Batch 3 Batch 4 Batch 5
Time

If you want “faster delivery” try Incremental Development
• “Fixed Incremental”
• Used since the 1950’s (e.g. X-15
hypersonic jet and IBM in L.A.)
• Does not require:
• Agile values and principles
• Scrum or any other Agile method
• Cultural and structural change
• Departure from (mini) waterfall
0018-9162/03/$17.00 © 2003 IEEE2 Computer
Iterative and Incremental
Development:
A Brief History
A
s agile methods become more popular,
some view iterative, evolutionary, and
incremental software development—a
cornerstone of these methods—as the
“modern” replacement of the waterfall
model, but its practiced and published roots go back
decades. Of course, many software-engineering stu-
dents are aware of this, yet surprisingly, some com-
mercial and government organizations still are not.
This description of projects and individual con-
tributions provides compelling evidence of iterative
and incremental development’s (IID’s) long exis-
tence. Many examples come from the 1970s and
1980s—the most active but least known part of
IID’s history. We are mindful that the idea of IID
came independently from countless unnamed pro-
jects and the contributions of thousands and that
this list is merely representative. We do not mean
this article to diminish the unsung importance of
other IID contributors.
We chose a chronology of IID projects and
approaches rather than a deep comparative analy-
sis. The methods varied in such aspects as iteration
length and the use of time boxing. Some attempted
significant up-front specification work followed by
incremental time-boxed development, while others
were more classically evolutionary and feedback
driven. Despite their differences, however, all the
approaches had a common theme—to avoid a sin-
gle-pass sequential, document-driven, gated-step
approach.
Finally, a note about our terminology: Although
some prefer to reserve the phrase “iterative devel-
opment” merely for rework, in modern agile meth-
ods the term implies not just revisiting work, but
also evolutionary advancement—a usage that dates
from at least 1968.
PRE-1970
IID grew from the 1930s work of Walter
Shewhart,1
a quality expert at Bell Labs who pro-
posed a series of short “plan-do-study-act” (PDSA)
cycles for quality improvement. Starting in the
1940s, quality guru W. Edwards Deming began
vigorously promoting PDSA, which he later
described in 1982 in Out of the Crisis.2
Tom Gilb3
and Richard Zultner4
also explored PDSA applica-
tion to software development in later works.
The X-15 hypersonic jet was a milestone 1950s
project applying IID,5
and the practice was consid-
ered a major contribution to the X-15’s success.
Although the X-15 was not a software project, it is
noteworthy because some personnel—and hence,
IID experience—seeded NASA’s early 1960s Project
Mercury, which did apply IID in software. In addi-
tion, some Project Mercury personnel seeded the
IBM Federal Systems Division (FSD), another early
IID proponent.
Project Mercury ran with very short (half-day)
iterations that were time boxed. The development
team conducted a technical review of all changes,
and, interestingly, applied the Extreme Pro-
gramming practice of test-first development, plan-
ning and writing tests before each micro-increment.
They also practiced top-down development with
stubs.
Although many view iterative and incremental development as a modern
practice, its application dates as far back as the mid-1950s. Prominent
software-engineering thought leaders from each succeeding decade
supported IID practices, and many large projects used them successfully.
Craig
Larman
Valtech
Victor R.
Basili
University of
Maryland
C O V E R F E A T U R E
Published by the IEEE Computer Society

Further information

What is a User Story?

Template
Who
What
Why
As a <role>
I want <goal / task>
so that <benefit>.
From Connextra

3 C’s
1. Conversations
2. Card
3. Conﬁrmation
As a holiday maker, I can
cancel a reservation.
•A premium member can cancel the same
day without a fee.
•A non-premium member is charged 10% for
a same-day cancellation.
•An email confirmation is sent.
This story only calls for a basic, functional
version of this.
From Ron Jeffries

“There might not even be a Card”
“C3 tried a standard format card in something like 1998 and realized
it was a bad idea then, and we said so.”
“We all get together with our Customer / Product Owner, and we talk
about the product. What problems does it solve, how might it solve
them. We’d tell each other stories about problems and solutions.
We’d draw pictures of the product. We’d probably talk with real users
or visit their sites and watch them work. We would conceptualize the
product, trying to give the whole team a rather consistent view of
what needed to be done. This would be a large-scale Conversation.”
…
There might not even be a Card at all!

The story that inspired User Stories
What I was thinking of was the way users
sometimes tell stories about the cool new things
the software they use does:
“I type in the zip code and it automatically ﬁlls in
the city and state without me having to touch a
button!”
I think that was the example that triggered the
idea. If you can tell stories about what the
software does and generate energy and interest
and a vision in your listener's mind, then why not
tell stories before the software does it?

“Requirement” runs counter to embracing change
Software development has been steered wrong
by the word ‘requirement,’ deﬁned in the
dictionary as “something mandatory or
obligatory.”
The word carries a connotation of absolutism and
permanence, inhibitors to embracing change.
And the word ‘requirement’ is just plain wrong.
Image credit: Meatball IO on Medium

What is a Minimum Viable Product?

MVP took off after the Lean Startup was published

Eric Ries on MVP
"A minimum viable product (MVP) helps entrepreneurs start the
process of learning as quickly as possible. It is not necessarily the
smallest product imaginable, though; it is simply the fastest way to
get through the Build-Measure-Learn feedback loop with the
minimum amount of effort.”
"Minimum viable products range in complexity from extremely
simple smoke tests (little more than an advertisement) to actual
early prototypes complete with problems and missing features."
"The lesson of the MVP is that any additional work beyond what
was required to start learning is waste, no matter how important it
might have seemed at the time.”
- Ries, Eric. The Lean Startup: How Constant Innovation Creates Radically Successful Businesses. Penguin Books Ltd.

What is Dropbox? Explained! Original Dropbox Video
https://www.youtube.com/watch?v=xy9nSnalvPc
What’s the MVP here?
(see the next slide)

The Dropbox MVP
"In this case, the video was the minimum viable product. The MVP
validated Drew’s leap-of-faith assumption that customers wanted
the product he was developing not because they said so in a
focus group or because of a hopeful analogy to another business,
but because they actually signed up."
- Ries, Eric. The Lean Startup: How Constant Innovation Creates Radically Successful Businesses. Penguin Books Ltd.

Don’t confuse two different concepts
The Minimum Viable Product and the
Minimal Marketable Product
Posted on Wednesday 9th October 2013
Summary
The Minimum viable product (MVP) is a powerful concept that allows you to test your ideas.
It is not to be confused with the minimal marketable product (MMP), the product with the
smallest feature set that still addresses the user needs and creates the right user
experience. The MVP helps you acquire the relevant knowledge and address key risks; the
MMP reduces time-to-market and enables you to launch your product faster. This post
discusses both concepts, and it shows how you can use the minimum viable product to
create a minimal marketable one.
The Minimum Viable Product
The minimum viable product (MVP), as deﬁned by Eric Ries, is a learning vehicle. It allows
you to test an idea by exposing an early version of your product to the target users and
customers, to collect the relevant data, and to learn form it. For instance, to test the viability
of using ads as the major revenue source, you could release an early product increment
with fake ads, and measure if and how often people click on them.
As lack of knowledge, uncertainty, and risk are closely related, you can also view the MVP
as a risk reduction tool. In the example above, the MVP addresses the risk of developing a
product that is not economically viable.
Since the MVP is about learning, it’s no surprise that it plays a key part in Lean Startup’s
build-measure-learn cycle, as the following picture shows:
you to test an idea by exposing an early version of your product to the
customers, to collect the relevant data, and to learn form it. For instanc
of using ads as the major revenue source, you could release an early p
with fake ads, and measure if and how often people click on them.
As lack of knowledge, uncertainty, and risk are closely related, you can
as a risk reduction tool. In the example above, the MVP addresses the
product that is not economically viable.
Since the MVP is about learning, it’s no surprise that it plays a key part
build-measure-learn cycle, as the following picture shows:
The MVP is called minimum, as you should spend as little time and effo
this does not means that it has to be quick and dirty. How long it takes
© 2015 Pichler Consulting Limited Author: Roman Pichler. See romanpichler.com
- Roman Pichler, Pichler Consulting.

It's about hypothesis testing
"a hypothesis means we have an educated
guess that requires experimentation and
data to validate or invalidate.” - Steve Blank

What do you call the event at which you
do a demonstration?

What is the purpose of Sprint Review?

Sprint Review deﬁnition in The Scrum Guide™ (1)
Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product
Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate
about what was done in the Sprint. Based on that and any changes to the Product Backlog
during the Sprint, attendees collaborate on the next things that could be done to optimize value.
This is an informal meeting, not a status meeting, and the presentation of the Increment is
intended to elicit feedback and foster collaboration.
This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is
usually shorter. The Scrum Master ensures that the event takes place and that attendees
understand its purpose. The Scrum Master teaches everyone involved to keep it within the time-
box.
The Sprint Review includes the following elements:
• Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
• The Product Owner explains what Product Backlog items have been “Done” and what has
not been “Done”;
• The Development Team discusses what went well during the Sprint, what problems it ran
into, and how those problems were solved;
• The Development Team demonstrates the work that it has “Done” and answers questions
The Scrum Guide™
The Definitive Guide to Scrum:
The Rules of the Game
November 2017
Developed and sustained by Scrum creators: Ken Schwaber and Jeff Sutherland

Sprint Review deﬁnition in The Scrum Guide™ (2)
The Scrum Guide™
November 2017
understand its purpose. The Scrum Master teaches everyone involved to keep it within the time-
box.
The Sprint Review includes the following elements:
• Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
• The Product Owner explains what Product Backlog items have been “Done” and what has
not been “Done”;
• The Development Team discusses what went well during the Sprint, what problems it ran
into, and how those problems were solved;
• The Development Team demonstrates the work that it has “Done” and answers questions
about the Increment;
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely
target and delivery dates based on progress to date (if needed);
• The entire group collaborates on what to do next, so that the Sprint Review provides
valuable input to subsequent Sprint Planning;
• Review of how the marketplace or potential use of the product might have changed what is
the most valuable thing to do next; and,
• Review of the timeline, budget, potential capabilities, and marketplace for the next
anticipated releases of functionality or capability of the product.
The result of the Sprint Review is a revised Product Backlog that defines the probable Product
Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new
opportunities.

Further information
The Scrum Guide™
November 2017

Which are the primary functions of a
ScrumMaster at your organisation?

Who does a ScrumMaster provide
service to at your organisation?
Go to menti.com and use code 44 66 11

Scrum Guide deﬁnition of Scrum Master (1)
Scrum Master Service to the Product Owner
The Scrum Master serves the Product Owner in several ways, including:
• Ensuring that goals, scope, and product domain are understood by everyone on the Scrum
Team as well as possible;
• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog items;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.
Scrum Master Service to the Development Team
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.
Page | 7
coordination. Large Development Teams generate too much complexity for an empirical process
to be useful. The Product Owner and Scrum Master roles are not included in this count unless
they are also executing the work of the Sprint Backlog.
The Scrum Master
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum
Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules,
and values.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those
outside the Scrum Team understand which of their interactions with the Scrum Team are helpful
and which aren’t. The Scrum Master helps everyone change these interactions to maximize the
value created by the Scrum Team.

Scrum Guide deﬁnition of Scrum Master (2)
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.
Scrum Master Service to the Development Team
The Scrum Master serves the Development Team in several ways, including:
• Coaching the Development Team in self-organization and cross-functionality;
• Helping the Development Team to create high-value products;
• Removing impediments to the Development Team’s progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the Development Team in organizational environments in which Scrum is not yet
fully adopted and understood.
Scrum Master Service to the Organization
The Scrum Master serves the organization in several ways, including:
• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product
development;
• Causing change that increases the productivity of the Scrum Team; and,
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum
in the organization.

From the original Certiﬁed ScrumMaster
training material by Ken Schwaber - 2006
Customer collaboration over contract
negotiation
No intermediaries
Teacher to primary business stakeholder
Humanist, cultivate people
High agency team, bounded autonomy
Change agent to power distribution
Impediment removal facilitator
Team end-to-end cross-functional
Tech practices as core part of role

CHANGE AGENTSERVANT-LEADER MANAGER
FACILITATOR TEACHERCOACH
MENTOR REFLECTIVE OBSERVER
IMPEDIMENT REMOVER
Skilful ScrumMasters operate from each of these stances
We study these in Advanced Certiﬁed ScrumMaster (A-CSM) See: scrumwithstyle.com

self-management
cross-functional
servant-leader
lean
values-based
humanistic
networks over hierarchies
Theory Y
coach
bureaucracy elimination
transparency enhancer
facilitator capability builder

Origins of “Iteration Manager”
“When teams were struggling to ﬁnd high-priority work to do on one
particular project in 2000, the solution was to identify someone who could
provide a continual stream of high-priority functionality at a sustainable
pace to the delivery teams. This is the role that has grown into the
iteration manager (IM).”
- ”What Is an Iteration Manager Anyway?", Tiffany Lentz, The ThoughWorks Anthology, 2008.
“The split between release and iteration managers reﬂects the style and
preferences of the two individuals that do it... We don't think our solution
is one that necessarily everyone should follow.”
- martinfowler.com/articles/planningXpIteration.html

Further information
The Scrum Guide™
November 2017
An Example Checklist for ScrumMasters
Michael James
Danube Technologies, Inc.
http://www.danube.com
michael@danube.com
14 September 2007
(Revised 13 November 2009)
A Full Time Facilitator?
An adequate ScrumMaster can handle two or three teams at a time. If you're content to limit your role to
organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can
get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation
at your organization, and probably nothing catastrophic will happen.
But if you can envision a team that has a great time accomplishing things no one previously thought possible,
within a transformed organization -- consider being a great ScrumMaster.
A great ScrumMaster can handle one team at a time.
We recommend one dedicated ScrumMaster per team of about seven, especially when starting out.
If you haven't discovered all the work there is to do, tune in to your Product Owner, your team, your team's
engineering practices, and the organization outside your team. While there's no single prescription for everyone,
I've outlined typical things I've seen ScrumMasters overlook.
Part I -- How Is My Product Owner Doing?
You improve the Product Ownerʼs effectiveness by helping maintain the Product Backlog and release plan. (Note
that only the Product Owner may prioritize the backlog.)
Is the Product Backlog prioritized according to his/her latest thinking?
Are requirements and desirements from all stakeholders captured in the Product Backlog? Remember this
backlog is emergent.
Is the Product Backlog a manageable size? To maintain a manageable number of items, keep things more
granular towards the top, with general epics at the bottom. It's counterproductive to overanalyze too far past
the top of the Product Backlog. Your requirements will change in an ongoing conversation between the
developing product and the stakeholders/customers.
Could any requirements (especially those near the top of the Product Backlog) be better expressed as
independent, negotiable, valuable, estimable, small, and testable user stories1?
Have you educated your Product Owner about technical debt and how to avoid it? One piece of the puzzle
may be adding automated test and refactoring to the definition of "done" for each backlog item.
Is the backlog an information radiator, immediately visible to all stakeholders?
Does your definition of "done" (acceptance criteria) for each functional Product Backlog Item include full
automated test coverage and refactoring? Youʼre unlikely to build a potentially-shippable products every
Sprint without learning eXtreme Programming10 practices.
Are team members pair programming most of the time? Pair programming dramatically increases code
maintainability and reduces bug rates11. It challenges people's boundaries and sometimes seems to take
longer (if we put quantity over quality). Lead by example by initiating paired workdays with team members.
Some of them will start to prefer working this way.
Part IV -- How is the organization doing?
Is the appropriate amount of inter-team communication happening? Scrum of Scrums is only one way to
achieve this.
Are teams independently able to produce working features, even spanning architectural boundaries?12
Are your ScrumMasters meeting with each other, working the organizational impediments list?
When appropriate, are the organizational impediments pasted to the wall of the development director's office?
Can the cost be quantified in dollars, lost time to market, lost quality, or lost customer opportunities? (But
learn from Ken Schwaber's mistakes: "A dead ScrumMaster is a useless ScrumMaster."13)
Is your organization one of the few with career paths compatible with the collective goals of your teams?
Answer "no" if there's a career incentive14 to do programming or architecture work at the expense of testing,
test automation, or user documentation.
Has your organization been recognized by the trade press or other independent sources as one of the best
places to work, or a leader in your industry?
Are you helping create a learning organization?
Conclusion
If you can check off most of these items and still have time left during the day, Iʼd like to hear from you.
Thereʼs no canned formula for creating human ingenuity. This paper lists points which may, or may not, help in
your situation.
Once you start to realize what you could do to make a difference, you may find yourself afraid to do it. This is a
sign you're on the right track.
Copyright © 2007-2009 Danube Technologies, Inc. All Rights Reserved.
10 http://www.extremeprogramming.org/
11 http://www.agilealliance.org/article/articles_by_category/35
12 Craig Larman/Bas Vodde, Scaling Lean & Agile Development (2007)
13 Ken Schwaber, Agile Project Management with Scrum (2004)
14 Alfie Kohn, Punished By Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes (1999)
…
scrummasterchecklist.orgscrumguides.org

Why do we have these
varied understandings?

Semantic Diffusion
"Semantic diffusion occurs when you have a word that is
coined a person or group, often with a pretty good
definition, but then gets spread through the wider
community in a way that weakens that definition. This
weakening risks losing the definition entirely - and with it
any usefulness to the term.” - Martin Fowler

Larman's Laws of Organizational Behaviour
1. Organisations are implicitly optimised to avoid changing the status quo middle and
first-level manager and “specialist” positions & power structures.
2. As a corollary to (1), any change initiative will be reduced to redefining or
overloading the new terminology to mean basically the same as status quo.
3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”,
“revolutionary”, "religion", and “needing pragmatic customisation for local
concerns” — which deflects from addressing weaknesses and manager/specialist
status quo.
4. As a corollary to (1), if after changing the change some managers and single-
specialists are still displaced, they become “coaches/trainers” for the change,
frequently reinforcing (2) and (3).
5. Culture follows structure.
www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior

What are you going to do?
Turn to the person next to you and take turns to
share answers to:
1. Which Agile concepts are being missed at your
organisation?
2. Which is the ﬁrst that you will start discussing?

@rowanb au.linkedin.com/in/rowanbunning
Rowan Bunning
rowan@scrumwithstyle.com scrumwithstyle.com
Thank you!
Let’s connect

Agile knowledge check-up: Busting myths on core Agile concepts

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Agile knowledge check-up: Busting myths on core Agile concepts

Similar to Agile knowledge check-up: Busting myths on core Agile concepts (20)

More from Rowan Bunning

More from Rowan Bunning (15)

Recently uploaded

Recently uploaded (20)

Agile knowledge check-up: Busting myths on core Agile concepts