Agility and the Cloud

I was recently sent an email by a colleague, Bryan O’Connor who is an expert in VMWare asking a question about the connection between Agile and the Cloud.

There wasn’t time to write a considered response so I decided to try and record an unscripted response on my phone.

This video is my MVP – Minimum Viable Product. (Transcript below).

I wanted to test a hypothesis. Would people be satisfied, happy even with a quick, unrehearsed video presentation with no post-production?

Recently, I recorded a series of heavily produced videos for QA Training Limited but wanted to see if I could get content out more quickly.

As I spend my weekends on the farm in my overalls, it needed to be “take me as you find me”.

I shared the recording with Bryan and some other colleagues who all thought the format worked well, and wasn’t too contrived, so I shall start recording more to add to my channel. All will be in the form of a response to a question.

I also wanted to test how easily I could create a transcript using the Microsoft Video Indexer. Quite easily, as it happens:

Here is the transcript:

Brian. I promised you a response to your question about Agile and the cloud or agility in the cloud.

Although come to think of it, you might have been talking about agility and virtualization.

But the two go together so we’ll go with it.

OK two 2 things: Agility and Cloud.

So the first thing to get your head around is: Agility is a mindset. It’s a way of approaching work. It’s a way for individuals, or more likely teams to work together to get stuff done.

You’ll hear about things like Scrum and Kanban. These are just frameworks or tools that teams can use.

The agility is things like doing things in an iterative way.  Repeating steps over and over again to improve. That’s one of the underlying principles. Continuous improvement.

They iterate. They do things incrementally. So rather than try and boil the ocean. Rather than trying to solve the problem in one go, and all the design up front, they break things down into small bite sized chunks.

They pick the most important thing first. Ideally, a small manageable task. They design it, they plan it, they get the thing built, they get thing tested to get the thing out ideally. If not ship, certainly into the hands of a stakeholder who can see it, touch it, give feedback.

And then we go off and build the next thing.

So the key traits of agility: no matter whether you look at frameworks like Scrum, and that just provides meetings and roles, for teams to help them get organised.

What you’ll see is seems breaking work into iterations or time boxes or if you use Scrum, sprints. And quite often, even if you don’t use Scrum, they still call it sprints.

And so that’s where Agility comes. Look for regular feedback with stakeholders and each other.

Look for continuous improvement.

Look for breaking things down into small bite size chunks.

So the segue into cloud or virtualisation is in of itself: Cloud is a technology. It’s an awesome technology. It’s not an inherently agile thing.

Where the two touch is that one of the challenges, particularly in software development, when it comes to: OK by the end of this fortnight, by the end of this month, we’re going to have something ready to go, is typically infrastructure.

Because the team is going to pull in a piece of work in this Sprint. We’re going to get “X” done. So, by the end of that Sprint or during that Sprint, We’re going to need a server of the following configuration. Or we’re going to need the following kit.

And traditionally requesting infrastructure from those who supply it could be months. Multiple meetings, PO requests and so on. And so that’s always been a roadblock.

So, we’ve, as agile teams rarely been able to build a thing and test it on a live like environment. Now where virtualisation and cloud, “either one will do nicely”, really help here are just as enablers.

In the early days of a project, we don’t know what the build of the machines are going to be. We don’t know how many machines were going to need we don’t know what the platform is going to be. We just don’t know.

So, a lot of what we do in Agile is experiment.

Using various virtualisation techniques or platforms, such as AWS or Azure, we can within a Sprint try out a couple of ideas. It might be windows. It might be Linux. It might be AWS. It may be Azure. It maybe this kind of build or that kind of build.

And we’re doing this paying £0.50 a £1.00 per minute. Or an hour excuse me, and throw it away at the end.

And we can learn what the infrastructure needs to be. Once we’re clear on what it needs to be, we can start communicating to those people who can actually roll this out and maintain in the future.

But all the way through development, even all the way through demonstrating it and review by the Stakeholders, we’re just doing it in virtualized containers. Doing it in the cloud.

It may well be that when we finished, it stays there. But if for whatever reason, the stakeholder wants to, then move it on-prem then, so be it but right the way through development were able to try things out in a variety of different configurations at low-cost very easily. And with no roadblocks to our development or speed bumps to our development.

One other aspect as well. Particularly from a development point of view is a technique that is encouraged with developers is configuration management.

When you write your code, get it into configuration management like GIT, Subversion, whatever it may be, BitBucket for instance, so that your getting the code off your machine.

You’re getting it into repository where it can be shared by others. And, as the project develops, we’re constantly moving the code into these repositories where they can be accessed.

So that’s a best practice.

Also. A term from AWS I remember, I’m not sure if there’s a similar term in Azure, is “infrastructure as code”. So one of the beauties of AWS is we could specify the build, specify the entire infrastructure. As a template.

So what I encouraged the developers to do there was rather than build your thing and then, plonk into some kind of infrastructure, be thinking about the infrastructure you want and take the pain.

Rather than use a funky console with big blue buttons and you can spin things up, learn how to script this stuff. Spin up infrastructure in code and that way the increment that you’re handing over at the end of the Sprint will be the code for the production, application itself. But also, for the infrastructure. So, it’s far easier to spin up and replace infrastructure as you go.

So hopefully that’s been OK. I just took a break from the gardening. If you have got any more questions just give me a shout.

Cheers Bryan.

I plan to experiment with importing my transcript into Camtasia so that I can provide captioned videos but that of course will require more post-production..

Let’s tackle one requirement at a time 😉