12/2/2014 Milwaukee Agile Presentation: Persuading Your Organization to be Agile was delivered to 54 practitioners. NVISIA's Tracey Barrett shared tips on how to persuade an organization to become Agile. Interestingly enough, Tracey suggests being Agile in your adoption of Agile.

1. Milwaukee
Agile
Presented by Tracey Barrett – December 2, 2014
Persuading your Organization to
Be Agile

2. 2
Milwaukee
Agile
Agenda
 How to Make a Persuasive Argument.
 Understand the Audience.
 Anticipate Objections.
 Articulate the Problem.
 Propose a Small Start. Be Agile.
Basics of conflict resolution, or in this case – avoidance.
Gain supporters and start collaborating.
Identify the top problems Agile will solve for you and your organization.
Know what you’re up against and prepare for it.
Know what you can do on your own. You have more power than you think.

3. 3
Milwaukee
Agile
But first, Introductions…
Clients engage NVISIA when:
 Building a sustainable competitive advantage through software innovation
is part of their business strategy
 Increasing IT effectiveness is critical to their business
 New solutions require a high degree of integration or interoperability across
multiple systems
Tracey Barrett is Executive Director of NVISIA, a Software
Development Partner that works closely with the client’s team to
deliver their solutions in their environment.

4. 4
Milwaukee
Agile
Basics of Conflict Resolution
The Rules
Avoid “You” Language.
Anticipate Objections.
Appeal to Self-Interest.
Watch for body language.
Be direct. Set limits.
State the consequences.

5. 5
Milwaukee
Agile
Making an Argument for Agile
Setting up the argument
I understand that [common objection…]
But I feel [a problem the person can relate to…]
I think we have to [change the way we work…]
What if we start by [propose a small start. Be agile.]
Otherwise, [restate the problem and how it doesn’t go away.]
I get that we already have a lot on our plate this year
But the team feels pressured to meet these commitments
And thinks the only way to do it is by using agile.
What if we assign a single developer day one to Project X?
Otherwise, [restate the problem and how it doesn’t go away.]Without changing, we won’t get any more done than last
year.

6. 6
Milwaukee
Agile
 To make the argument, you need to:
 Discover the objections
 Know who’s willing to help
 Understand the self-interest – problems or opportunities
people are facing and Agile may be able to solve.
 Start by talking to people one on one.
 Ask questions that allow people to disagree with you.
 Listen to their answers – this is a fact finding mission!
Know your Audience

7. 7
Milwaukee
Agile
Start the Underground
Conversation
 Example questions…
 “I’m really jazzed about Agile lately. Do you think it
would work here?”
 “Agile has worked really well for me at other jobs.
Has anyone tried to introduce it here?”
 “I feel like we’re behind the times. Why do you
think Agile hasn’t caught on here yet?”
 “How have your projects been going recently?
Lately, I feel like there just isn’t enough time to get
everything done.”

8. 8
Milwaukee
Agile
Collaborate!
 Identify the starting points you could accomplish together
 Identify the stakeholders! Do you need approval for the
small starts? From who?
 Your conversations should
identify others who are
interested in Agile.
 Discuss the objections and
opportunities

9. 9
Milwaukee
Agile
Propose a Small Start.
Be Agile.
 Ideas
 Trying agile on one project – yours.
 Holding standups with your team.
 Give the business bi-weekly demos.
 Install a continuous integration server.
 Some tricks of the trade…
 You can keep others informed of what you’re doing without asking
them for permission. If they want to stop you, they will.
 People don’t want to hear how you can help them. It’s much better
if they can help you by doing almost nothing.
 Highlight the ways you’re already agile – make the case for a next
step instead of a small start.
 Never leave the ball in their court.

10. Milwaukee
Agile
Approaching the Stakeholders
Common Concerns and Approaches for Various
Stakeholders

11. 11
Milwaukee
Agile
Business Users
Common Objections to Agile:
 Not Interested: They have their own IT
requests to accomplish, and aren’t
interested in how the work gets done.
 No Funding For Organizational Change:
Business projects have all the funding. An
“Agile Rollout” project never makes the
cut.
 No Time Available: Cannot dedicate a full-
time Product Owner to the project.
 No True Product Owner: You build highly
integrated applications with no single
owner.
Typical Problems
Their goals depend on IT – something
they have no control over.
Weeks and months of up-front
requirements gathering is painful.
Not sure about the UI they want – they’ll
know it when they see it.
The system they get usually isn’t what
they want.
They still have to do their full-time job
during a project.
Motivator: They want their project done – and done well.
IT decides when the system is done –
and forces it on them.

12. 12
Milwaukee
Agile
Business Users
Common Objections to Agile:
 Not Interested: They have their own IT
requests to accomplish, and aren’t
interested in how the work gets done.
 No Funding For Organizational Change:
Business projects have all the funding. An
“Agile Rollout” project never makes the
cut.
 No Time Available: Cannot dedicate a full-
time Product Owner to the project.
 No True Product Owner: You build highly
integrated applications with no single
owner.
Typical Problems
Their goals depend on IT – something
they have no control over.
Weeks and months of up-front
requirements gathering is painful.
Not sure about the UI they want – they’ll
know it when they see it.
The system they get usually isn’t what
they want.
They still have to do their full-time job
during a project.
Motivator: They want their project done – and done well.
IT decides when the system is done –
and forces it on them.
Awesome! Just to keep you
informed, we’re going to be using
Agile on your project.
I get it. We’ll use Agile on the project
that’s funded. It’s a more efficient
way to use that budget.
This is going to be a problem
regardless of methodology. Let’s go
with Agile and assign a BA to act as
proxy.

13. 13
Milwaukee
Agile
Common Objections to Agile:
 Business isn’t interested: Business has
its own IT requests to accomplish, and isn’t
interested in how the work gets done.
 We’re not structured for Agile: We have
a PMO, a BA group, Development, QA,
etc.
 Too much to do already: We can’t get
done everything we need to, why would we
add something else?
 You need a strong team to do agile: We
hire a lot of junior developers who need
guidance.
IT Leadership
Typical Problems
They are removed from the work – but
accountable for it.
Often required to prioritize business
requests – and constantly saying no.
Production problems throw everything
off schedule.
Their staff is vocal – they get a lot of
suggestions and complaints.
They feel extremely pressured to meet
commitments and deliver quality.
Motivator: They need to keep the business and their team happy.

14. 14
Milwaukee
Agile
Common Objections to Agile:
 Business isn’t interested: Business has
its own IT requests to accomplish, and isn’t
interested in how the work gets done.
 We’re not structured for Agile: We have
a PMO, a BA group, Development, QA,
etc.
 Too much to do already: We can’t get
done everything we need to, why would we
add something else?
 You need a strong team to do agile: We
hire a lot of junior developers who need
guidance.
Awesome! If they don’t care about
methodology, let’s use Agile!
IT Leadership
Typical Problems
They are removed from the work – but
accountable for it.
Often required to prioritize business
requests – and constantly saying no.
Production problems throw everything
off schedule.
Their staff is vocal – they get a lot of
suggestions and complaints.
They feel extremely pressured to meet
commitments and deliver quality.
Motivator: They need to keep the business and their team happy.
We don’t have to re-org the company
to get started. Let’s just work within
our project teams.
I agree! Agile will spread the work
out through the team, and Lean it out
so we only do what’s truly necessary.
This one ticks me off. Have some
faith in your people already….
True, we’ll have to balance the team
with a mix of seniors and juniors, but
we do that already.

15. 15
Milwaukee
Agile
Common Objections to Agile:
 Business wants to know how much a
project will cost: We need an estimate for
the project in order to approve its budget.
 Business wants to know if we’re on
schedule: If there’s no set end date, how
can we measure our progress?
 We can’t assign developers day one: #1
– they’re busy and #2 – we won’t have the
work.
Project Managers / PMO
Typical Problems
They run from meeting to meeting with
little time to do work.
They’re often not familiar with the
technology of their project.
They’re managing part-time resources
who are rarely productive.
Their team doesn’t inform them of issues
until they miss their date.
They feel extremely pressured to meet
commitments and deliver quality.
Motivator: They want to deliver on time and budget.

16. 16
Milwaukee
Agile
Common Objections to Agile:
 Business wants to know how much a
project will cost: We need an estimate for
the project in order to approve its budget.
 Business wants to know if we’re on
schedule: If there’s no set end date, how
can we measure our progress?
 We can’t assign developers day one: #1
– they’re busy and #2 – we won’t have the
work.
They’ll get demos every
two weeks and regular
updates on what will be
in by the deadline.
Project Managers / PMO
Typical Problems
They run from meeting to meeting with
little time to do work.
They’re often not familiar with the
technology of their project.
They’re managing part-time resources
who are rarely productive.
Their team doesn’t inform them of issues
until they miss their date.
They feel extremely pressured to meet
commitments and deliver quality.
Motivator: They want to deliver on time and budget.
Okay! I’ll give you a top-down
estimate to start the project, and I’ll
re-commit at 8 weeks.
There’s work for a small team.
What’s the advantage of starting
before they’re available?
With waterfall, scope is fixed
and deadline moves. With
Agile, you can fix the deadline
and adjust scope.

17. 17
Milwaukee
Agile
Business Analysts
Common Objections to Agile:
 Business needs me: They need help to
determine the requirements of the
software.
 Developers want detailed requirements:
I’m always getting asked for more detail,
and now we’re going to go without
requirements?
 Business Analyst isn’t a role in Scrum:
If we move to Agile, what will BA’s do?
Typical Problems
Up front requirements gathering is a
huge, painful task.
With modern systems, the UI is tactile –
and difficult to plan.
They receive lots of change requests
once the users finally see the system.
They get a lot of questions from IT – or
they don’t. Which is worse?
They make commitments the final
system doesn’t deliver on.
The business doesn’t usually care about
every little decision – but you have to.
Motivator: They want to deliver the best system for the business.

18. 18
Milwaukee
Agile
Business Analysts
Common Objections to Agile:
 Business needs me: They need help to
determine the requirements of the
software.
 Developers want detailed requirements:
I’m always getting asked for more detail,
and now we’re going to go without
requirements?
 Business Analyst isn’t a role in Scrum:
If we move to Agile, what will BA’s do?
Typical Problems
Up front requirements gathering is a
huge, painful task.
With modern systems, the UI is tactile –
and difficult to plan.
They receive lots of change requests
once the users finally see the system.
They get a lot of questions from IT – or
they don’t. Which is worse?
They make commitments the final
system doesn’t deliver on.
The business doesn’t usually care about
every little decision – but you have to.
Motivator: They want to deliver the best system for the business.
I agree! The Product Owner
deserves a team, too!
We’re not trying to tune the process
for developers. Getting business
decisions made is the hard part.
Developer isn’t a role in Scrum
either. If you’re assigned to the
Team, we’ll use your skills.

19. 19
Milwaukee
Agile
Architects
Common Objections to Agile:
 Agile is a free-for-all: There’s no
architectural consistency between agile
projects.
 Agile doesn’t have time for architecture:
If you build everything in snippets, you
never consider the big picture.
 You cannot build anything complex in
two weeks: Real architecture takes time to
build.
 I don’t want to write code: That’s not my
role anymore.
Typical Problems
People with the benefit of hindsight
second guess their decisions.
They may not be familiar with new
technology they need to design for.
Developers don’t follow through on the
architectural designs.
They feel disconnected from the top
problems the business is facing.
Motivator: They want to consistently deliver flexible, high-quality systems.
IT projects to introduce new architecture
don’t get funded.

20. 20
Milwaukee
Agile
Architects
Common Objections to Agile:
 Agile is a free-for-all: There’s no
architectural consistency between agile
projects.
 Agile doesn’t have time for architecture:
If you build everything in snippets, you
never consider the big picture.
 You cannot build anything complex in
two weeks: Real architecture takes time to
build.
 I don’t want to write code: That’s not my
role anymore.
Typical Problems
People with the benefit of hindsight
second guess their decisions.
They may not be familiar with new
technology they need to design for.
Developers don’t follow through on the
architectural designs.
They feel disconnected from the top
problems the business is facing.
Motivator: They want to consistently deliver flexible, high-quality systems.
IT projects to introduce new architecture
don’t get funded.
We can put controls in place and
assign an Architect onto the team.
We can make better
decisions and avoid analysis
paralysis if we focus on one
decision at a time.
We’ll be most effective if we set
short-term goals. If it doesn’t result
in a full feature, I’ll deal with it.
Work with your manager to find out
the role they want you to play. I’m
sure we can work it out.
Systems are too complex
to gather all requirements
and consider their design
in its entirety.

21. 21
Milwaukee
Agile
Developers
Common Objections to Agile:
 Stand-ups are micromanagement: I get
my work done. I don’t need you to check
on me everyday.
 I just want to write code: I shouldn’t have
to plan / gather requirements / design /
test, etc.
 Unit testing is a waste of time: I could
get my job done faster if I didn’t have to
write unit tests / do code reviews / etc.
Typical Problems
They are told what to do, but not why –
or how it fits into the overall project.
They’re constantly pulled off projects to
deal with production support issues.
Up front activities run long, but their
deadline doesn’t change.
There are issues in the code that they
are not given time to refactor / resolve.
They have to code to requirements, even
if they have a better idea.
Motivator: They can have more say in how the project is run.
The requirements have gaps, or don’t
match what other API’s need.

22. 22
Milwaukee
Agile
Developers
Common Objections to Agile:
 Stand-ups are micromanagement: I get
my work done. I don’t need you to check
on me everyday.
 I just want to write code: I shouldn’t have
to plan / gather requirements / design /
test, etc.
 Unit testing is a waste of time: I could
get my job done faster if I didn’t have to
write unit tests / do code reviews / etc.
Typical Problems
They are told what to do, but not why –
or how it fits into the overall project.
They’re constantly pulled off projects to
deal with production support issues.
Up front activities run long, but their
deadline doesn’t change.
There are issues in the code that they
are not given time to refactor / resolve.
They have to code to requirements, even
if they have a better idea.
Motivator: They can have more say in how the project is run.
The requirements have gaps, or don’t
match what other API’s need.
You’re right, I don’t need to check on
you. But it’s great mentoring for the
others to hear what you’re doing.
If we ask you to do that it’s because
coding’s not the bottleneck. We’re
applying effort where we need it.
It seems that way, but in a year when
you need to change that code,
having tests will make you faster.

23. 23
Milwaukee
Agile
Exercise
 Form Groups of 2
 You’ll each get a 5 minute turn.
 You will role play the part of the
person you need to convince.
 Anticipate the objections!
 Your partner will role play you.
Explain your situation to them so
they understand your argument.

24. Milwaukee
Agile
Questions or Comments?
Thank You