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