After watching this video, you will be able to:
Describe how Extreme Programming was the beginning of Agile and describe Agile
and how it became part of DevOps. In 1996, Kent Beck came along
with extreme programming. Kent based this on an iterative approach.
He described these feedback loops. Release plans takes months,
iteration plans take weeks, acceptance plans take days and stand-up
meetings are conducted every day. And pair negotiations are done every hour and unit
testing in minutes and programming in seconds. These tighter and tighter
loops represent the approach. The idea was to improve software
quality and get feedback quickly: get something out to the customer, get
feedback quickly, and then iterate on it. Extreme programming was intended
to improve software quality and responsiveness to changing customer requirements.
It emphasized concepts like pair programming. I encourage you to try pair programming. It
gets two sets of eyes on every line of code and helps cross-train your team with skills.
For example, a person who really knows Python will pair with one who is just learning Python.
They work together and the junior programmer gets to see how the senior
programmer approaches the problem. Pair programming is a great way of mixing the
skills in your team and getting everyone under the same code to understand it at the same time.
Kent Beck’s Extreme Programming was one of the first Agile methods.
In 2001, seventeen software developers met in a resort in Snowbird, Utah to
discuss these lightweight development methods. What they came up with is
called the Agile Manifesto. The Agile Manifesto emphasized
valuing individuals and interactions over process and tools; working software
over comprehensive documentation; customer collaboration over contract negotiation;
and responding to change over following a plan. That is to say, while there is value in the items
on the right, we value the items on the left more. It was a big breakthrough.
People began to change their organizations to be Agile.
In Agile development, requirements and solutions evolve through
a collaborative effort of self-organizing cross-functional teams and their customers.
It advocates adaptive planning, evolutionary development, and early
delivery, and continual improvement. It also encourages rapid and
flexible response to change. Work is done in increments called sprints.
Planning is adaptive. We plan for the next two weeks, and then the two weeks after
that, and then two weeks after that. Agile includes continuous improvement,
that is asking what you learned, and what you are going to do to change.
The Devs were latching onto it and I was on a couple of Agile teams back then and it
was really, really working out well. But being Agile doesn’t solve all the problems.
There is still Ops to consider and Agile was in direct opposition to the way
operations was being measured. I was on a project that illustrates this concept.
We started the project in January. Toward the end of February, we had
code we actually wanted to deploy. We went to the Ops team to deploy
it and they said open a ticket. So, we opened a ticket to get three VMs. And
couple days later we asked about the VMs. You know, it takes about 20 minutes to make VMs.
The Ops team said it takes two weeks to find a person who has the 20 minutes to make the VM.
The ticket sat and sat and sat and then it was kicked back.
The project was deployed in September, and I left the project in December.
I couldn't take it. It was crazy that the developers were being
Agile, working in sprints, working in sprints, and then waiting, waiting, waiting
for the Ops team to deploy something. Agile, alone, is not good enough.
Patrick Debois had the realization that we need to make Ops people Agile.
The result of this situation is called two-speed IT.
Here is how it works (or rather... doesn't work!) A developer needs some resources.
Ops tells him to submit a ticket. The developer says, “Never
mind. I'll go to the cloud.” And the developer goes to the cloud and gets the
resource immediately instead of waiting for days for his IT organization or service a ticket.
This is the slow speed of going through company resources and the fast speed of
getting resources outside the company. This is how “Shadow IT” gets started.
There are resources that the business doesn’t know about because people go around the
IT shop because IT is not meeting their needs. Then, the cloud makes this very easy to do and I
would bet that every organization has users with cloud accounts that no one in IT knows about.
We need a solution to this problem and DevOps has an answer.
In this video, you learned that: Extreme Programming paved
the way for Agile development Agile emphasizes valuing
individuals, collaboration, responding to change, adaptive planning,
early delivery, and continuous improvement