1
00:00:07,920 --> 00:00:12,000
After watching this video, you will be able to:
Describe how Extreme Programming was the

2
00:00:12,000 --> 00:00:16,320
beginning of Agile and describe Agile
and how it became part of DevOps.

3
00:00:17,520 --> 00:00:22,080
In 1996, Kent Beck came along
with extreme programming.

4
00:00:22,080 --> 00:00:26,880
Kent based this on an iterative approach.
He described these feedback loops.

5
00:00:26,880 --> 00:00:29,600
Release plans takes months,
iteration plans take weeks,

6
00:00:29,600 --> 00:00:33,520
acceptance plans take days and stand-up
meetings are conducted every day.

7
00:00:33,520 --> 00:00:39,760
And pair negotiations are done every hour and unit
testing in minutes and programming in seconds.

8
00:00:39,760 --> 00:00:42,960
These tighter and tighter
loops represent the approach.

9
00:00:42,960 --> 00:00:46,560
The idea was to improve software
quality and get feedback quickly:

10
00:00:46,560 --> 00:00:50,880
get something out to the customer, get
feedback quickly, and then iterate on it.

11
00:00:50,880 --> 00:00:53,840
Extreme programming was intended
to improve software quality and

12
00:00:53,840 --> 00:00:59,760
responsiveness to changing customer requirements.
It emphasized concepts like pair programming.

13
00:00:59,760 --> 00:01:05,360
I encourage you to try pair programming. It
gets two sets of eyes on every line of code

14
00:01:05,360 --> 00:01:10,720
and helps cross-train your team with skills.
For example, a person who really knows Python

15
00:01:10,720 --> 00:01:15,280
will pair with one who is just learning Python.
They work together and the junior programmer

16
00:01:15,280 --> 00:01:18,400
gets to see how the senior
programmer approaches the problem.

17
00:01:18,400 --> 00:01:23,600
Pair programming is a great way of mixing the
skills in your team and getting everyone under

18
00:01:23,600 --> 00:01:29,520
the same code to understand it at the same time.
Kent Beck’s Extreme Programming was one

19
00:01:29,520 --> 00:01:35,200
of the first Agile methods.
In 2001, seventeen software

20
00:01:35,200 --> 00:01:40,880
developers met in a resort in Snowbird, Utah to
discuss these lightweight development methods.

21
00:01:40,880 --> 00:01:43,680
What they came up with is
called the Agile Manifesto.

22
00:01:44,480 --> 00:01:49,280
The Agile Manifesto emphasized
valuing individuals and interactions

23
00:01:49,280 --> 00:01:53,840
over process and tools; working software
over comprehensive documentation;

24
00:01:54,560 --> 00:02:00,640
customer collaboration over contract negotiation;
and responding to change over following a plan.

25
00:02:01,280 --> 00:02:06,560
That is to say, while there is value in the items
on the right, we value the items on the left more.

26
00:02:06,560 --> 00:02:09,920
It was a big breakthrough.
People began to change their

27
00:02:09,920 --> 00:02:14,480
organizations to be Agile.
In Agile development,

28
00:02:14,480 --> 00:02:19,680
requirements and solutions evolve through
a collaborative effort of self-organizing

29
00:02:19,680 --> 00:02:24,080
cross-functional teams and their customers.
It advocates adaptive planning,

30
00:02:24,640 --> 00:02:30,160
evolutionary development, and early
delivery, and continual improvement.

31
00:02:30,160 --> 00:02:33,600
It also encourages rapid and
flexible response to change.

32
00:02:34,240 --> 00:02:38,640
Work is done in increments called sprints.
Planning is adaptive. We plan for the next

33
00:02:38,640 --> 00:02:42,160
two weeks, and then the two weeks after
that, and then two weeks after that.

34
00:02:42,800 --> 00:02:46,880
Agile includes continuous improvement,
that is asking what you learned,

35
00:02:46,880 --> 00:02:51,840
and what you are going to do to change.
The Devs were latching onto it and I was on a

36
00:02:51,840 --> 00:02:55,920
couple of Agile teams back then and it
was really, really working out well.

37
00:02:56,880 --> 00:03:03,840
But being Agile doesn’t solve all the problems.
There is still Ops to consider and Agile was

38
00:03:03,840 --> 00:03:07,360
in direct opposition to the way
operations was being measured.

39
00:03:08,160 --> 00:03:13,120
I was on a project that illustrates this concept.
We started the project in January.

40
00:03:13,120 --> 00:03:16,480
Toward the end of February, we had
code we actually wanted to deploy.

41
00:03:17,040 --> 00:03:20,880
We went to the Ops team to deploy
it and they said open a ticket.

42
00:03:20,880 --> 00:03:26,400
So, we opened a ticket to get three VMs. And
couple days later we asked about the VMs.

43
00:03:26,960 --> 00:03:31,520
You know, it takes about 20 minutes to make VMs.
The Ops team said it takes two weeks to find a

44
00:03:31,520 --> 00:03:36,320
person who has the 20 minutes to make the VM.
The ticket sat and sat

45
00:03:36,320 --> 00:03:40,960
and sat and then it was kicked back.
The project was deployed in September,

46
00:03:40,960 --> 00:03:43,840
and I left the project in December.
I couldn't take it.

47
00:03:43,840 --> 00:03:48,320
It was crazy that the developers were being
Agile, working in sprints, working in sprints,

48
00:03:48,320 --> 00:03:51,920
and then waiting, waiting, waiting
for the Ops team to deploy something.

49
00:03:52,640 --> 00:03:57,600
Agile, alone, is not good enough.
Patrick Debois had the realization that

50
00:03:57,600 --> 00:04:03,120
we need to make Ops people Agile.
The result of this situation

51
00:04:03,120 --> 00:04:07,520
is called two-speed IT.
Here is how it works (or rather... doesn't work!)

52
00:04:08,080 --> 00:04:12,960
A developer needs some resources.
Ops tells him to submit a ticket.

53
00:04:12,960 --> 00:04:16,560
The developer says, “Never
mind. I'll go to the cloud.”

54
00:04:16,560 --> 00:04:20,960
And the developer goes to the cloud and gets the
resource immediately instead of waiting for days

55
00:04:20,960 --> 00:04:26,560
for his IT organization or service a ticket.
This is the slow speed of going through

56
00:04:26,560 --> 00:04:30,640
company resources and the fast speed of
getting resources outside the company.

57
00:04:31,840 --> 00:04:35,840
This is how “Shadow IT” gets started.
There are resources that the business

58
00:04:35,840 --> 00:04:42,320
doesn’t know about because people go around the
IT shop because IT is not meeting their needs.

59
00:04:42,320 --> 00:04:47,840
Then, the cloud makes this very easy to do and I
would bet that every organization has users with

60
00:04:47,840 --> 00:04:52,640
cloud accounts that no one in IT knows about.
We need a solution to this problem

61
00:04:52,640 --> 00:04:57,680
and DevOps has an answer.
In this video, you learned that:

62
00:04:57,680 --> 00:05:00,480
Extreme Programming paved
the way for Agile development

63
00:05:01,200 --> 00:05:04,640
Agile emphasizes valuing
individuals, collaboration,

64
00:05:04,640 --> 00:05:09,840
responding to change, adaptive planning,
early delivery, and continuous improvement