Your agile isn’t my agile old man

Seems everybody and their dog are “doing agile” and they all seem to be complaining about how agile isn’t helping them, in fact for a lot of them it seems to be hindering them.

I’ve wondered about this for a while and it wasn’t until reading Dan North’s recent post “How to train your agile” that it struck me.

I’ve been writing software for just under 20 years and when I started the way projects were managed were completely different from how a lot of people manage them now…

When I was young it was all fields around here

At the end of the 90’s delivery of software was frequently measured in years, projects often cancelled before completion and of those projects that were delivered they frequently had stability issues requiring lots of rework.

This way of working was fundamentally broken and so people set out to find a better way to work.

When they started using agile, delivering in months not years and focusing on ensuring the software worked you can see how radical the change was and this lead to a real change in how software was delivered, it gave businesses:

• Faster development
• Better quality software
• Working software delivered to production

All the things you still hear today associated with agile, what organisation wouldn’t want all of those things compared to what they had?

Whatever grandpa, that’s not how we do it nowadays

The expectation today is working software delivered in weeks not months or years,  an “agile” process isn’t really adding anything here, it’s the norm, it certainly isn’t going to make it any faster, even though people might keep saying it will.

Unfortunately not all environments are  the same and in some “agile” is a dirty word synonymous with pointless meetings and having to work in a hamster wheel of sprints which never deliver what they were supposed to, where each sprint can become a
mini-death march.

Where people are working in this way they don’t see any benefits, all they see is a broken process that they’re forced to follow because the management believe it will mean faster development, better quality, etc.  If all you’ve known is this type of environment then you would most likely think agile should die in a fire and for a lot of devs that have joined our community in the last 6-8 years this is their only experience of agile.

At the other end of the scale there are people working in an environment that makes original agile look antiquated, continuous deployment multiple times a day, focused on adding value for the business, trunk based development with feature toggling, etc. These types of environment frequently, but not always, have a DevOps culture looking beyond development to see how the organisation as a whole effects what they do, and the organisation looks for ways to improve, systems thinking.

Where does this leave us?

When you take a look back at the environment that spawned agile its easy to see where the claims around faster, better quality, etc came from, at the time it was a completely different way to work.  To be fair if you are still delivering multi-month/year projects using waterfall then those original claims are still likely to be true today.

For anybody in environments that look backwards to most agile practices – well done! keep up the good work! Only thing I will say is stay vigilant as it can be all too easy to slip back into bad practices.

If you are working in an “agile” environment, that is anything but agile, you may be able to change what you are doing by using the retrospectives to start conversations around the areas you believe aren’t helping and look at what you can do to change the situation, focusing on the principles rather than the practices (outcome not output, working software, etc) to attempt to improve your situation.

There is almost always ways to improve how you are working and that should be baked into any process you follow, what is frequently missing is the will to change or even try to change.

I firmly believe agile can help you but it does require you to participate so make sure you join in and look for ways to improve how you work, regardless of its “agile” or not.

Location of VM when using VMWare & Docker on windows

In my previous post I covered how to get Docker working on windows using VMWare workstation rather than VirtualBox.

One problem I ran into is that by default Docker will create the VM for the host OS in the users directory which usually resides on the C drive.

I try not to have my VM’s on C as I tend to keep that for my main OS and so I wanted to find a way to move where the VM was created.

First method I found for doing this involved me manually moving the vmdk by opening the VM in workstation after it was running, stopping Docker, moving the vmdk and editing the VM details in workstation to set it to the new location.  Whilst this worked it is a complete pain and so I dropped that approach and looked for alternatives.

I then found the create option--storage-path which allows you to specify where the VM should be created, this worked but again I didn’t want to have to specify the location every time, good for flexibility but if I forgot to use it then the VM would end up being created on the C drive.

Then I found there is an environment variable that Docker looks for named MACHINE_STORAGE_PATH which will be used as the root folder when Docker creates the VM it will use as the Host OS.

So on my machine I set it to F:\Docker and then Docker created all the necessary folders (cache, certs, machines) under this folder and the individual VM’s are created in machines folder.

Remember you will need to restart your command/console window once you set the environment variable or it won’t take affect.

Docker using VMWare workstation on windows

I’ve wanted to explore Docker for a while now being on windows meant I’d need to use VirtualBox which I didn’t want to do since I already have VMWare Workstation installed.

After a bit of a google I found that there was a driver to use VMWare with docker but no posts describing how to use it.  With a bit of trial and error I got it working and thought I’d share how to do it here.

How to..

Before you start you need to be on Windows 7 or above and have VMWare workstation already installed.

First install Docker machine for windows (you can get it from here), this will install all the normal programs needed to run docker.

Next you want to get the VMWare workstation driver from here, its an exe but you don’t run it you just need to copy the driver into the folder where you installed Docker Machine (usually C:\Program Files\Docker Toolbox).

At this point you’ll be able to run a create command which will build a Docker instance but you won’t be able to talk to the container.  The reason for this is the network adapters that VirtualBox installs will stop Docker talking to the VMWare virtual machine.

To be happy that its all working you can simply disable the network adapters and then any container you create should work.  At this point you can either leave as is or uninstall VirtualBox.

One side effect of this is that you won’t be able to use Kitematic since it only works with VirtualBox on windows.

Is this useful?

Even as I write this post I know that the Docker for Windows beta is coming out but that only uses Hyper-V at the moment.  Docker have said that you’ll still be able to use Docker Machine after Docker for Windows arrives and if you want to use VMWare that this may still be the best option for you.

CodeProject