You are currently browsing the Agile Staffordshire posts tagged: meeting


October 2013 – Agile Experience Guest Speaker

Go to Codeweavers

Date: Wednesday 30th October 2013
Time: 7:00pm
Venue: Staffordshire University – Stafford Campus (Lecture Theatre 2 – the Octagon building)

This month we welcome Mr Craig Judson from Codeweavers Limited. Codeweavers are a local company, based just outside Stafford in Dunston. They adopted agile techniques in 2007, starting with Scrum and have continued to evolve their agile techniques ever since.

Following graduation from Staffordshire University School of Computing, in 2006, Craig joined Codeweavers as a developer and has since progressed to become an Operations manager. He has previously spoken at international conferences and BCS meetings.

Craig’s talk will discuss how Codeweavers have adapted agile techniques to fit their requirements. A taste of the topics covered are:

  • OO and behaviour
  • Code smells and ‘if’ statements
  • Continuous Integration and Source Control
  • Pair Programming and the Pragmatic Programer
  • Kanban and Single Piece Flow
  • University is only the first step!

As I’m sure you’ll agree, some of the topics could be controversial! Come along and see a hands on report.

Hope to see you there,
Neil

May Meeting: Software Craftsmanship

Bombe at Bletchley Park © Bletchley Park

Details

Date: Tuesday 31st May 2011.

Time: 7:15pm start to a 9:15pm (doors open at 6:30pm and close with the pub).

Location: http://www.pieandale.com

Theme: Software Craftsmanship Round-up

Software Craftsmanship

The analogy of software development as a medieval style craft will romanticise our profession but it also provides a keen set of principles that will ensure software produced today will be used and evolved well into the future. The movement has been popularised by the likes of Uncle Bob Martin, Corey Haines, and, particularly in the UK, Jason Gorman. It is Jason Gorman that organises the Software Craftsmanship conference at Bletchley Park which is the main European conference on software craftsmanship. The attendance is limited to around 120 participants and demand always outstrips supply. This year though Agile Staffordshire will be represented by 8 members –  4 of which also attended last year.

A call to action by Jason Gorman at the end of last year’s conference urged us all to go out and spread the word about high quality, well tested, communicative code in well designed and usable software. This, coupled with the upcoming conference and the release of Uncle Bob’s follow up to Clean Code: The Clean Coder: A Code of Conduct for Professional Programmers, means now is no better time to talk about software craftsmanship.

The Meeting

Software Craftsmanship 2011 is on Thursday 26th May and the plan for the Agile Staffordshire meeting the following week is to bring as much content and discussion as possible back up the M1 and across the A50 (and down the A34). This does mean that those involved will have to come up with something over the weekend so we don’t know yet what will be discussed. The programme for the day is available on the SC2011 web site so please take a look and let the group know what you’d like to know more about – some people already have which is great.

The format of SC2011 sessions are a mixture of programming, discussion and talks so we’ll probably have a mixture of topics at the meeting – bring a laptop as we’ll no doubt be writing some well crafted software.

I’ll not be organising this meeting from the end of this week as I’ll be on holiday. My able assistants Neil Kidd, Shaun Finglas and Paul Barrett are all on hand via the mailing list for any queries or suggestions.

March Meeting: Session Outcomes

March’s meeting themes were Designing an Agile University Course followed by a test driven development exercise.

Agile University Courses

Trevor Adams, from the Staffordshire University, presented the group with a short talk on the challenges of teaching agile based project planning and software development techniques. He covered the motivations for including content relevant to agile development and the problems faced when trying to incorporate this content in a course that has multiple aims. The conflicting forces that drive the content for university courses are:

  • Attracting students – this is why games specific courses have been more prevalent recently and Trevor pointed out that a course purely based on Agile development would be quite a niche choice and may not appeal to the mass of students
  • Industry – while companies such as Agile Staffs regulars iWeb and Codeweavers can see the benefit of agile development there are plenty of employers that require different skill sets. Trevor noted that concentrating on one particular area could disadvantage students as their skill sets would be less marketable on graduation.
  • Assessment – a university needs to ensure that students are learning new skills and that those that achieve a better understanding are compensated with an appropriate grading structure. Agile development requires a great deal of collaboration with things like pair programming and stand up meetings, so individual assessment can prove tricky. This, in particular, was the aspect that Trevor wished to explore more thoroughly and was the focus of a group work session he organised.

Facilitated by some well prepared worksheets we ended Trevor’s session with group work around the actual planning of a university module. We are invited to design the module through aspects of topic, format and assessment. Having to actually consider this in depth raised some important questions, some of which the people from industry hadn’t thought about. Deciding on an effective assessment technique was the most difficult part of the exercise.

The more favoured topic for each group’s course was TDD with some element of pair programming. This is thematic with the current trend in topics at Agile Staffordshire and seems important to members in terms of continuing the spread of TDD and learning techniques too.

Trevor said that while he saw it as important for the rest of us to see the challenges he faces as a course leader when designing modules with agile content he also wanted to take ideas away from the session. He promised to attempt some of the modules we’d planned and would present feedback at a later session. We look forward to hearing tales his triumph and stories of the new challenges he has faced.

iWeb also posted about this part of the session on their blog: http://www.iweb.co.uk/blog/2011/03/iweb-work-with-staffs-university-to-design-course/

Test Driven Development Exercise

As this was the first classic TDD exercise the group had attempted we started with a video from Corey Haines. Recorded at the Orlando Ruby User’s Group in 2009 this performance kata is designed to last around 15 minutes and be performed over and over again. This notion of deliberate practise is taken from martial arts but is also analogous with how musicians practise using scales. By repeating the same steps over time you can adapt and refine your technique within a simple isolated problem. You can experiment more than with production code as the kata code is discarded at the end of the process so you are free to make mistakes. It also affords the opportunity to try different design decisions.

While the Corey performed the kata in Ruby we were left to choose any language we wished. I saw PHP, C# and JavaScript being attempted and everyone made quite good progress with the problem. One set of pairs were using two laptops to view one set of code being developed, so that they could see how TDD helped the code to evolve. The PHP camp had some problems with the first, basic tests as the typing style of the language meant that the “null” and empty string of the C# most of us were used to couldn’t be used as a default. This mean we could not force the next change by coming up with a test – eventually we opted for the quickest route to green and returned an unexpected string rather than null- this meant the test went red so we could solve the problem, refactor, and get on with the next test.

We were reminded that the test driven cycle is Red – Green – Refactor and I was attempting to walk about enforcing this like the TDD police. Most people took on this pattern well though and I think everyone saw great benefit in how TDD was helping them develop this simple code.

Slides and Additional Content

As always, I prepared a few slides for this session which this time included some additional content. If we’d had time I would have covered some of the outcomes of a similar session I attended at XP Day last year. The motive for that session was to design a whole agile course, including a fourth year for MSc. I summarised the topics discussed for the 1st, 2nd and 3rd years, and those for the MSc extension. There is more information on the XP Day page.

Here are the slides: https://docs.google.com/present/view?id=dg7kxgdk_156c5bgg6hq

Retrospectives

At the February meeting we ended proceedings in a truly Agile manner by inspecting and adapting the way that the group and meetings were conducted through a Retrospective.

For those who found this useful and want to take this away and try it elsewhere then here is the format we used:

  • Give everyone some sticky notes, a pen and 5 minutes to consider the following two questions:
    • What have we done well?
    • What can we improve?
  • Invite everyone to write down as many points as they want, one per sticky note, that answer one of the two questions.
  • Place the two questions (or a 🙂 and 🙁 will suffice) as headings on a whiteboard, a wall, a chart, a table – anywhere that is visible and accessible
  • Invite everyone to stick their notes under the relevant heading.
  • Once everyone has had a fair chance (5 minutes) to stick their notes and think of any additional points then get everyone to sit down ready for the next step.
  • Group any related notes together to avoid duplication.
  • Invite everyone to take a pen and place a mark, dot, circle, tally or cross against the points they wish to talk about:
    • Each person gets 3 votes
    • They can vote for any of the notes, including their own
    • They can place their 3 votes on any note, with all 3 on one if they wish
    • Allow around 5 minutes for this activity
  • Once everyone has voted you should see an order to the points that people want to talk about – take the top 3 notes as the topics that will be discussed.
  • Spend the remainder of your timebox (we used 30mins but at Codeweavers we generally use 1 hours) discussing the 3 top points.
  • Appoint a chairperson to control the flow of conversation and to ensure everyone gets a fair chance to speak
  • Appoint a time keeper who ensure that the 15 minute timeboxes for each point are kept to – this isn’t strict but ensure the timebox is not abused.
  • Try to summarise discussion into actionable points – two or three per point should allow you to complete these actions before the next retrospective. Some things don’t have actions, just the discussion is enough.
  • When the timebox is up, the discussion comes to a close and no further points are discussed – if a point was not discussed this time, and it reoccurs for next time, it is likely that it will get discussed. Only points that the whole group deem important will be discussed so no one person will get to dictate the course of improvement.

Variations

  • If you find that you don’t have time for 3 points, try just 2, or try extended your timebox.
  • If you find you are not covering enough items then try taking the top 5 – be aware though, that your goal is to raise actionable points from the issues raised, so ensure you only cover what is likely to be actionable before the next meeting.
  • Don’t make the timebox too long as people lose concentration and other stakeholders think you are wasting time in meetings. Keeping the discussion focussed and producing action points mean that other stakeholders (managers etc) can see the results of the meeting, and if you follow up on the action points, they can see the improvements being made.
  • Give it a go, if it doesn’t work, have a retrospective retrospective – what went wrong, what can you improve, what went well? Change the format, ask on the google group for suggestions.

Tag Cloud