Author: datoon

Rhythm

No this is not a post about music.  It’s about software development and more importantly delivery.

Before I progress we are all agreed that we are mammals, therefore have an inbuilt rhythm – http://en.wikipedia.org/wiki/Circadian_rhythm – this is usually a 24/25 hour period in which we all sleep, wake, eat and go to work or do something else!

So let’s elaborate further and take this in to the realm of software delivery.  It appears that we (mammals) need rhythm – “Although circadian rhythms are endogenous (“built-in”, self-sustained), they are adjusted (en-trained) to the local environment by external cues called zeitgebers, commonly the most important of which is daylight.”.

This is where software delivery comes in, I’d like to take SCRUM as the example of setting up this rhythm.  Every 2 weeks we’ll deliver software, have some planning and retrospect.  This sets the pace for the delivery – team members know when things are happening and therefore can get in to a rhythm.  The team understands when the start and end is – they have a focus too for a given time period.

Now I’m an advocate of delivering more often (every couple of days), but I believe that until you can do these things well which is walking, you can’t sprint (no pun intended).

The other rhythm is that of the daily stand up – this occurs at the same place & time each day.

Other Agile practices seem to promote the same ideas – such as the TDD cycle, pair programming (if you pair well – i.e. swapping the keyboard!!).

It appears that with no rhythm you’ll deliver software, but maybe you won’t be going as quickly as you can.

From “Golden Master” to Unit Tests

So I’m currently working on some code which has been written but needs refactoring to add some additional business requirements – there are very few tests.  So I started by wrapping the code that I want to work with a “golden master”/characterisation test below is the pseudo code for this:

[Test, Ignore (Run this once at the begining)]
void GenerateGoldenMaster()
{
Call service
Serialize result to xml
Save to file
}

[Test]
void CompareGoldenMaster()
{
Call service
Serialize result to xml
Save file
Compare with master & assert correctness
}

I save the file so that I can see the results side by side – sometimes this is helpful rather than assertion failure in the test runner.

If you’ve never heard of the “golden master”/characterisation test then it’s a testing technique to ensure that as you refactor some legacy code the output is the same.  Anyhow, as I started the refactor the code to add the new functionality, I noticed a couple of bugs.  Now while you’ve got the “golden master” I would advise against fixing these bugs until a little later in the refatoring stage, I prefer to highlight and fix these bugs by using tests.  This is where you should be going – as I don’t tend to like to run comparison tests in a CI environment.

A couple of things happened while running through the refactoring – the “golden master” didn’t have enough test combinations in.  I therefore had to reconfigure the data in the database to give this additional test combinations.  I only did this once I had everything passing with the original “golden master” that I had created.  This gave me the confidence that the changes to the data would generate the necessary failing assertion.

Once I’d got to a point where I was happy that “most” of the combinations had been covered.  I then started to add the tests which will run in the CI environment.  Essentially, as this is a service with a db, I start by creating an in memory database, adding some data and asserting that the service response contains these bits of data.  I also use random data (guids) generated each test to add some testing invariance…

Now is when I want to highlight the bugs that I’ve found before as I now feel confident that the current refactored code is the same as it was before, but now I can add the tests to fix these bugs.  Insert the data as required then check that the output is incorrect – this will obviously create a red test which can now be fixed with confidence.

As the tests grow the “golden master” can be removed and deleted from the code base.

I’ve used the “golden master” a number of times within production code with no tests, if you find yourself in this position, then see if you can wrap the original code with a “golden master” and then start refactoring.  I think you’ll be surprised how effect they are…

First Impressions Count

You hire someone, you’ve been through the interview process which can take up to 2 hours, you’ve invested time and money in getting that person to come and join your company. Then they join and you’ve not got the induction nailed. I’ve had this happen a few times to myself. Get to the company – no computer or a borrowed computer – sat alone on a bank of desks with none of my to be team members. Walking out for lunch by yourself to find the shops that supply food, which you can’t find because the office is in a location you’ve not been to before. As an individual you’ve perceived this place to work as crap or not. I have positive work experiences after this has happened but it’s taken time for this initial perception to be reversed.

Yet the solution to this is pretty simple – in my eyes anyhow. It just needs a bit of planning ahead, not much but just an idea of how you are going to get people bedded in to your team. Here is a rough guide for an induction that works:

  1. Get all the equipment they are going to be using ordered (fortunately when I was hiring, this was handled by my HR colleague) – it’s got to arrive before and be ready for them to use on the day they get there. Keep pestering until you are happy it’s going to on there desk when it arrives.
  2. Get a desk within the team area – ideally in the middle of where the team sits – if there is no room, make room – move yourselve if necessary.
  3. On the day of arrival get there before they do – i.e. if they are going to get there for 8:30 – you’ve got to be in for 8:15.
  4. Once you’ve been notified they are here – go get them straight away – they are your priority for the day.
  5. Buy them a coffee – have an informal chat about the weekend and travel in. I usually talk about working hours at this point – as people want to know this.
  6. We had a company induction the morning they would arrive – if possible get this out of the way as soon as possible.
  7. Get them to be dropped off in your team area after the induction.
  8. Go out for lunch as a team (you should be doing this every day so adding another person should be easy!).
  9. Once back from lunch – let them setup there kit which will be nicely boxed on there desk. Let them install whatever they need to get there job done (hopefully the PC is already imaged with key software). If there are problems then take them the people who can sort them out (i.e. infrastructure/desktop support people) free introduction done ;).
  10. Give them access to what they need to do there job (i.e. Git, TeamCity, Octopus).

So that’s day 1. The next couple of days are pretty free form but generally I followed something as follows:

  1. Get them working on production code within the first 2 days of joining – I promote pairing so this was easy for them to drop in with a pair.
  2. Get them to release to production within the first week of being at the company – if you can’t release this often then start working towards it.
  3. Walk them through the architecture of the solution they are working on.
  4. Walk them through the full architecture of the eco-system they are working with.
  5. Get them to setup a build pipeline within the first month of being at the company.
  6. Setup your 121’s with them.
  7. Show them around the department – hopefully this should only take a couple of informal introductions – nothing to over the top required.

That’s about it from memory – I know it looks like a lot. But once you’ve done it once it’s a breeze. I’ve found that your other team members will end up helping with this as well! It really does matter making that first impression – people want to feel wanted and valued!

“in the first few milliseconds of our perceiving something we not only unconsciously comprehend what it is, but decide whether we like it or not.”

Kanban board columns

Below is a pretty much “default” Kanban board & the relevant columns.  We still use CFD’s to analyse & hopefully improve flow through our system.  So what I’ve been pondering is whether the below is right for us.

We have 2 main queues that I want to talk about today.  The Dev Done & the Ready for Release.  I’m going to focus on the right side of the board to start with as this is the most valuable side…

What we tend to see over our sprints is a build up towards the end of the sprint.  I’m now pondering the benefit of the Ready for Release column.  Over time stories/work builds up here and is not release.  Part of my limited WIP side comes in to play as well, as soon as I see more than 3/4 cards in play.  I’m probably thinking a little bit about the size of the release and the riskiness of the release too.

So this is starting to make me question:

  • Is this really a good column to have?  
  • Why are we completing stuff in test then not releasing it straight away?  Maybe the transaction cost to live is too much, if this is the case then this is the problem that needs to be highlighted and gone after.  
  • Are the stories not valuable to be released independently and maybe the relative value of them is not important?

I’m also questioning the benefit of any queues in the system – like the one between Dev Done & Test.  It seems as though this is a smell rather than a solution to flowing work through the system.  Queues are just a way to buffer another piece of the system from inconsistent flow of work, most of the work on the board can be controlled by the team.  We have cross functional dedicated teams, therefore they should be able to “dev & test” in a single flow.

Some may say that the start of the system is a queue, but in fact this is simply an input buffer to the system/team.  This helps to prevent variance within the system so that there is always enough work for the team to work on.  Therefore, my opinion is that this is “required”.

Has anybody been able to eradicate these columns?

Maybe all I’m thinking about is Single Piece Flow really…

Test Clean-Up

I’ve recently had a massive clean up of dependencies between our Core solution, tests & everything else that comes to mind.

During this time I noticed a number of tests which fell in to the following categories:

WTF?  Are they testing!
They’ve been in our test suite & build server for a long time in there current guise.  The first set are similar to:
[Test]
public void BuildMeAPanda()
{
     var panda = new Panda(“Chi Chi”);
     Assert.That(“Chi Chi”, panda.Name);
}
As you can see we are simply testing the logic of a constructor.  Not too much value in this.  Although it looks good on our code coverage stats!!!  
[Ignored]
The second are ignored tests which seem to have been written with a future intend – i.e:
[Test, Ignore(“Really need to work out how to test this!”)]
public void InteractWithDb()
{
    var panda = new Panda();
    var repo = new PandaRepository();
    repo.Save(panda);
    // work out what to do here!
}
Broken & [Ignored]
The third are the they broke the build, I must get the build in, quickly ignore the test ones:
[Test, Ignore(“This breaks the build I’ll re-instate it later”)]
public void Bug52358()
{
    // Arrange 
    … Lots of code
   // Act
   … Some more code
   // Assert
   … Some assertion
}
My view on these tests is to eradicate them.  If they’ve not been in your build cycle for some time then they are not adding any value.  They are simply adding overhead to your build time, your thoughts and general clunk within your solution.
I would also try to re-instate the Broken but ignored tests, however, if they fail and you can’t understand them within a time boxed amount of time delete them…
The only occurrence that I’ve not done this – is on those integration tests where you use them occasionally – a prime example of this is testing email & sms sends.  However, these should appear in a different project called:
  • .IntegrationTests
They should be clearly labelled with:
  • [Ignore(“Integration tests!”)]
And over time you probably want to delete these too!?!

Why is Agile/Lean so tough?

I watched an excellent video by Ken Schwaber the other day regarding SCRUM.  Like all these things certain stuff just resonated with me…
One of the key points was how tough SCRUM was to implement and the relative poor success rate in implementing SCRUM.  The reason behind this is due to the tough questions that SCRUM highlights, my firm belief is that “Agile methodologies” like SCRUM, Kanban, etc do exactly this on the tin.  Highlight your problems – I recall a quote, “It’s like developing software in a room with all the lights full blast, compared to the dark room you’ve been sat in for last 5 years!”
People often see “Agile methodologies” as silver bullets – follow some simple rules and this will change your software development process for the better.  I mean what else could be simpler?  It will make you able to accept changing requirements late in the build process, build better quality and deliver faster.  The honest truth is that just following these simple rules won’t help your process.  The reason you’re looking for a change is usually because of the three reasons highlighted.  
  • You’ve got to accept that there are going to be some really tough questions that are highlighted.  
  • You’ve got to accept that you have to answer these questions to be successful.  
  • Only you can answer these questions, not anybody else.  
  • If you’re scared of answering tough questions and having tough conversations then do not engage with these “methodologies”.  Or if you do then be prepared to fail.  
  • So who is “you” – it’s everyone from the top to the bottom.
The answers to these questions will inevitably lead to change, and once again this change has to be done in the correct manner.  Embracing change, and ensuring that everyone is happy with the change is extremely hard to do – it needs time and effort from people.  It needs people to address people’s concerns, discuss why the change is better than the status quo.   
There are better articles about managing change at the following locations:

Am I a Code Monkey?

Last night’s XPMan was really good.  We did some TDD but with no code – essentially we created tests and then created a sequence diagram to pass the tests.  We then applied the RGR (Red, Green, and Refactor) to the sequence diagram as we built up the tests; I found it a really good exercise in returning to the basics of TDD.  One key thing for me was that it’s really important to do the simplest thing first and get this to go red before you do anything overly complex.  During the second kata and my second pair of the evening this became quite pertinent.

However, there is one discussion which provoked some thought and quite a heated exchange.  This came in the form of, “I’m a code monkey and I should just fulfil the requirements given to me by the BA’s/customers.”  This provoked quite a debate about if a BA asked you to jump of a build would you do it?  Another comment was about reading the Agile Manifesto.

So here’s my 50p worth.  Yes I am a code monkey, but professionally I need to question what I’m doing.  However, this has to be done in the correct manner – asking what the business value is of a specific requirement/user story is?  Rather than just saying no.  By asking this question – you are just ensuring that the person asking for the work to be done has considered whether it is valuable.  If the answer is yes, then you have to fulfil this obligation to the customer and complete the requirement/user story even if you deem it as spurious.  This is the professional thing to do.  

It’s really important not to blindly accept what people are telling you what to do, but to ask questions and occasionally say no in the right manner – but the manner in saying no has nothing to do with the Agile Manifesto, more the way you say it.

Maybe an unrelated thing – the Agile Manifesto say’s that we value the things on the left more than the right – but remember the things on the right we still value.  Something I sometimes forget about is that we still need a plan, we still need a contract negotiation – it’s just we value the following changing requirements & customer collaboration over the other two.

So yes I am a code monkey, but it’s important to question what you’re doing before committing to it.

XPMan Introduction to Kanban

Tonight I facilitated an intro to Kanban at XPMan.  This was to run through what Kanban is, and introduce the 5 core properties of Kanban.

The slides for the presentation/discussion points contained the following:

  1. Visualising workflow
  2. Limit WIP
  3. Measure & Manage Flow
  4. Make Process Policies Explicit
  5. Use Models to Evaluate Improvement Opportunities

We didn’t cover everything in Kanban, but hopefully people got an idea of what it is and how they can start using it.

I’d like to re-emphasis that you should apply it to your current process – it doesn’t replace what you do currently it just overlays it.  Look at the stats that you get out of it, and let them drive your incremental change

Links:
Kanban Dev mailing group
Limited WIP Society, Manchester
Kanban 101
Limited WIP society

Books:
Kanban – written by David Anderson the “creator” of Kanban for software development.
Personal Kanban – how to apply Kanban to yourself!
Scrumban – applying Kanban with SCRUM
The Goal – need I say anything?

XPManchester:
XPManchester blog
XPManchester group

Thanks to everyone who turned up and joined in.  Hopefully provoked some interesting conversations and more importantly gave you some ideas to take away.

Collective Code Ownership

I recently asked the following question – What does good team code ownership look like?

  • Everyone adding (good) test coverage
  • Discussing the code
  • Design strategy
  • Adhere to code standards
  • Tool box of patterns

Everyone adding (good) test coverage

This is especially important, tests make everyone feel secure when making changes to the code base.  Everyone in the team must know the benefits of tests, so must maintain them and add other good tests.

Discussing the Code

The code is essentially a living entity, i.e. we add functionality, we have to look after it, it is often sick!  So it’s important that the team talks about the code base.  This is powerful because it gives people are deeper understanding of the code base.

Design strategy

A way to improve the design – most code bases have areas that don’t give us the necessary ways to change the code, or they are hard to test.  So they need to be refactored & improved upon.  We are currently doing this with our UI – using MVP.

Adhere to code standards

Currently we don’t have any standards, however, I do think we have a good code style.  This is mainly garnered from Uncle Bob’s clean code videos – which are excellent by the way – you should watch them if you’ve not (or read his book Clean Code)!

Toolbox of Patterns

You’ve got to be able to change the code, this becomes linked to discussing the code.  Patterns can help with discussing the code…  Having a design strategy – links to this!

This is not a comprehensive list but it’s a good start…

Remember:
“It’s important not to own code you’ve written in a code base; however it’s important that people respect the way the code was written”

Limited WIP Society – Open Space

I attended the second Limited WIP Society group @ LateRooms.com – this was in the format of an Open Space – essentially this is a conference style half hour time slots on things about Kanban and other systems thinking stuff…  The tracks that I attended are below – I’ve tried to remember as much as possible!!

MMF’s (Minimum Marketable Feature)

This was interesting discussion – the main point was the importance of understanding what value.  The definition of value must be shared between the business and development…

Other interesting points:

  • Capability in order to be able to deliver a MMF – so in essence there has to be the technical ability to deliver something within a day.  I.e. can you write code, test it and deploy it easily enough in a day.  If you can’t then your transaction cost is too much and you are not going to get the benefit from a MMF.  The other interesting discussion was about business capability – the business needs to be in a position where it can receive MMF’s and understand the impact on them.  
  • MMF’s are all about reducing risk, delivering value, and having a constant feedback cycle. 
  • Someone mentioned a graph in order to decide on whether an item is an MMF – I can’t find it at the moment. 
  • Alkthough it’s important to say “No” – some times its better to give people options to the business users. 
  •  I’ve also heard of people using the following to decide on an MMF or to clear a backlog:
Somewhat unrelated but still important:
  • Kanban doesn’t work with multiple delivery teams.  If the team does not deliver the same thing then Kanban can’t work.

Daily Stand-Ups & Retrospectives

  • The focus of the meeting should be unblocking the blocked issues – everything else is unimportant.
  • Important that at the stand-up the team is protected.  You need to reduce the external pressure.
  • Managers have a changed role within Kanban – they have to prioritise and help to unblock issues – rather than manage people.
  • The granularity of tasks is important – if the tasks are too big and nothing moves then something is probably wrong.  
  • The issues within the stand-up are important but the detail of the issue is not important.
  • Some retrospectives should focus on analysing data others should be in the normal retrospective style – i.e. what went well, what went not too well, and what can we do better next time.  It’s important that during a retrospective that everyone has done the best that they can do.

Coaching

This was an interesting talk but unfortunately I didn’t take many notes.  It mainly surrounded the fact that the change to Kanban is a cultural one which can be hard to invoke.  Somehow we managed to start talking about The Choice by Goldratt!  @wisemonkeyash talked about the glaze of resistance/layers of resistance and has posted this awesome link about why change is difficult.  We started to talk about mermaids, and crocodiles!  However, the overaching thing for me was that everyone is open to change it is just the way in which you invoke the change that is important.  It has certainly highlighted that I need to read “The Choice” and other books – i.e. Driving Technical Change.

Identify Bottlenecks

This was mostly inspired by the Theory of Constraints – why and how it is important to find a bottleneck.  What to do with a bottleneck and other random thoughts about inventory in software development.  I found this talk to be one of the most interesting because it’s a topic that I’m very interested in at the moment – for this reason I’m not going to excessively talk about it!  This blog contains enough thoughts about this!  It’s highlighted some interesting things about trying to elevate the bottleneck – something we are not doing at the moment.

An excellent night.  I know I’ve probably missed some information!