Skip to main content

Feedback from yesterday's AgileNorth conference.

Note: This is a long post as I've tried to get down all my notes, please skip this post unless you really want to read all my view of the AgileNorth conference!

These are my notes from yesterday's AgileNorth conference held in Preston in the north west of the UK. It was a full day and to be honest, I was knackered! It's funny how listening and talking all day really tires you out. There were approximately 50 people, which seemed about right for the size of venue.

What is Agile? by Kevin Rutherford

The day started with introductions from Phran Ryder (chairman) and Katie Taylor (secretary) covering the format of the day, followed by the day's keynote from Kevin Rutherford, who ran his discussion as a number of agile iterations.

We all added 'requirements' (topics to potentially cover) to the board, then Kevin suggested a number of them that he would get through in the first 'iteration' (10 minute speaking block). It covered a whole host of topics, but two key factors jumped out at me:
* Measure and track the number of running, tested features completed per week (or month) so that you can track how well you are doing with some real 'hard and fast' data.
* Create an interface to management that gives them all the data that they need to do their job, but allows you to do XP within your team.

Fitting Agile Teams in a non Agile Organisation by Lindsay McEwan & Gavin Hope

This session was the main one that I was interested in when signing up for the conference and they didn't disappoint.

They started with a look at how to get a 'team' together that really gels as a team, noted that the environment is very important, they moved into a separate room from the rest of the development department and created their own workspace.

The whole team's work revolves around the 'task board', a large pin board where tasks and stories 'to do' were pinned on one side, and then moved to the 'done' side once completed. It gave a very easy way to see where everyone was up to, and what was outstanding. They have daily stand up meetings where the cards are moved so that everyone is aware of what is being worked on.

They have a 1-hour project retrospective at the end of each iteration (each iteration lasted 2 weeks) to review both technical and personal issues that had surfaced during that time. This allows the team to correct any problems early on before they become big issues. A recommended book was "Project Retrospectives: A Handbook for Team Reviews" by Norm Kerth.

Time management was driven by the task board, items are either to do or done, there is no "90% complete" concept. The daily stand up meeting includes task tracking progress. Only one task is worked on by a developer at any one time - this stops tasks backlogging with one person if they get stuck on a different task.

The whole team are involved in the planning meeting so that all parts of the team are aware of the requirements and features. The tasks are broken down into 2-4 hour lumps, this allows easier tracking and monitoring of the team's 'velocity'. A graph of the time spent delivering business value is derived from the completion of the task cards, this is then used to estimate the number of tasks the team can handle during the next iteration. They suggested that if you get someone who is hung up on the code in a perfectionist way - "the code's just not quite right..." then a good question to ask is "Who is the judge of quality?" - it could be the end user, the support team, etc. Maybe 'good enough' is ok in this situation.

They had major problems trying to implement the 'on-site customer' idea, it just didn't work for them. What was happening was that the customer was reporting a problem to sales, and they would report a solution to technical. What the customer got was usually not what they wanted. They are now trying to gain access to the real customer problems by putting their staff on placements at their customer sites.

They had problems initially with customer support requests. They were tracking the amount of time the requests where taking to resolve, this lead to support tasks being looked upon as "getting in the way of real work". Their solution to this was to add the support request as a regular task to the board, and then track how many support tasks were being completed each week. They then factored the average number of support tasks per iteration into the planning for subsequent iterations.

15% slack time was added to each iteration for continuous improvements and planning for the future. Recommended reading was "Slack" by Tom DeMarco and "Lean Software Development: An Agile Toolkit" by Mary & Tom Poppendieck.

Managing Agile Projects by Jim Sutton.

Jim's presentation focused on how and why his company needed to go agile and some of the difficulties faced when trying to do so. The title lead me to believe that it was going to be more 'down to earth' on how to manage the team on a day to day basis.

None the less it was a good presentation, here is a list of the items that I pulled from it:
* Break the cycle - do one thing VERY differently!
* Try the daily stand up meeting
* Have a "cut the crap" card that can be held up when discussions get too woolly
* Use 2 week iterations, monthly is just too long
* Sales and marketing departments are still very non-agile, this can be a problem

Refactoring by Ivan Moore & Duncan Pierce.

This was my 'developer' session of the day, where Ivan and Duncan along with the 20 (or so) audience performed a live refactoring of some very poorly written java code. Ivan was using Eclipse to edit the code, and was quite a wizard at using the refactoring tools on offer. It was mostly a discussion-led session with not a lot of things to note down but I learnt a lot about using the refactoring tools and how to spot code that was ripe for refactoring. Suggested reading was "Working Effectively with Legacy Code" by Michael Feathers and the "Refactoring Workbook" by Bill Wake.

All in all it was a fantastic day, and really re-energised me into 'the agile way'. Now I need to figure out how to introduce agile and XP into the company I work for...

Technorati Tags: , , , , , , , , , ,


Rob Baillie said…
I'll get round to reading this post, I will, I will!
Anonymous said…
Just a comment on "Fitting agile into a non-agile organisation". The company that used to employ these had to make dramatic changes due to a downturn in the business, which was in part due to the development team losing focus and working on unnecessary things. The "internal" customer approach meant that external (i.e. real) customers were not interested in the end product. The management style was such that a lot of good staff resigned and we unfortunately lost some more during redundancies.
Any company looking to use agile should also consider reading Steve Yegge's blog as a warning about how bad things can go.
Anonymous said…
James McGovern is right - the people speaking at these conferences tend to have vested interests.

All these "methodologies" have a small number of decent ideas in them. Forget the books and consultancy, read a little on-line and try out only the _really_ sensible bits and see if they help at all. There's no need for widespread changes, just try a little at a time. If it doesn't work for you then drop it. Above all, don't line the pockets of the consultants - they'll just try to sell you the next fad once the can't sell Agile.