Agile 101

DevOps is built on top of the foundation of Agile. That sentence makes perfect sense to me, but I was recently reminded (Hey Steven! What the heck?) that not everyone has worked as a developer and knows Agile from a hole in the ground. So, here is my 20,000-foot overview of Agile.

First, there are many ways to build programs, but I’m not going to bore you with them. Suffice it to say traditionally programs are built using what’s called the Waterfall method. In Waterfall your ream goes through several, distinct steps: Analysis, design, specification, coding, and testing.

It has several problems. First, as anyone who’s ever even been close to a Waterfall project knows, 80% of the work happens in the last 20% of the project. What that means in practice is coders work 18-hour days, testing is done at a breakneck pace, and quality assurance? What’s quality assurance?

Second, let’s say the programmers are deep in the code when the customer or management says, “It has to have this new feature with sprinkles on top!” No, that never happens right!? With Waterfall, climbing back up to add a new design or specification is incredibly painful.

Back in 2001, some developers got sick and tired of this and created the Agile Manifesto. In it, they came up with four guiding principles:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Here’s how this works. Programming teams include users and management from the get-go. This is done by putting everyone involved in a project into small groups, which meet daily. One of the most popular mechanisms for doing this is called Scrum, but there are other methodologies such as Extreme Programming (XP).

The programming team determines what the project will accomplish. This is not like Waterfall, though, with its grand programming plans that Must Be Followed to the bitter end. Instead, in Agile, it’s presumed a project will evolve over time.

That doesn’t mean, however, that the project has an open-ended time frame. It won’t. You still need to accomplish the overall goal. But, you’ll get there by making small, frequent updates to the project instead of focusing on management-set performance milestones.

Along the way, features are finished before moving on to the next one. In short, in Agile you break projects into small, easy-to-complete pieces.

Once done, those pieces must work. If they won’t run until the entire project’s done, you’re doing it wrong.

At the same time, testing is done every step of the way. You don’t check all the code at the end. You make sure each piece works as it comes out.

During this process you also do your best to practice Pareto’s law, aka the 80/20 rule. In other words, 80% of your results are going to come from 20% of your efforts. The trick, of course, is figuring out which 20%. With Agile, you try to work this out as you go. That’s one reason those daily meetings are so important. You want to make sure some on your team aren’t going down rabbit holes of false productivity.

There are endless debates on how well Agile does, or doesn’t, work. For now suffice it to say the Agile methodology works extremely well on the cloud and in DevOps, but I’ll take Agile in the cloud up in my next story.

 

Trackbacks

  1. […] best way to do this is with an Agile application development approach of trying, learning, and then modifying business decisions on the […]

    Like

  2. […] best way to do this is with an Agile application development approach of trying, learning, and then modifying business decisions on the […]

    Like

  3. […] very best means to do that is with an Agile software building manner of making an attempt, finding out, after which enhancing trade choices at […]

    Like

  4. […] best way to do this is with an Agile application development approach of trying, learning, and then modifying business decisions on the […]

    Like

  5. […] best way to do this is with an Agile application development approach of trying, learning, and then modifying business decisions on the […]

    Like

Leave a Reply to ​Red Hat’s only business plan is to keep changing plans Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: