Wednesday 22 February 2017

Development : Scrum & Leveraging Virtualisation (My Hobby Team)

Recently in one of the Scrum teams I oversee as their Scrum Master, I saw a common problem, one or two members of the team were being blocked by mundane issues once or twice a week.  For one member of the team this was a physical PC fault, for the other it was disk-space.

They are running their own equipment, outside the remit of my authority or the company control, therefore I had to clear the decks in some manner, the solution?

Well, the development was all Linux, I created a standard Ubuntu image and issued it to all concerned and asked that these be the ONLY virtual machines run to complete work.

The first week of this resulted in a slow time, I found people were not using; as per the original specification; virtual machines at all, I found they had a mish-mash of development materials, and importantly nearly every person asked me to allow them rights to install software.

I didn't allow this, instead I used the Scrum management software I've put together and collected all their ideas about editors, tools and software to add to the image, and we had an additional 10 minute open discussion going around the group to assess the merits of each piece of software, what it would be used for and how it might leverage either an easier time to task completion route or how it might introduce potential benefits in other ways.

I started with the proposer of the software, then alternated between those in the group whom had indicated they liked the software option and those that had not, in cased where no-one objected to a piece of software, I simply took the concensus benefits and added them as points below each item listed.

In the end we had reduced the pile of suggestions to three, the first a lightweight text editor, many were split between "just using nano, pico or vi" and those "desparate to use sublime".  This came down to a simple choice, one was free, one was not, we have a sub-zero budget since having to source those drive caddys last month... Everyone was going to use my preference "nano".

The second was a performance measuring tool option, to monitor the system, I opted to leave this decision to the testers in the group they have yet to advocate a choice, but I decided to take the option out of the scrum teams scope of interest, their code has to be fast and that's the end of that discussion.

The third was an art package, there were many options, one person wanted to do all their art in Paint.NET on a windows machine then move it into the main project, another wanted to create assets with GIMP and another wanted to use Photoshop. on his Mac, an easy decision GIMP.  It's native to Linux and free.

The standards were set, we would use tar and gzip on the image I had issued, Nano, GIMP, Code::Blocks and the compiler was the GCC for the group.

For diskspace, problems, every individual member was issued a brand new 1TB drive, the Ubuntu Image and they had to host this virtual machine however they wanted, it needed a single CPU core and 1GB of RAM minimum.  Many of the developers were able to tweak and give the machine 4 cores and 4gb of RAM.

Since then the team has run a lot more smoothly, issues with your software, pull the VM image down again... Issues with the source tree?  Delete your local working copy and resync with the repo server!  Need a place holder image?  Fire up GIMP.

This was the first time, since the New Years, that I had reviewed the team in any depth, as a Scrum master in this situation I don't have a lot of blocking or shielding duty, individuals work in their own time and in their own homes, so they have to deliver or fall short.  It is a hobby project after all.

However, our first Sprint feedback is in from yesterday evening, the overwhelming feel is that the team is now working much more quickly, they are verging on out stripping all previous schedule expectations (which were secret from them) and yet they all feel this is easy gliding development time, moving from product point to product point without the hassle of their machine or not being sure how to run an item, or not having the same set up.

My next task?  To do the same with the tester group... What a bag of cats they might be....

No comments:

Post a Comment