# Monday, 20 July 2015

Recently I have been doing a lot of coding, and we’ve been working on some exciting things at RippleRock from Lean Coffee Table, TFS Rippler and some advanced HTML 5 charting tools. Our working atmosphere at RippleRock is pretty relaxed with a good work-life balance. As our consultants are usually spread through out the UK (and even some parts of Europe and occasionally India), we make a lot of use of technology to stay in touch with each other. We are all very driven and passionate people about what we do which also makes working remotely from each other (when we need to) much easier to do.

Morning Ritual
The morning ritual is very much the same as a co-located team, we have an early morning stand-up. I personally feel that the day hasn’t started properly unless we have one of these.  One of us will open our task board and display it to the rest of the team and we will talk about what we have done and what we will be working on next. 

Remote Pair Coding
We stay in touch using Skype for Business, Skype or Google Hangouts depending on what works best for our situation. Skype For Business is our go to app for remote pair coding. It enables either party to take control when working together. The developer who has control of the keyboard listens to the observer who directs. We can switch control by giving the observer control using Skype for Businesses “Give Control” functionality. We don’t always Pair Code when working remotely as it can be quite taxing being on a remote call for several hours, however as a team we can spot bits of work we believe will be better worked on while pair coding and when we do this, we end up with some very good results.

Feedback Loops
Because constant feedback is so important we focus on small chunks of work that are regularly committed to source control, run in our CI build and deployed to a server. This ensures we have constant feedback for our morning stand-up's. This also encourages us to try things out quickly if we are unsure on what is the best approach, because our feedback loops are so short we can afford to fail quickly and this way choose the best solution that works.

Code Reviews and refactoring
This pretty much works in the same way as co-located teams. Sometimes we pair when going over code if we need to figure out what was the idea behind some decisions. Other times code is changed and shelved as a suggestion to the developer who is having code reviewed and they can look over the suggested changes, compare and incorporate them to ensure they understand them.

Tools
Tools are not a replacement for process they only help facilitate the process especially for when we are are working remotely. The key tools we have found are as follows

  • A shared remotely viewable board of work. Any kind of web based board be it TFS, Jira or LeanKit will help here to make work visible.
  • Source Control basically goes without saying how important this is.
  • Remote conferencing tools like Skype, Skype For Business or Google Hangout are important. Those that enable remote desktop control are even better.
  • CI Builds kicked off after check-ins provide a fast feedback loop.
  • Wiki or central document area. We find a Wiki for quickly jotting up helpful documentation essential and it encourages use because of how easy it is to use.


.
Tags: Agile | Remote Working

Monday, 20 July 2015 13:35:47 (GMT Daylight Time, UTC+01:00)  #    Comments [0]


# Friday, 05 December 2014

I’ve recently completed a project working with a great development team. Every time you work on a new project even in a software coaching role you hope people learn new things from you and that you also importantly learn new things from them. 

One of the things I found interesting was getting the team to follow Test Driven Development. The reason I was so adamant about it even down to being called “Mr Test” by the team, is that I like many other developers have been on projects where any kind of automated testing had been thrown out of the window or not been given the attention it deserves. All too many times teams have said they are following test driven development and not really know what it actually means. You may have heard the following.

  • “Its only a small change there’s no need to test it”
  • “I’ll write the tests later I just want to get it done.”
  • “I’ll put a task in the backlog to write the tests”
  • “I’ll write the code and you write the tests”

TDD aside, I think the first thing that has to be understood, is why unit testing is actually important. This is the example I like to use. When we build our application, its a bit like building a house, you need to ensure you have good strong foundations before you start building those brick walls. Software development is very similar in the example below our foundation is the code we have previously written and to ensure this code does what it is supposed to we protect what we have previously done with unit tests.

Our tests are our insurance policy. They ensure that our code behaves the way it was intended long after we have left it and moved along to the next piece of development.

image

Just like building the foundations of a house you don’t necessarily realise the consequences of doing it incorrectly until later. Unit testing is very much the same, its not until later that you realise your application is falling apart and you have absolutely no idea why. Every change you make to the application fills you with dread because you have no idea what you will end up breaking next. It can also be one of the reasons a team starts off with a high velocity and then suddenly slows down and stops delivering each sprint. 

When teams start to understand the picture above, the rest usually comes together quite easily. Developers start to realise that even if they are working alone in a team of one on some internal code the value of unit testing still applies to them.

TDD should then be a natural extension after the value of unit testing is fully grasped. Test Driven Development helps us think about the intent of our code, how we are going to test our application upfront, it makes us think about the design and can encourage good design at the same time.



.
Tags: Agile | TDD

Friday, 05 December 2014 12:41:17 (GMT Standard Time, UTC+00:00)  #    Comments [0]


# Thursday, 02 May 2013

My reason for looking into this particular subject was being on a client site and sitting with a BA who was feeling a bit down hearted. She couldn’t figure out how she could properly communicate to the team how a bit of the system worked so they could refer back to it for a piece of work they were currently working on. I asked her why she just didn’t document it, her response to me was “but agile mean’s you don’t write documentation”. I must admit it through me when she said that. I had always without even thinking about the methodology itself provided anything I possibly could to help a team out when they needed it. If it made their lives easier to do a job and to burn through those tasks what was the harm in that? If in doubt on how to provide a piece of information to a team or if you are wondering if it adds value, why not ask them?

For example, sometimes to help a team focus on what they are building I usually suggest taking a wireframe (if you are indeed using wireframes) or rough sketch of what they are working on and place it on the wall. I may even suggest taking a copy of the PBI and sticking it next to it, the tasks that come off that PBI can float around the wireframe and you can use bits of string (nothing high tech!) to point at the various bits they are starting on. After a while the team would start doing this themselves and use it as a handy visual aid to what they were actually working on. In the morning stand-up's they could point to the bit of functionality they were having problems with (if any). This didn’t replace the task board it helped visualise an aspect of it that they were currently working on.

The approach worked well from a top down approach of development. Another approach I found worked after they had worked their way down the wireframes is doing a rough diagram of the stack that sat underneath that wireframe that they were currently developing. They could then point their tasks at what they were working on if it helped them to communicate to the team where they were or helped them visualise what they had to do next. When I say rough it would make sense for the team to collaboratively draw this in marker pens on a white board. By doing this it enables them to change or improve it.

Talking to others about this approach..

They found it was good as long as the wireframes the team were using were those they had contributed towards creating in the first place and that the team accepted they were not set in stone i.e. they could evolve with the teams input.

Using sketches instead of wireframes, gives the idea that the design is not permanent and can be changed at any time.

It was ok as long as the wireframes were modelling what had already been produced.

It was “taken to the team”, i.e. let the team decide if it adds value and or it helps them.

What are your thoughts, are there any visual aids as a developer you may have found helpful in the past?

Please note..
I must point out that I am not an Agile coach, but have worked as a developer, lead developer or architect on several teams in the past.

.
Tags: Agile

Thursday, 02 May 2013 11:37:13 (GMT Daylight Time, UTC+01:00)  #    Comments [0]