You are currently browsing the Agile Staffordshire posts tagged: agile


From Chaos to Kanban

There’s always a great atmosphere and discussion at Agile Staffordshire whenever we have a guest speaker. February did not disappoint. Craig Judson (Operations Manager at Codeweavers) presented Kanban in general and then elaborated on how Kanban is utilised specifically for continuous delivery of software.

Subsequently, a vibrant and energised discussion took place on working practices and project/product management. It was great to have such a varied mix of disciplines and roles present to contribute; consultants, developers, academics and managers. It was particularly interesting to note how various people were adapting well-known techniques to their work place and teams.

Thank you, Craig!

Craig Judson discussing Kanban and software delivery.

Craig Judson gave a presentation on Kanban and how it is used to deliver software at Codeweavers.

Also in February, Rosie Anderson and Rebecca Mycock stopped by to introduce Outsource. While Agile Staffordshire is primarily a group to share experience, expertise and good practice it is useful to network and learn about jobs, careers and opportunities in the Industry. I am sure that we will welcome them again at some point in the near future. Students may wish to pay attention to our blog for news concerning graduate recruitment (as well as all of the great professional experiences they can learn about). Thank you, Rosie and Rebecca!

Git Introduction January 2015

Paul Williams presenting Git.

Paul Williams gave a great introduction to the group on version control basics with Git

There was a great vibe this January; our first meeting of 2015. Paul Williams opened the year with a great session introducing Git. The session served as a useful introduction to those new to Git as a version control mechanism and incorporated rebasing techniques for those with intermediate skills. We experienced a wide spread of issues related to version control; what else would you expect with up to 20 people trying to do the initial commit? We also had a sneak peak how others are using Git in professional ventures. It was a great fun! Agile Staffordshire enjoyed an enthusiastic turnout; it was lovely to see everyone. Thank you, Paul.

The session provoked some good discussion and even set the scene for our first quarter topics. In March 2015, Agile Staffordshire will hold a session on Vi (the editor that appeared mercilessly upon commits) and more advanced Git techniques in April 2015. February’s session will focus on project management, with a specific discussion on Kanban in relation to software development. Keep watching our blog for upcoming events or join our meet-up group.

Group working at Agile Staffs January 2015

Ad-hoc team trying to commit to repositories in ad-hoc ways! What could go wrong? Not much really!

Enjoying Git session - January 2015.

It’s amazing how a bit of Git can make people smile.

I would like to add special thanks to Staffordshire University for hosting our event and providing wireless Internet connectivity throughout the session. Super stuff! Another special mention to Mel for taking photographs!

Open Data Institute Retrospective

Stuart Harrison, ruby developer for the ODI, introduced us to the ODI’s mission and how it facilitates ‘openness’.

I think for many Agile Staffordshire participants, including me, it was a great introduction to an organisation of which only the name may have been familiar. Stuart provided a spirited talk on the rationale for open data and shed some light on how open data has already gained some traction.

It is possible I am really late to the ‘open data game’, but I find the idea profound. I first encountered open data systems being realised during Brooklyn Beta 2013. Since then I have been interested in how applications can make use of available open data to overcome information hoarding. I think this is relevant to Agile Staffordshire, many of us being involved in software development for the web. How many great projects have stalled due to unavailable data; and particularly data that could really benefit society by being open, authoritative and reliable? Public information could be stored in several data stores, with no external access to the organisation responsible and with no arbitration or authority. Stuart explained the situation by way of a scenario involving an app designed to provide information on public transport.

The introduction to ODI provides Agile Staffordshire with a number of things to think about:

  • How can we become more open? Would it help attract more members if we were?
  • Could we make our projects open, inviting other interest groups to make use of the fruits of our labour?
  • Is there scope to making our event planning open? Again, some transparency may assist us with reaching more people in the local area.

Overall, for me the main message seems clear. Great software, great business and great people all seem to share one particular trait. They all create more value than they take. ODI embodies this principle and I think we are better off for their endeavours. Software that provides a great experience and service, but also provides opportunity for others to build on it and create value elsewhere is good for everyone.

Last month’s agile experience session with Craig Judson

Firstly, I’d like to thank Craig for an excellent October session on Codeweaver’s experiences with agile. It was our first session in a Staffordshire University lecture theatre so well done Craig for dealing with such an imposing stage, especially with the growing number of attendees 🙂

It was good to see this increase in newcomers and regulars – surely due to the combination of the interesting presentation, Cathy’s excellent work on publicising our group around the University and the Meetup.com site attracting newcomers.

Back to Craig’s talk (Development in an Agile Environment -slides) – he briefly covered the Chaos to Kanban era at Codeweavers which saw their development team and wider organisation transistion towards Lean service provision. Craig discussed their popular introduction to agile through Scrum, how using an agile coach (Kevin Rutherford) helped, and how agile means change to all stakeholders within an organisation. In particular, he introduced many to concepts like ‘work in progress’, ‘flow’, ‘feature switches’ and ‘SOLID principles’ which fuelled a healthy barrage of questions at the end.

9PM came too quickly, and the questions had to be interrupted temporarily while we walked / drove to  the Morris Man pub. On completion of the traditional ale purchasing, the questions and discussions continued for some time – another great Agile Staffs session.

 

 

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

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.

Welcome to the New Agile Staffordshire Web Site

Hello,

I’ve installed WordPress so that we can use it to record meetings and blog about any additional topics or resources. After a rocky start with some hosting issues it appears to be working well now. You should notice the Google Group information in the side bar and hopefully some posts should appear here soon.

Let Paul Shannon know via the Google Group if would like an account.

For group information check out the google group http://groups.google.com/group/agilestaffordshire/


Tag Cloud