Friday, October 14, 2011

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.

Thursday, September 08, 2011

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

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

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 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.

Monday, September 05, 2011

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...

“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”

Thursday, August 18, 2011

Limited WIP Society - Open Space

I attended the second Limited WIP Society group @ - 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.


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!

Wednesday, July 27, 2011

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:

Thursday, July 14, 2011

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.

Thursday, June 30, 2011

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.

Saturday, June 11, 2011

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!

Monday, May 23, 2011

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"

Friday, May 13, 2011

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 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!

Tuesday, May 03, 2011

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...

Wednesday, April 20, 2011

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?!

Wednesday, April 13, 2011

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.

Thursday, March 31, 2011

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!

Wednesday, March 23, 2011

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

Monday, March 21, 2011

"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.

Wednesday, March 16, 2011

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!?