Delayed Value

Having my last look at the board today, I found it interesting that we have work items sat in the “Ready For Production” column. The total items in this has grown over the last couple of weeks – we now have 7 items ready for “Production”.

These items all have a varying level of “Business Value” (value) associated with them – but are sat in the system. They are all blocked by the same thing – the legacy system has a quarterly release cycle.

This poses a couple of questions:

  1. Is there a threshold before the amount of value being delivered outweighs the cost of putting that value live?
  2. Should every single piece of item developed be pushed live as soon as it is ready – therefore giving you an instance ROI?
  3. Are the items of high enough value to the customer if they can just sit in the “Done” column for a couple of weeks?
  4. Do the customers have visibility of what is “Done”?

My gut feel is that the first question is a cop out – the cost of pushing things in to a live environment should be minimal because you should really have seemless CI. It should be of no extra cost to put code in to a live environment. If it costs – you need to spend time & money on improving this build & deploy system. This is an Internal Quality as Martin Fowler puts it.

If you push every single piece of work live you need to have customers who can accept a constantly changing system. This maybe difficult but I think it depends on what you are delivering – i.e. defect fixes, and minor enhancements could be dropped in at any point. With large changes in functionality – it depends on how involved the customer has been with the development. Here we probably can’t do it, because the customer is not overly involved.

The above statement probably answers the last two questions as well. It’s all about the customer deciding on what to develop – this way they can decide upon the items with the highest value. They also know when items are complete.

This is one of the 4 principles in the Agile Manifesto – “Customer Collaboration”.

Team Foundation Server – Test Presentation

Since I joined my current company I’ve been tasked with learning about Team Foundation Server. It was seen as key component to future development within the company. However, previous initiatives have fallen by the way side over the years. I think these have not worked because they have failed to interact with the larger audience of IT – i.e. outside of just the .Net development teams.

It has often been seen as a “thing” that was coming but no-one really knew about.

We finally get a production ready instance of TFS 2010 this week. After numerable test instances have been used and “toyed” with.

Weirdly I’m leaving my current company in the next week, and yet this initiative seems to be finally getting some steam behind it; or at least it felt that way today.

We’ve been using it within our development team for.Net technologies for the last 5 years or so, more recently we’ve been starting to use it for User Stories/requirements, work item tracking and general reporting. CI builds where going to be my next task.

Today I’ve given a presentation to the Test team. After a trial demo to our development team the other week, this seemed to send everyone to sleep!? I decided to change the format, I hoped it would make it more interactive and actual let me know what people thought about TFS, what they’d heard about for so long – but never really seen. I also needed some help – since I’m not really a “Tester” (although I’m trying harder to become multi-skilled – I might blog about this separately!!!) – so didn’t know what to show them. I can give a demo to developers easy since I know what they want to do.

This led me to the following format for the presentation:

  • Get an understanding of what the group knew about TFS?
  • What they thought TFS was?
  • What they thought TFS would do for them?

I linked this to another item:

  • What are the current problems within “Test”?
This gave me a lot of ideas as to what they actually wanted to see, it also highlighted what TFS wasn’t going to give them. I.e. it isn’t going to solve World hunger, or poverty!!!

After this I let the group drive the demo:

  • What do you want to start using?
  • What do you want to see?
  • What do you want to explore?
I found this helpful, and hopefully they enjoyed it and saw the potential of TFS. I have to re-emphasis that I am no expert on it from a “Test” perspective – I simply know of its potential to fulfil some of the problems that they currently have. It’s essential that someone takes the time and interest in the tool to try to solve some of their problems.

It’s definitely a tact I’d take with any other presentation/demo I’m giving in the future!

BDD – Initial Experiences

I’ve recently discovered BDD or rather there has been an increase in communication about this topic around me – someone mentioned Cucumber at XPManXL!

I found the extremely well written Cuke4Ninja site, and started to discuss Specs more with my colleagues. Jason highlighted that SpecFlow seemed like a good implementation for .Net development.

This all seemed to align with both Gojko Adzic at Agile Yorkshire which I unfortunately missed, but made up for with attending XPManchester where John(no) gave a presentation/discussion about BDD for his Masters… He asked us to implement a Chess Kata using some features which he has developed – these can be downloaded from GitHub.

I spent a bit of time trying to implement the features. My first experience of BDD! I found it quite overwhelming initially with all the specs running. I.e. I had quite a lot of specs/tests running and didn’t know where to start.

Retrospectively I should have included a single feature – implemented it till green and then incrementally added features as I went along. This is something I am going to do on my second attempt. I plan to throw away my initial code and start again. Although I’ll probably use a similar design I’m interested to see how after my initial attempt how it will differ – will it be better design?

Initial thoughts are that features are a way to have a shared vocabulary between developers and business users. I also think that they are the Acceptance Criteria which are usually written on the back of User Story cards.

I’m also slightly confused at when to start delving deeper from high level features in to say lower level “Behaviours/Features”. This I’m sure will become apparent as I spend more time using BDD.

Kanban – Retrospective – Categories for Improvement

We keep having weekly retrospectives about the Kanban board.

Last week’s retrospective probably went a tad off target, or maybe it produced ideas which don’t improve the process of our team, rather than general ideas about the board. Note: no idea is wrong or right during these retrospectives – it’s just the focus might have been lost on the purpose of Kanban.

Last week we looked at things that “went well”, things that “went wrong” and things that we wanted to “improve”. We then voted on which improvement ideas we wanted to implement. You can see what we implemented in my last blog post.
This week we invited Andy (our very own Lean/Agile samurai) to the retrospective, partly to see how we should run a retrospective, and partly to get some focus back on Kanban.

The following was the rough structure of the retrospective. The first was a discussion between pairs about “Why we wanted to do Kanban?” and also “What we wanted to change?” These where put on post it’s and stuck to the wall randomly.


We silently organised as a team the post-it’s into groups. I found it especially interesting the commonality between the post-it’s that each of the pairs came up with – probably not very interesting since we all share the same goals & grievances!

The team then came up with the following list of categories for each of the groups of the post-its (in no particular order – I just wrote them down this way!!):

  • Teamwork
  • Customer Satisfaction
  • Problem Identification
  • Prioritisation
  • Predictability
  • Speed
  • Transparency


The team scored each of these with either an “x” “–“ or “tick” depending on how we felt things were currently. We scored the majority with a “-“on some categorices and “x”’s on other categories – as you would expect. None we scored with a “tick” – we had some small ticks though!!!


We then paired again (with different pairs) and asked each other how we could improve the process targeting the above categories.

We fed this all back in to a whiteboard – and came up with a list of things to improve. We each had 3 votes again and got to vote on an idea we’d like to implement. The ideas we are going to implement are as follows:
  1. Measure cycle time overall and between different work types & stages.
  2. Limit number of items coming in to the start of the workflow & each stage.
  3. Cut things down into smaller chunks of highest value.
We are going to try to implement these this coming week, to see if it improves parts of the process. The impact might not be immediate but Rome wasn’t built in a day (I’ve used that quote too often recently!).

An important thing for me is that we start to get some stats about the work we do in our “development system” – i.e. how long it takes for us to complete different work – what is the cycle time for a specific type of work?

3 Weeks of Kanban

So we’ve had the kanban (note the small k!) board for nearly 3 weeks now. It’s been quite a learning curve. Especially since a few of us know the theory and some are really new to it.

The first thing to know is that the daily stand up is a new idea, so quite a few people are alien to what the purpose of the meeting is. This makes it seem quite an arduous task to stand in front of the board for 30 minutes initially (times have come down in recent weeks).

This is primarily due to a lack of shared knowledgeunderstanding of the purpose of the daily stand-up. As I will now highlight!!!

Compared to a SCRUM meeting the Kanban daily meeting is significantly different. My understanding of SCRUM meetings are that they take the following format, each member of the team say’s:

  1. What they did yesterday.
  2. What they plan to do today.
  3. What issues you have.

Having read about these meetings, my general understanding is that they do not scale – i.e. they start to take longer than the 15 minutes allotted when you have more than 10 team members (note: everyone is involved!).

My understanding of the format of a Kanban meeting is as follows:

  1. Highlight anything that is “blocking” a work item – we call this an “Issue”.
  2. Pull the next work items in from “Done” columns.

I’ve read that mature adoptees of Kanban will actually perform a retrospective during the meeting. I.e. why is this issue preventing this item from moving? How do we prevent this from happening again?

So you can see that I have a specific understanding of daily stand-ups! How are we going to share this knowledge?

Well today I’ve been trying to write the ideas above in to an “explicit policy”. So now we have a “Purpose of Daily Stand-Up” – which ironically has the information highlighted above. This is a single power point slide – the key here is brevity (which I’m not very good at most of the time!).
We also needed a definition of an “Issue” so that people are aware of what we are trying to highlight during the meeting.

“Solving Issues” also has a definition and ideas of how to solve issues. The most important thing is that anybody can solve the issue. Another important thing is that the issue is taken away from the daily stand-up – otherwise it turns in to a conversation between only a few people; then no progress is made during the stand-up people not involved in the conversation get bored.
All of these lead in to a Retrospective – i.e. “How can we improve flow?”, “How can improve different areas of our process?” These are placed on another slide. So now we have four slides which hopefully outline “explicit policies” or definitions – hopefully these will help over the coming weeks.

Other things that we probably need to consider:

  • Size items – could we use T-Shirt sizes?
  • Mark on items when they move – i.e. transition to “Done”, transition to “In Progress”.
  • Mark on items each day they are in a certain area on the board.

So to summarise some important lessons:

  1. We are always learning.
  2. We have plenty of good ideas from all the team for the board.
  3. The board will change.
  4. We probably have too much Work In Progress.
  5. Meetings need a purpose or goal.
  6. Meetings need an agenda.

Test Driven Development – Personal Retrospective

Over the last year, members of our team have realised that we need to change the way in which we work, this is both as a team and as individuals. The first stage of this is in the realisation that we are actually doing something wrong in the first place. This is a personal experience of mine with regards to Test Driven Development (TDD).

A key realisation was that we need to ensure that quality is higher; quality is always a word which makes me think: What is quality? How do you define quality? I often think that quality is one of the most subjective words in software development. I’ve come to realise that quality isn’t just about how good the code is. It’s about meeting the customer expectations as quickly as possible – that’s the purpose of our job (the Agile Manifesto highlights this).

One of the key things to quality is that getting through system test shouldn’t be a chore. It should be a pleasant experience and the amount of back and forth between System Test and development is a good indicator of poor quality. (Note: this isn’t the only measure of quality; this article isn’t about code quality). This should be reduced to the minimum. This is twofold:

  1. It can cause friction between developers and testers.
  2. More importantly it ends up costing you a lot – of trust, and more importantly money.

Unit testing has been around since the computer was born – well programming was born. I wonder whether Ada Lovelace had Unit Tests. I recall my time at University and that my key lecturer – Tony always wanted you to have test harnesses before he’d accept your code for assignments. This meant you had a suite of tests which ensured you substring written in assembler would work. You’d pass in certain strings and then see whether the expected came out – failingl the test if it didn’t work.

I often wonder where I lost that skill or why I forgot to do it. After I graduated it all became about writing code and getting it in to production as soon as possible. It didn’t matter about the tests; it just mattered about getting the code out as soon as possible. How mistaken I have been. I must have cost companies a fortune; I’ve been for interviews where they asked, “How do you test code?” – press F5 and play around with edge cases was generally my answer. You could see their faces – “What about NUnit?”

Big admission I know. For me over the past couple of years I’ve come to realise that software development is all about learning, the faster that you can learn the more adaptable and more progressive you become as a developer.

It’s taken me about 6 months to get used to Test Driven Development, and get it (nearly) completely embedded in to my development practise. I now feel that I have a better understanding of how to write tests, and write better quality code as a consequence. This hasn’t been easy – it’s been hard work, changing the habit of my entire (semi) professional programming career. Write the tests first, and then write the code to make those tests pass.

It is amazing that it now “feels wrong” to be writing code which doesn’t have a test. How weird I wouldn’t have cared a couple of years back. It’s definitely been a learning experience and something that I am now keen to share with other professionals as well.

Once you become passionate about a technique it can quickly rub off on to other people.