Category: Agile

Limited WIP Society – Open Space

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

MMF’s (Minimum Marketable Feature)

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

Other interesting points:

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

Daily Stand-Ups & Retrospectives

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

Coaching

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

Identify Bottlenecks

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

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

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

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!

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.