Author: datoon

What’s in a Role Anyway?

We recently had a discussion about what the state of the development community at the moment. I’ve also had a blog post with a comment, where I stated is there a need for a BA!? This centred mainly around the make up of the team and who or what key skills you need in a team. As I’ve become accustomed to being just a developer over the past couple of years which has included either of the following: writing code, or supporting production code. Although this has been my primary role over the last couple of years I’ve come to realise – probably since discussing and studying Agile & XP especially that this is simply cannot be the case anymore.

The main reason for this is due to the fact that XP & SCRUM just has a concept of a team – this includes everyone who is needed to deliver a product or rather something of value to the customer. The idea that when the time comes to deliver everyone needs to be able to help to deliver the product – this is mainly because there is not one person responsible for the delivery – the team is responsible. So this means that if there are tests to complete before the iteration completion date and no development work – then everyone needs to “muck in” to complete the tests.

This leads to teams of individuals with multiple skillsets – as an individual you might for one day have your developer “hat” on – the next day your “hat” is firmly in the “test” ring. Traditional role definitions are probably not well used here and are probably redundant. You are essentially just a team member who has more experience in development than testing, BUT you must be able to help with testing if the needs arise. If there is a bottle neck you must be able to relieve the pressure on the bottle neck – otherwise the “team” will not deliver.

This ability to learn different skills leads me to another important asset of any team member – you must be willing to learn. I think Agile especially encourages this, since everything is an experiment? I was listening to a Podcast with Lisa Crispin and a couple of her final thoughts centred on the need to learn and willingness to learn. It must have struck a chord – because I was skiing at the time! I believe these are key skills for anybody working within in an Agile team.

For me this leads to a couple of core things to look for in team members:

  • Willingness to learn
  • Ability to adapt to the needs of the team

“Specification By Example” – Initial Thoughts

I’ve been reading through the excellent “Specification by Example” in it’s early form from Manning. I’ve often struggled with the upstream practises of Agile. Recently I attended a work presentation surrounding capturing requirements and other work which BA’s undertake – it looked very “watefall-isk”! My concern was how to counter this discussion around sign off and the need for documentation.

I’m so glad that I was able to get hold of “Specification by Example” – it’s given me plenty of ideas of how to promote a different way to work. The benefit of living documentation has got to be a good starting/selling point!?

This lead me to ponder what the role of a BA was within an agile/lean organisation. It seems to have been an area that has been left behind over the years. This is primarily due to the fact that most of the original Agile Manifesto signatories where people from the software development field.

I’ve often wondered whether User Stories is all Business Analysts should do; in fact do you need Business Analysts?

Specification by Example answers a lot of questions around capturing requirements in the early phases of an agile/lean project. I’ve tried to map out how I see the process within our organisation – I’m not sure whether it’s what is intended but it’s something that I want to try out in the future:

I will write more about the book, but my first impressions are that I would recommend this to anybody who is developing software, it is extremely informative and well written.

What is Strategic vs. Tactical?

Over the last couple of years the term strategic and tactical has become more apparent to me, this is probably because people have talked about the need for strategic software solutions against the need for tactical software solutions.

I’ve been pondering what this actually means to me! What impact does a tactical solution have on the end user? What does a strategic solution have on an end user? My gut feeling is that the answer would be nothing.

So let’s flip the question around, because I believe the term is coined by developers/management. It may even be an excuse for not doing certain practises. A tactical solution is a quick fix; with very light weight Project Management around it, there may not be time to do any tests and the whole attitude is doing whatever it takes to deliver with the least amount of effort. A strategic solution has PM’s, BA’s and Project Management around the solution. This makes it strategic because there is more governance. We’d prefer to take our time on this project because of its strategic importance.

The definition for strategy is:

  • “A word of military origin refers to plan of action designed to achieve a particular goal.” or;
  • “Highly important to an intended objective”

The definition for tactical is:

  • “Less of a long-term significance than strategic operations”

From briefly wiki-ing and searching on the web, the terms “strategic” & “tactical” seem to have their history in the military. Strange that software development has adopted these words, my view is that there meaning has been modified incorrectly for software development.

If you were to apply these words to software development, maybe they should have a different meaning to what I’ve seen. So here is my 50p’s worth. The strategy is where the overall “architecture” of the company is going – i.e. we want everything to be SOA. The actual implementation – writing of code is tactical – i.e. we will implement this through a RESTFul service using WCF.

Both the development of the application and the overall “architecture” of the system should be aimed to align closely with what the customer actually wants.

The customer probably doesn’t care what the strategy is – they probably only care what the tactical delivery is!?

The Joy of Post Holing


We had a really magnificent week away in Italy – this was all part of my dad’s rehabilation after he broke his ankle/leg in Switzerland on the Piz Trubinesca. You may know about this if you’ve chatted to me – if you don’t you can read the over media hyped version @ you can see it here!


We stayed in Livigno in the Picolo Tibet – which is run by Ercole (I think that’s how you spell it!) – he was a fellow patient in the St Moritz hospital that my dad spent 20 days in following the accident.

We spent the first part of the week skiing – it’s really good swishing down the slopes on the skis. I changed to snowboarding a couple of years back, but have since gone back to skiing. Due to a damaged board after a big gust in Scotland slightly damaged the board, and also I’ve got the gear for ski mountaineering now!

The second part of the week was spent ice climbing. The approaches where pretty awkward due to the depth of the snow – not having snow shoes really tells. Post holing as the “yanks” call it is really exhausting and time consuming when approaching routes. It seems to take a quarter of the time to get down after the route! It may well be time to invest in some snow shoes – the only problem is that they need to be easy to carry and collapsible – it seems that there is already a patent pending!

The first ice route was a WI 4+ it took about an hour and half to get to the bottom of the route the guide book time for the approach was half an hour! The Joy of Post Holing! It was really interesting climbing the top pitch the ice must have been half a metre thick sheet of ice. It kept thudding as you placed the axes and crampons. Quite interesting really – I didn’t put much protection because the ice wasn’t that thick!!! Both pitches where fantastic.

The second ice route was a WI 5 the guidebook says it is only a 90 metre route. It ended up being more like a 200 metre route. The gully was quite long to get to the main pitch which is a really nice sustained 5 pitch. The ice was just good enough to climb on the left – the centre was all rotten out – it had been in the sun too long and was really mushy!!! It was a really good route to do on the final day before travelling back to Zurich. Something to get the arms pumped!!!

A really good trip and a good place for my dad to continue his rehabilitation – to quote after the WI 4+ – “That’s the hardest thing I’ve been on since the accident!”.

Hopefully Scotland will stay/get in nick again so we can get up there for some more ice climbing in the coming weeks. Back to training & work for now!

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.