VIRAL CHANGE™ CONSIDERATIONS
FOR AGILE IN PRACTICE
 Viral Change™ from Leandro Herrero of the Chalfont Project
 Let’s map out the highly influential, highly connected trusted people – a small group of great
people can do great things. Let’s ask them for help!
 Let’s agree non-negotiable behaviours for each method on an imaginary method
continuum
 Let’s accumulate memorable & transferable stories of good behaviours for “people like me”
 Our influencers will lead by example and provide “social proof” for imitators
 Backstage leadership
 Formalized informal community with no limits on tools to use
 Let’s be clearer about Iterative and Agile methods for people who need that clarity

FOOD FOR THOUGHT ON
EXAMPLE BEHAVIOURS- SHOULD
WE USE VIRAL CHANGE ™
Are these the ones?
Are there more?
Which would be non-negotiable?
Of those, what stories are there for “people like me”

WATERFALL BEHAVIOURS -
WHICH BEHAVIOURS ARE NON-NEGOTIABLE? ARE THERE MORE?
 Use fixed price, fixed scope, fixed date
contracts. Unfix quality.
 Build & maintain credible, competitive, and
affordable plans
 Comply with controls
 Consider mandatory deliverables
 Consider approach given risk & scale
 Consider business readiness/change
 Seek guidance before scaling
 Try to understand – ask why?
 Good dependency management
 Good supporting function engagement
 Working in silos & perform handovers.
 Get everyone to work in one room to recover
from / avoid failure
 Document everything up front
 Business case, Plans, Task break-down
 Requirements. Designs
 Risks, issues, dependencies, assumptions
 Tests including end to end & non-functional
 Do latest Baseline? If so, when is the latest?
 Everything is a must have
 Manage change through change control –“out
of scope”
 Manage budget
 Implement practises as per PRINCE2/PMBoK
 Business people perform user acceptance tests
 Review regular formal status reports –RAG
 Heavy governance model
 Risk based testing
 Discover security/usability/performance bugs
during pre-go-live hardening phase
 Quality is measured by the number of
prioritized defects from testing before go/nogo
& the number of issues post go live
 Manage the risk register – have mitigating
actions and owners & follow up
 Report earned value
 De-scope or move date/cost if in trouble
 Exert high energy and overtime towards the
end
 Perform “conference room pilot testing”

“DO WHATEVER” BEHAVIOURS
 “success theatre”, data-free zone
 “Low ball” project risk
 Use fixed price, fixed scope, fixed date
contracts.
 Tell vendor to “be Agile” or to do our custom
method w/o training
 Build & maintain hopeful plans; the team needs
stretch goals
 Dodge controls
 Escalate to get interfering QA folks out of way
 Big bang
 Dodge controls
 Only care about getting across the line.
 No dependency management – escalate instead
 Little / no supporting function engagement
 Disrespect, unhelpful behaviour
 Measure perceived effort, not results
 Document something up front
 Vague plans, risks rot on risk register
 Poor functional requirements. No NFRs,
late designs only because we have to
 Tests planning only “independent” testing
 Deal with today’s emergencies first – watch the
optics
 Rely on heroic efforts to save the day
 Absorb every change – we’ll do it!
 Go significantly over budget or deliver nothing
within budget
 Business people perform user acceptance tests
 Review regular formal status reports –RAG
 Use a lightweight governance model
 Start testing late and take longer than
expected
 What’s a hardening phase?
 Quality is measured by the number of defects
from testing before go/nogo & the number of
issues post go live. It doesn’t matter, we’ll fix
the bugs in production.
 Manage the risk register – have mitigating
actions and owners & don’t bother following up
 No one remembers the business case
 Move date/cost if in trouble, several times
 Exert high energy and overtime for months
 Over-stretch boundaries of risk-based testing

(DELIBERATELY) SCREWED UP SCRUM BEHAVIOURS
WHICH BEHAVIOURS ARE NON-NEGOTIABLE?
ARE THERE MORE?
 Seek feedback, be willing to learn
 Credible, competitive, affordable plans
 Phone call / IM chat / f2f chat / white board
 Implement top-drawer, laser focused & urgent
dependency management
 Use focus factor / velocity with ideal day
estimates – remember there is no ideal day
 Try to understand – ask why?
 Negotiate ways of working for all concerned
 Collaborate actively every day
 Iterations begin and end on a regular rhythm,
beginning with good planning, ending with a
good look back
 Have IT PM and business PM (Product Owner)
 IT PM rules but business PM is still central to
proceedings
 Plan for working demonstration every iteration
& measure results
 Routine requirements / design look ahead with
all concerned
 Root out & unravel complexity
 Act & think like you trust the team
 Have a team focus, business & IT
 Team members work full time on project
 Baseline latest when, if at all?
 Use change control for change if everything has
already started
 Use prescribed ALM tool in the intended
manner
 Comply with controls
 Ask mentor for help
 Participate in formalised informal community

SCRUM + TECHNICAL EXCELLENCE –
WHICH BEHAVIOURS ARE NON-NEGOTIABLE?
ARE THERE MORE?
 Un-fix scope – everything cannot be must have
 Good enough is good enough
 Seek feedback, be willing to learn
 Phone call / IM chat / f2f chat / white board
 Implement top-drawer, laser focused & urgent
dependency & issue management
 Use focus factor / velocity with estimates
 Try to understand – ask why?
 Negotiate ways of working for all concerned
 Credible, competitive, affordable plans , even when
priorities change - be urgent about that
 Product Owner and team manages a list of all the
things to do, called a product backlog;
 Product Owner prioritizes value and Solution
Architect prioritises risk.
 Product Owner prioritizes 3 weeks ahead of sprint,
and does last minute tweaks before iteration
planning
 Sprints begin and end on a regular rhythm,
beginning with good planning, ending with
potentially shippable increment & lessons learnt
 Collaborate actively every day
 Product Owner (a business PM) rules
 Practise technical excellence, whichever school
you’re in (TDD dead/not dead, and there is always
agile testing)
 Perform routine requirements / design look ahead
with all concerned – requirements for next sprint
are INVESTable, with user roles discovered, and
NFRs elaborated
 Learn skills – Have a team focus, business & IT
 Root out & unravel complexity
 Be as professional as you can be with the work,
while being as nimble as possible
 Let’s make everyone feel like we’re on one team
 Act & think like to trust the team
 Team members work full time and don’t change
 Baseline latest when, if at all?
 Use product backlog item substitution to handle
change.
 Comply with company rules& legal regulations
 Don’t scale, but if you must, consult help
 Measure delivered business value
 Overtime for sprint commitment and no more
 Consider business readiness & IT readiness
 “Use your brain” , less scripting more testing
 If you must, breakdown tasks for this sprint only

LEAN KANBAN DEVELOPMENT –
WHICH BEHAVIOURS ARE NON-NEGOTIABLE?
ARE THERE MORE?
 Use a kanban system daily
 Visualise workflow hourly/by the minute
 Stop starting, start finishing
 Use T&M / PAYG contracts only until we have
good data for predictability (cycle time)
 Pull one item at a time
 Experiment with work in progress limits
 Respect work in progress limits, tune as
necessary
 Let’s help each other out
 Try to understand – ask why?
 Forecast based on cycle time + 2 standard
deviations
 Improve collaboratively
 Do “Iterationless development” once you get
into a rhythm
 Use expedite swim lane for exceptions & watch
out for abuse

LEAN START UP BEHAVIOURS
1 OF 2
 Validate ideas through 2-4 week build measure
learn cycles
 Have short ideation to focus on ideas
 Projections are full of uncertainty. Take a leap
of faith.
 Use “innovation accounting”.
 Experiment to innovate. MVPs often result in
bad news. Take risks. Tune MVP in next cycle if
persevering
 Have short execution periods to avoid
distracting ideas
 Deploy as often as possible, e.g., many times
per day
 Focus on absolute Minimum Viable Product
from one cycle
 Only build max 80% product until idea
validated – early adopters prefer this
 Don’t focus on quality until ideas get validated
– after all, what is quality if we don’t know the
customer yet?
 Customer interaction over white-boarding /
strategising
 Change direction or strategy if idea is
invalidated (pivot)
 Use a different brand to avoid long term
damage to corporate brand
 Drop invalidated ideas even if it means losing
customers who are using them
 Try to understand – ask why?

LEAN START UP BEHAVIOURS
2 OF 2
 Split testing to validate additional features or
improvements or reduced functionality; stop
guessing - understand cause and affect
 Opinions about priorities are guesses
 Use Actionable, accessible and auditable
metrics - use cohort based reports. 5 to 10
actionable metrics in standard report for all
experiments
 Monitor metrics and customer reactions during
experiment and abort if necessary
 Failure is a pre-requisite for learning
 Innovation accounting leads to quicker pivot
 Just in time scalability
 Beware of engine of growth Paid, viral or sticky
growth
 Pull the andon cord - stop the line
 Continuous deployment
 Pull, don't push
 Customers often don't know what they want,
hence figure out what we need to learn and
work backwards; formulate a hypothesis that
we want to test.
 Be accountable
 Practise the five whys (taking a systems view)
and avoid the curse of the five blames. To that
end, be tolerant of all 1st time mistakes and
don't allow them to happen twice.
 That said, Make a proportional investment
 Help each other out!
 Keep handoffs and approvals to absolute
minimum - it's a lean startup!
 Someone must have a personal stake in the
outcome - a shusa, or chief engineer who
decides everything. Create an island of
freedom, an innovation sandbox to support that
and protect the organization
 One team oversees whole experiment e2e
 No experiment can affect more than a specified
% of customers