Many companies adopt Agile because it is the natural thing to do. But do they know what they are getting into? In this talk we will use some anecdotes and lessons learned from Agile adoption to build a model that will hopefully help our companies adopt Agile in a way that affects positively their business. Questions we try to address will include: How does Agile affect functions outside development? How to bring the benefits of Agile to non-development functions? What can Agile affect my bottom line?

1. I'll start right away with the lessons learned. Are you ready: you can start taking
notes, because this stuff is precious. This is a talk about the real process of
adoption Agile, failing, then trying again. The stories in this presentation are
collections from several companies where I've worked at and that I've interacted
with. At the end you will have the solution for all of your problems, don't worry!
:)
1

2. 2

3. 3

4. 4

5. 5

6. 6

7. The facts are
• most companies have or are considering adopting Agile (typically in their R&D)
• Agile delivers more visibility (83% of the case), faster time to market (37% shorter
time-to-market), responsiveness to change (90%)
The evidence is clear. Agile is being widely adopted, and now the question for you who
work in software organizations is: do you want to be left behind? Or do you want to
consciously start exploring Agile as a strategic execution focus for your organizations?
Excellence in execution can be a strategic advantage (fast release cycles).
7

8. Most of you will want to or have already started adopting Agile (statistics tell us this
much)
But how do I make it work for my business.
Sure R&D may benefit from it, but will it, in the end benefit my business? This is the real
question that we must examine. What are the issues? How do I make it work for R&D
first, but then for the rest of the organization?
8

9. This question is even more relevant if you consider the odds…
The hidden truth is that, unless you focus on improving your whole product
development process it is unlikely that you will be able to benefit your business.
This is what Ken Schwaber one of the early developers of the Scrum process said… It’s
important to understand the context of this comment. Ken said the same to me in 2004
when visiting the company where I was working, most companies run behind Agile, but
never really take agile adoption to the level that benefits their whole business.
This is the problem we have to face, our challenge if you will.
9

10. So, we have really two challenges when adopting Agile.
First, how do I adopt Agile?
-What does it mean for R&D
-How do I make R&D faster, achieve better time-to-market, etc.
But, second: how to I make it benefit my business?
- R&D is only part of the company. And surely any change in R&D will affect other
functions. Will it be a positive impact? How do I care for and ensure that a change in
R&D is positive for my business overall?
10

11. These are the questions we are tackling today. We need to figure out a way that helps us
get Agile to the business level, to the point at which it improves our whole business.
We need some “rails” on which to put our Agile adoption train.
It would be nice to have this model, a model that would help us adopt Agile and benefit
my business. Let’s try to build one together, shall we?
11

12. Let’s review some lessons learned and what steps we may be able to follow to achieve
our goal
This presentation is based on experiences from several adoption processes, it is
necessarily limited but tries to establish a platform on which we can build on. That can
help you adopt Agile throughout your whole business.
12

13. So let’s start with an obvious step.
Like in the past, adopting Agile in an organization will benefit from Pilot projects. These
relatively “safe” experiments will serve several purposes
1- Introduce the method in a way that does not risk your business
2- provide a learning opportunity for your people
3- increase your knowledge of what are the likely consequences of Agile adoption in
your environment
This is an appropriate step for any big change, but quite critical with Agile adoption
because Agile will have consequences you don’t expect (and that is ok). This is a key
learning opportunity!
13

14. As you complete your Pilot Projects you will have your own set of lessons learned.
- How does your organization react to Agile adoption?
- Where are the tensions showing up?
- What roles feel threatened ?
- What functions take up the change, what functions resist or even rebel?
These are just some of the questions that you will answer during this process and that
will help you fine tune your approach.
14

15. But keep in mind that Pilot projects, even if successful are just a small sample of what
the adoption process will be. Understand that Pilot projects are more likely to succeed
because they are “safer” experiments.
An example of how Pilot projects are “safer” is that they are typically free from political
games in the organization as they are “small”.
Pilot projects are needed, but don’t represent the whole organization.
15

16. Taking Agile to the rest of R&D is different than running a couple of Pilot Projects.
The tensions are different in higher risk/higher stakes projects.
You will have to consider:
-how to use Agile in larger projects (potentially),
-how to use Agile in different contexts (fixed price? Fixed scope? Within customers that
don’t do Agile?)
-How will other functions in the company react to Agile projects, which put different
demands on the organization?
These are considerations you will go through when adopting Agile across R&D. That’s
the next step. Breaking out from the pilot projects and tackling R&D-wide adoption.
But before we go there let’s review some of the ideas we’ve covered so far…
16

17. We have completed the first step towards our treasure island. Our Cheat sheet of Agile
adoption if you will.
Use pilot projects to learn and prepare a wider adoption, but don’t forget that pilot
projects succeed because they are isolated.
17

18. This brings us to step 2.
After the pilot projects we are forced to think about and consider the impact on the
whole R&D.
-R&D is diverse within itself.
-What happens when you have Agile and non-agile projects at the same time?
-How to ensure we make the right products, not just products faster?
Let’s dive into these questions as we consider the impact in the whole R&D
18

19. A problem you will face is how to synchronize multiple projects ongoing in your
organization.
In Agile we follow some pretty concrete rules about software development, one of them
is Continuous integration and continuous deployment (even if not to the end-customer).
Think about this case:
-R&D teams will depend on each other (for many reasons)
-One team asks another for something in the next Sprint, but the other team does not
have a similar clock cycle and tells your team: come back in three weeks when we do
our next planning process.
This leads to Agile teams not being able to deliver or even worse, delivering half-done
functionality that breaks everything else until the next team’s work is finalized.
If you have to coordinate multiple product release cycles where several teams interact
and cooperate then you must synchronize the different clock cycles in your organization.
But there are other things that require coordination…
19

20. As teams start synchronizing their work more often, the differences in their goals
become evident at first and conflicting very soon after that.
Cooperating that happens at the fast rate we expect it to happen in an Agile context
requires that the team’s goals are aligned.
20

21. This is one of my favorite issues. In the early days of Agile adoption I used to get the question quite often: “but we
need to cooperate with this other project that is using waterfall, how can we do it?”.
Well the answer is simple, but here’s the illustration of what I mean. Let’s take a common problem that you will face,
which will be R&D teams using Agile that need to cooperate with IT for product development/deployment. IT is often
slow in the adoption of Agile…
Not all teams in the organization work in Agile mode. Let’s imagine, for the sake of argument that R&D
has their house in order (yeah, right!) and are following the right process in the right way (sure, sure). But
how about other functions.
Let's take a simple case: how about IT? Well.... Surely the poor R&D management are not supposed to fix
*ALL OF THE* problems in the company right? Just kick IT! Get it into their score cards so that they suffer
from not doing what we ask them. You are laughing, but this shit really happens and when it does it is
mostly sad :(
Going back to the point. If I'm an Agile team, who's in control of the situation and need to plan something
for the next sprint, I run down to IT and ask them: could you please come to our Sprint Planning. It's
tomorrow at 9:00 sharp and it lasts 4 hours. We will need your commitment in a couple of things. The IT
manager opens their eyes widely and says: What... things? what things? and commitment? what?
Tomorrow? but that's the deadline for our TPS reports, you can't certainly expect that we will be there in
such short notice! Let me spell this problem in terms anyone can understand: "CULTURE SHOCK"! Scott
Adams get's a field day out of Agile adoptions alone!
So, to sum it up. An agile team goes to IT and says we need this server installed by next Sprint (in 2 weeks)
and we need to have this continuous delivery system implemented (requires only a couple of hours from
1 or two engineers) and then we need this monitoring system set-up in 4 weeks so that we can start
serving our pilot customers. The Agile Team is glowing, they know their lines and hit their marks, they
know what they are expected to deliver and they just need a tiny-small contribution from IT. Right?
Wrong!
IT will come back and say: what do you think we have here? A slave shop with people laying around
without anything to do? No Sir-e! We run a very tight ship here and we were asked last month to reduce
costs so we are giving back some VMware server blades to the hosting provider and we had to fire Jimmy
who was in charge of the monitoring system. Sorry old chap, we have a lot to do. If you need something,
talk with Helen over there who's the (single) project manager for IT projects and get your work scheduled.
With any luck we will get to it before Xmas. Well... you know where this is going, right? Agile in R&D is
21

22. useless if IT has to plan with 6 months in advance and cannot commit to anything
incrementally.
So the message is clear. Starting in R&D: drop waterfall now! Move all projects to
use Timeboxes. Timeboxed sprints, Timeboxed synchronization cycles for the
whole R&D and Timeboxed projects!
21

23. This leads us nicely to this step.
This step is about creating an R&D wide synchronization mechanism. By which all
projects and all teams can synchronize their work. They know what they need to do and
when they need to do it.
They come together regularly to review their work and plan the next iteration. For the
whole R&D.
22

24. We’ve talked about R&D projects so far. But there’s one role that is critical for any Agile
adoption to succeed. That role is the Product Owner (aka Product Manager).
The hidden truth is that Agile does not work without a good Product Owner/Product Manager
and team relationship.
The garbage-in, garbage-out problem.
The change from give requirements, came later to ask about delays. Change to: engage regularly
with the teams. Follow-up on what they need from you. Your job is very critical for the team.
This leads to confusion:
Another common problem is that Product Owners will be utterly confused by the
change in behavior by the teams.
See, they used to be called Product Managers, spent most of their time in trade shows,
talking to customers, meeting with sales, writing PPT's about their products etc.
Now, if you are using Scrum the role of the Product Manager is completely changed.
Now we expect them to work with the team regularly. In fact, in the companies where
I've worked the Product Owner is expected to interact with the team every day or at
least several times a week.
Being a PO is a full time job and is very much focused on the team. This is difficult to
implement in a legacy business. The link between customer and R&D has always been
very weak or non-existent. After all, R&D teams used to get their requirements through
a requirements document, *NOT* by talking to the people who knew what the
customers needed.
23

25. If you follow this train of thought, it is clear that you need to reconsider the boundaries
of your R&D organization… how far does it expand?
-Should product owners be in R&D?
-Should deployment be in R&D?
There’s no single answer to these questions, you need to understand what you are trying
to do, what are you trying to optimize…
24

26. And, while we are the process of changing our R&D we will bump into obstacles that
come from other organizations. When you bump into those obstacles (and you will) you
will have to go back to basics. Analyze your goals, analyze the other function goals and
align those!
Agile cooperation will inevitably need cooperation from other functions. Do you have a
cross-company goal for Agile adoption? Well, do you?
25

27. One step to create alignment that you will need to do relatively soon will be to include
product management in R&D. After all it makes sense, right? We develop products, not
separate pieces of software, right?
How many of you see yourselves developing software?
How many of you see yourselves developing products?
26

28. Why this step becomes quite important is that R&D can improve quality, they can
improve speed of execution, but they can’t improve the products without cooperating
with other parts of the company, specifically Product Management.
27

29. Lesson Learnt 9: Portfolio decision making is very slow, convoluted and not stable
enough
This leads us to Lesson Learnt number 9: The product decisions are very slow. This is
illustrated by this picture here. Where our Product Owner really thinks that they are in
charge. We, the turtles, just hide and we actually like that the big cats take the
responsibility for the product decisions. We say “they know what they are doing”… And
in the meanwhile we get crappy, incomplete, inconsistent and frankly appalling
decisions. But most importantly the product decisions are not aligned with your agile
cycles.
You will start an iteration and in the middle the portfolio process leads to a decision that
breaks everything you’ve done, sure we want change… but c’mon. I need to know
something before I can plan anything.
Ask yourselves, can you trust your product portfolio process to deliver good quality
decisions at timelines that are aligned with the cycles you have in R&D?
28

30. It is obvious from this discussion that we can’t really improve our business if we just
concentrate in R&D. And that is really the next challenge.
R&D alone cannot improve your business. You need to look beyond R&D…
29

31. So, the million euro question. How do I make Agile work for my Business?
30

32. So, what have we covered. In step 2 we should consider the impact on the whole R&D,
and understand the value/importance of Product Management for your R&D
31

33. Step 3 calls on us to embrace the whole organization. It is no longer about our little R&D
corner, it is about the whole system. From idea to product.
We need to optimize the whole system.
32

34. This takes us to the next big challenge.
Whether we like it or not Sales likes waterfall: long-term, non-negotiable roadmaps. The
problem is that R&D cannot work with those. R&D is a complex process in a complex
context, this requires that we use adaptive processes (Scrum, XP, Lean, etc.) Agile! R&D
cannot work with long-term, non-negotiable roadmaps!
33

35. But let’s not be idealistic here.
Many teams adopting Agile will want to iterate fast, but forget that they need guidance
(product and other), they need support.
You can let a team loose, but where are they going?
How many of you have been in a team that was working great, but producing nothing?
34

36. We need to a build framework that guides us, that focuses us, that delivers the guidance
we need.
A Vision is one way to achieve this. A vision is a long term guidance, but that is very
much negotiable. A Vision is a way to take the advantages of the user story model to the
portfolio level.
We agree on the Vision, but the team with the Product Owner then will have to adapt
that Vision to the real world.
35

37. Another side-effect of having a high-level guidance in the form of a Vision is that teams
take ownership of their part of the design process.
We’ve seen teams where people take a more pro-active approach to the design process
and start thinking about value, and how to deliver value rather than just concentrating
on the detailed work steps that they need to follow.
36

38. But Vision are just steps in the pursuit of your company strategy. You must link your
Vision to your company’s strategy.
37

39. As you deliver Vision-aligned projects you will start to see pressure, tension points in the
whole organization. Be ready for this, this is not bad, this is part of the process
38

40. When you see these problems search for alignment across your business. Define your
cross-company goals for agile adoption, work on enabling cooperation. We should all be
trying to achieve the same goal, right?
39

41. Finally, Agile adoption is not a short term process. Your competitiors are not sleeping.
You have to keep improving.
Agile and the methods we regularly talk about are really a framework for improvement.
You start with Scrum, and then you move to Lean. Or you start with XP and then you
move to Kanban. Whatever the evolution is, the important thing is to understand that
we cannot predict the future.
Transform your Agile adoption process into a continuous improvement process
40

42. Recapping: We need to deliver value by considering the whole system, optimize the
system, not R&D.
41

43. The key issue is this: We need a model. A model that can get us started, that drafts the
roadmap for agile adoption.
We need to adapt it as we go along, but we should have a clear Vision in mind. It is
overall business improvement that we are aiming for.
42

44. Let’s create a business-oriented, a holistik approach to Agile adoption that can help us
avoid the doom we seem to be destined to (at least according to Schwaber).
43

45. Finally, I’d like to leave you with a tip that can potentially save you millions and millions
of euros.
Hire someone with experience in this process!
44

46. So, in summary here is the model.
3 steps, surrounded by a big bunch of lessons learned from our experience over several
years of agile adoption in 2 large Finnish companies.
45

47. I’d like to invite you to continue this conversation on Twitter and on your own blogs. We,
as a community, need to develop our knowledge and blogs and twitter are great tools to
create connections and build a conversation that can develop our industry
46