Author: datoon

Efficient Vs. Effective

I’ve been thinking about “The Goal” of Kanban in our organisation for some time.

I believe that there are numerous (side/non) goals – however, the one true goal is to deliver high quality, business value to the customer.  However, to enable this to happen a Kaizen (continous improvement) environment is likely to aid & probably help you on this “path” to the goal (you might never get to the goal – it is after all a goal).  You also have to accept that life/business/software dev/nothing is never static so you have to be able to adapt your process to ensure that you keep delivering value to your customer.  This Kaizen environment helps people to eliminate waste, but also empower people to make changes to a process or system which isn’t helping to deliver value to the customer.  Anything that doesn’t add value is essentially waste.

I think there is a lot of “Non-Value Added” time during software development.  In fact maybe the only “Value Added” time is the point in which you push/pull it to live.  Everything else might just be “Non-Value Added” time!
 
So what exactly is efficiency within Software Development – well to me now it’s clear – thanks to wikipedia & the above mind burb!  Efficiency in software development is anything that is not “Value Adding” in your current value stream.

Now you might think – well if you’ve got Kaizen time (i.e. slack time to improve your process) how is this adding value to your current value stream.  Well it might be something to help improve the flow within the value stream.  This is as important because you are trying to optimise the current value stream – so essentially you are aiming to add value or remove waste from your value stream (agh confusing!).  It’s important to accept that these might fail sometimes – but hey people make mistakes and learn from them.

I think Effectiveness & Efficiency get confused.  I’m certainly confused this late at night!  Let me give some arbitrary examples of measuring these two things…

Measuring Effectiveness might be measuring the number of LOC (Lines Of Code) a developer writes.  However, this is irrelevant in line with the “Goal”.

Measuring Efficiency might be measuring the amount of Business Value a developer delivers to the business.  This is more relevant to the “Goal”, and to some degree is measurable against the goal.

However, this will promote local optima – promoting selfishness, and definitely promoting a non-kaizen environment.  This would lead to a process which is not optimised – you essentially get silos of optimised process, with other areas unoptimised.  That’s why it is important to look at your full value stream when measuring Efficiency.

Before measuring Effectiveness think about the impact this might have on your overall “Goal”.

Thanks to the following for making me think about this stuff way too much:

Increased WIP = Increase in Lead Time

I’ve been viewing our Cumulative Flow Diagram and some interesting stats surrounding the work we are developing, our current flow rate and WIP.  Today I was able to see how increasing our WIP directly affects our Lead Time.

Our big spike is due to all the items being placed on the backlog (TODO) – although some of these may never be implemented more on this in the future! 

To summarize some of the information I can see (and you can’t!):

Average Lead Time for any sized item from inception to live:

  • 35 days – 7 and 11 items in progress
  • 21 days – 2 and 5 items in progress

There are a number of things to note:

  • Variability in size has an impact on lead time – large items increase lead time.
  • Increase in Work in Progress decreases lead time.

 The above ties nicely in to Little’s Law.

Ye Olde Story

Back at the start of time, or rather the inception of the company there was a small IT department this had to work closely with the business in order to fulfill the ever changing requirements of the business.  The IT department of two had to work this way to ensure that the newly found company always had the competitive advantage.  

Unfortunately, as the company got bigger more things started to flow in to the system (IT team) and slowly the development team of two where overwhelmed with the requests being asked of them.  They became the bottleneck in the system.  In order to alleviate this bottleneck the company hired two more people, this had the desired affect and the IT team could develop some of the functionality that the business wanted.  At the same time the company hired more people with more great ideas of how to improve the business. 

As the business grew, the list of items for IT expanded exponentially until it became full of things which added little bits of business value but at high cost, the list of items was not prioritised.

At this time the IT department decided that it needed to help manage this list of items because the development team couldn’t complete all the work.  The company decided on introducing contracts and processes so that when those pesky users could only put something on the list if it was fully thought of – or at least had enough detail to work on.  The customer started to gold plate features/products just to ensure they get there idea got through; this meant that the bottleneck which was the development team started to do work on items which added very little value to the business.

Parts of the process was deemed to work well for a period of time, but alas no-one recorded the before and after to see whether the new found processes improved the flow through the system.  Even more importantly, no-one measured whether the development team delivered value to the customer.

The IT department started to monitor work it realised that it was slow to deliver change to the business.  The processes that had been put in place to manage the work were not delivering value to the customer as quickly as the IT department had envisioned. 

The solution to delivering value was simple but hard to implement.  The IT department needed to realise the following:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
  • That is, while there is value in the items on the right, we value the items on the left more.
The “pesky end users” where in fact the customers and needed help to get rid of items which didn’t add value or not have a good ROI – this needed to be done through improved communication – rather than more processes and barriers.

Fortunately, the IT department realised that it needed to evolve from its current state in to a new state, where it delivered high value software to its customer.  This was only going to happen through hard work, and through frank conversations within the team, and by evolving there processes to match their customers’ needs.

How Communities Can Help You

I was fortunate enough to attend Agile North Conference yesterday.  I spent all the day in the practitioner based stream of the conference.  I came away from yesterday brimming full of ideas of how to deal with some of the problems that we have at work.  I’d say that most software development companies have these common problems. 

Most areas where people live and work will have regular user groups for people who are interested in their craft (software development).  I regularly attend XPManchester which is another great community from which to get ideas about eXtreme Programming, although there are other things which come out.  Come along!

After XPManchester I met up with a couple of team members who had attended the BCS event about automated testing.  I was slightly late to the pub but could hear the geek conversation going on downstairs – my colleagues were also brimming full of ideas and thoughts from that event.

These community events are really fantastic place to get new ideas from, talk to passionate people and generally get a buzz for development back – if you ever lose it! 

There are loads of ideas out there, go and read about them.  If something isn’t working at work then try to apply an idea to it.  If it works then great – if not then don’t get disheartened keep trying different ideas until you find one which works for your environment, and even go back to ideas.  If they failed back then it might be just because you didn’t do it in small enough chunks, or you didn’t really implement it properly.

Keep the changes small, and quick to reverse.

Once you’ve found something that works, share it with the community!  Most other companies are having similar problems to yours!

Share the communities you find with your fellow colleagues at work – some people will definitely be interested in attending!

Playing By the Rules

I’ve been trying to reflect on some of the recent successes we’ve had at work.  These successes where highlighted in a recent retrospective we ran last week.  Increased teamwork/collaboration, and improved built in quality to a certain degree. 

How over the last couple of months has the team seen such a rapid improvement?

The answer is pretty simple really – we have been playing by the “rules” outlined in eXtreme Programming & SCRUM (to a certain degree):

  • Pairing
  • Test Driven Development
  • Planning Poker
  • Retrospection
  • Daily Stand Up’s
  • Continuous Integration (to some degree)
  • Reflecting on Agile In A Flash cards 
  • Watching Clean Coders

As one of the Agile In A Flash cards said the other day – we have been playing by the rules, which is something we must keep doing until as a team we are more mature.  Once more mature we can start to review the “rules” and adapt them to our situation if they do not fit.  Hopefully this will allow us to further satisfy the needs of our customers.  In my opinion the most important part of software development. 

As a team we probably need to refine our pairing, and having properly defined roles during pairing.  How to ensure that both driver and navigator are working together.  A common problem is the navigator is distracted.  We could simply do the write a failing test then swap, scenario which I have seen work well at XPMan.  Another way is to use the Pomodoro Technique.  As I’m writing this it’s probably the case that as a team we should decide on a way to pair and follow this for a couple of weeks an retrospect on it!

Test Driven Development is another area that we need to get better at, but I think we know what we need to do – we just need to start doing it!

As you can see there is still much to do, a recent mind map highlighted just how far our team has to go.  Some of this is in relation to rules we’ve not implemented and some of this is just to enusre we keep applying the “rules”

Feeling the Rhythm

This week has seen our team embark on a major piece of new functionality for our legacy system.

Our progress has been relatively slow up until today, this might be due to the stories being epics, or it might be that we are doing all the right stuff! 

Test first (although probably not true TDD), pairing, getting existing code under test before modifications, improving the design of the existing code base.

We have two pairs who are working together on two stories.  Two of the people have swapped mid-week, Russell and I, have “owned” a story for the week. 

The two stories we are working on are quite different, the first story (which I fortunately picked) was to create a new page for the legacy system.  The code for this has been written using TDD; the new page interacts with the legacy system through the Model.  You might question why I stated “not true TDD” earlier – the reason is that we are lacking the automated acceptance tests to ensure that the outer ring of the TDD cycle is correct.  This is something I’ll be feeding in to the next sprint.

The other story is updating an existing page.  Essentially this job is three fold – get the code under test, improve the design (change to MVP), and make the functional changes.  This has been a huge job.  Unfortunately, we are not going to be able to fit everything in to this sprint; however, we will be able to leave the code in a better state than when we started!  We are forcing ourselves to pay back the technical debt that has been accrued – this is quite painful and time consuming!

The pairing has been extremely beneficial – it’s made the team focus on getting the job done.  I can’t say whether it’s improved the code quality, my gut feeling is that it’s caused conversations about the design of the code, which has simplified it (the tests also help with this), and also caught some things which are just plain wrong.  We even had a CRC session to flesh out some of the details of the classes and to ensure that they had the correct responsibilities (thanks Sam & XPMan!).  Pairing also seems to add energy to development or maybe that’s the caffeine!

It’s felt like we’ve not moved much for most of the week, but this afternoon the team’s feeling was that we were eventually getting somewhere!  The team decided to add a couple of hours to our afternoon – something which I’m not always too keen on – I’m a believer of a sustainable pace.  However, I also believe that if the team is agreed then this rule can be bent a little.  So we stayed for a couple of hours, and managed to get a couple more tasks off the list, and now we are pretty close to completing the two stories. 

This week has had a really good rhythm to it.  The Red-Green-Refactor cycle lets you get in to an amazing flow, of sadness then happiness, then more happiness as the code is refactored.  The team has been trying to apply what we’ve learnt from the cleancoders.com webcasts to the code base.  Especially the Boy Scout rule.

It’s important that we ensure that we deliver business value, but also improve the code base to work with, and have fun!

Motivated Individuals – Great Teams


Getting up at 4:30am in the morning on your holiday may seem like a bit of a daft thing to be doing; in the end holidays are meant to be relaxing and a time to unwind.  Some people enjoy lazing on a beach.  Unfortunately, that’s not my idea of a holiday – my ideal holiday is cramming as much “stuff” in to the shortest possible time.  “Stuff” is defined as ski touring (where I’ve been), ice climbing, rock climbing, skiing.

So what’s the reason for getting up so early and how does this relate to anything at all!!!

Well the reason for getting up early (especially in huts) – is because the hut guardians generally want you on the hill early so you can be back early.  The reasons are probably three fold:

  • In winter the afternoons bring a greater chance of avalanches.
  • In summer the afternoon brings the possibility of thunderstorms.
  • It also gives you the most amount of time to achieve your goal – i.e. go up a hill/mountain!

I’m not one for getting up early, however, on holiday it seems even easier to get up than it does on a work day.  It is quite simple go to bed a lot earlier than normal so that you can ensure that you are fresh in the morning – there is also not much to do in a hut after dinner!

When you get up in the morning at “silly o’clock”, there is an enviable buzz around the hut – people are psyched for the day ahead.  This energy is really amazing, you can feel it flowing through the building. 

This is the perfect example of building teams around motivated individuals (read principle 5), if a software team had the same buzz as my fellow mountaineers/hut goers then it would probably build kick-ass software.  Quite assumptive I know!

My mind now ponders at how to get this motivation flowing through everyone in a team; is getting people up at 4:30am in the morning reasonable!!!

Having a shared goal would be a good start, and finding out what motivates each individual in the team…

Baby Steps

We’ve been recently working on moving the legacy UI code to MVP.  This week has seen my focus move from doing some of the initial work, to a support role within our team.  So the focus has been on fixing live issues that we currently have within our system.  I might blog about the reasons I think we have these support issues in the future. 

As the week has progressed (it feels like a long week, maybe because it’s a short week!) – I’ve been getting more involved with a colleague who is now converting the legacy code to MVP.  It’s been extremely interesting pairing/mentoring the developer.  My colleague is quite new to MVP and test first approach so it has been interesting to see how focus can be lost quite easily – thinking about other sections of the system. 

I think this is to do with focusing on the problem at hand, not getting distracted by other issues and just solving the current red issue – the broken test.  Once this is green we can think about things which might be important or not be – i.e. how can we improve the current design and the current code base.  Or even add another test to highlight the current hacked – I’m very much of the ilk of doing the simplest thing to green.  Maybe I’m just plain lazy or like to KISS.  Maybe I want to ensure that my focus is on the smallest possible thing.  A former colleague always used to say, “I can only concentrate on one thing at once.” 

This has made me think about a number of things.  Developing software is hard; thinking about an entire system and its interactions is even harder.  Sometimes developers struggle to focus on their current problem and get distracted by something completely different (i.e. the entire system!). 

This is the reason it’s important to write tests first.  The act of writing the test focuses the mind on what it is we want the method/SUT to do, we can then focus on doing the simplest thing to get the test green.  Once this is done we then focus on refactoring.  We then repeat.  This ensures that we keep focused as we write the code – it’s a very nice rhythm, and very rewarding (amazing how seeing something go green gives me a thrill!!). 

I recently sent out the code kata that Roy Osherove put on his blog – the string kata.  It’s interesting that the notes say ensure you do not rush ahead of yourself and do not scroll down.  Something any human being would want to do, we are thirsty animals for information and problem solving!  I know that some people might struggle with this!

I suppose this poses a couple of questions for me:

  1. Are we killing the inquisitiveness by stopping people from rushing a head, or just simply focusing the brain power of the individual/pair (I know that in a pair one will concentrate on the code, and the other on the design) on the problem at hand? 
  2. Do we currently struggle to focus on a single thing?
  3. Can the human brain multithread?!

Exposing Code Smells with Tests

I’ve managed to complete my other project within my original estimates – I will blog about whether visualising the work and the other approaches I took worked/helped next time!

Today’s task has been to start converting the UI layer of the main legacy system that our team maintains to MVP.  I’m not going to delve in to the reasons why we chose MVP; well I think we just decided that it would be the easiest path to getting the UI under test.  The team probably has more experience with MVP than MVC so it’s probably a wise choice! 

I’ve taken a relatively simple screen to start with, one that shows the notes on a specific Sales Order, allows some filtering, and allows the user to add an additional note.  Instead of delving straight in to the ASP.Net code and slotting tests around the existing functionality, I chose to simply abstract the current functionality in to the presenter.  This was all done using tests to drive the code.  Essentially the tests are what the code does “as-is”, so I suppose you could say that I let the current implementation drive the tests to a certain degree. 

As I started to increase the number of tests around my newly created notes presenter class, interesting patterns and problems with the existing code emerged.  Since I’ve become an advocate of a Test-First approach, I’ve noticed that code not written by tests doesn’t show problems – early in the development cycle.  I also think (maybe wrongly) that code doesn’t get refactored if you don’t have good tests – therefore ending up spaghetti-fied or just damn hard to highlight problems.

The existing code does a number of things:

  • Shows all the notes; Or;
  • Allows you to filter notes
  • Then displays the count of each of the types of notes

Now as the tests have grown I’ve found the existing code does the following:

  • Shows filtered notes/all notes
  • Then gets all the notes again to display the count of each of the types of notes.

The presenter should just get all the notes then filter based on the current filter criteria.  This removes the dependency on multiple calls for the notes.

The other thing I found was that the NHibernate ISession is used at quite a high level – with the Service (essentially the Model that I’ve been using for the Notes – it was in existence already) that I am calling to get the Notes.  The problem was that I had to force the ISession in from the Presenter.  This has made me feel really uncomfortable –a code smell!  I’ve had to mock the ISession object out for all of the tests since I am using constructor injection.  Really this dependency should be pushed right in to a Model. 

Thinking about it further (as I write this blog post) – it is probably about time to create a real model.  I thought I could have got away with using the existing note service for this purpose.  This in essence would be a model/façade so I no longer have to mock the NHibernate ISession.

This is something I will endeavour to do on the next phase of development (i.e. tomorrow!).

I find it interesting that the things above highlight themselves after only writing a dozen or so tests.  It definitely backs up my thoughts on test-first development, and makes it even more crucial to write them all the time.  There has also been the added benefit that I’ve been able to fix a minor UI bug with the code that I’ve written.

Visualising Your Own Work

The project that I’m working on at the moment is pretty small.  I’ve been given the freedom, or ability to introduce some of the concepts that I’ve been reading, and thinking about over the last year. 

To summarise – I have my own features for the functionality that I am going to implement.  These have been written as acceptance criteria using SpecFlow – and the Given, When, Then syntax.  Hopefully, this will ensure that the product that I develop delivers what the user wants (I can’t say what the user wants as this is a confidential product).  I’ve found that my customer is extremely positive about using this, although we’ve probably not had as much face-to-face conversation as I would have liked.  Maybe I should explain this…  I’m convinced that some of the acceptance criteria would be better business aligned if we had a discussion rather than e-mail chain.  Ironically, since I’m new, I’m probably a tad nervous or shy to be forcing workshops on people (people who know me might laugh at my shy reference!).

I’ve found the Given, When, Then extremely useful and forces me to think about what is important for the user.  I’ve also used BDD/TDD for it as well – I’m more than confident that the design of the component I have written is a lot cleaner than I would have written a couple of years back.  I’m pretty happy with the design and lack of duplication in the code.  I’ve tried to be extremely hard on the refactoring – something I need to work on more and more. 

The other thing I’ve started as of today is my own visual board.  The reason for this is I’ve been struggling to focus on what to work on next.  I’m interested in seeing how this works; I can already feel the benefit of having something visual forcing me to think what is next and get on with the work!  Therefore, I know have:

I’ve had to get rid of what the cards actually say sorry, but they are just succinct pieces of work for this project.  The pink items are blocks, or rather problems with the card – these need to be resolved before the card can be moved to “Done”.

I’m not going to apply Work In Progress limits yet, I’m not sure whether I need to apply this to the project – my estimate is that the work will take 10 days, so should fit in a single iteration!?

Really I should have a Continuous Integration environment for the project!