Eventyr

Simply Buy Tickets

Ticket sales are properly launched for the upcoming Brighton Coding Dojo night which will be held at the Creativity Zone at Sussex on 10th May as part of the Brighton Fringe Festival. Tickets are £3/£2 and the night includes a full buffet (making it a real bargain). 

Public, students and professional programmers are all welcome (although some knowledge of programming constructs is preferred).

Come and join us, and tell your friends.

Coding Dojo 11

The eleventh Code Dojo (my, this is starting to look well established!) was on 26th March at the FP Offices.  We continued Kata Four (Data Munging) in Java - looking at the second part of the Kata. 

It was good to have some new people attending (PiersCawley, GrahamCarlyle and MakotoInoue) and they helped instigate a lot of interesting conversation at this session about ways to address problems, Test-Driven Development, Up-Front problem discussion (as opposed to solving), refactoring, the limitations of Java, and applications of Agile. 

I almost wish I had taken notes. 

(Thankfully the session was recorded so I can just watch the video again at another time should I choose.)

As Dom puts it: "I learned an enormous amount from the interaction this evening. [...] Chatting  afterwards made me realise how I tend to be very focussed on solving the problem at hand rather than stepping back and trying to create something beautiful."

Revisiting Agile Fun

Ran another Agile Fun session for the folks at FP at the Pitcher and Piano - this time on office space. 

It was interesting to see what people came out with as the main features of an office to be developed.  I wasn't convinced by the idea of a giant fax machine in the middle of the office that would get in everyone's way, but that was what the customer requested.

I think a different venue to the Pitcher and Piano may need to be found.  The table, and table service, is spot on but the noise levels can be problematic - and would cause problems for me explaining some concepts to novices.

More photos here.

---

I have since received my packs of XP Playing Cards in the post, which I hope to put into practice soon.

Agile Certification

While it might be nice that an employee has been trained in an agile practice, or has read books, nothing beats the experience gained by working on a team and learning for yourself. making mistakes, enjoying successes, and facing both with equanimity and humility.

Jon Kern on the Agile Alliance's position on Agile Certification

QCon - Post Conference Info

Post conference Info:

QCon wiki

QCon slides
QCon Flickr Pool

Key Takeaway Points and Lessons Learned from QCon 2007 - summary article based on blog posts about QCon, nice to be quoted.

Retrospective Loss

Very sad to have missed a workshop on Retrospective techniques being run by Diana Larsen and Rachel Davies - Had place, had train ticket, had directions, had to be ill all night.  Such is the way.

Sad to have been so ill I ended up in bed for two days - also missing XtC and an XPDay meeting.

QCon - Friday

It being my birthday I only stayed at QCon for the morning.  This was a shame in a way as this day had some of the most interesting talks of the three days.  It also ended up being one of my busiest as a student helper (although I did not get the chance to use the video camera again).

I got to run about and help with the Open Space Sessions being run by Diana Larsen - but sadly had no time to attend.  I got to see some very interesting talks from Joseph Pelrine and Dave Thomas (although given the numbers of people I ended up sat on the floor!).

I also had a 'twitter moment' - as I was asked what my twitter id was just as the lift doors closed on my way out back to Brighton.  I never had the chance to answer but I did get the chance to twitter it. Such is life.

---

Notes from talks (hoping I have them right now):

Joseph Pelrine:

• (Sad to miss most of this talk - given he had props.)
• Every time you put a team together they will organise in a different way.
• Sensemaking involves Observation, Interpretations and Conclusion.
• People may not even be playing the same game, let alone speaking the same language.
• If you are doing Agile by the book you are not doing Agile.
• Humans don't like to deal with rules - they don't do best fit but first fit pattern matching followed by some subconscious post-rationalising.
• Process, Protocols, Ritual and Ceremonies can be both a reflection of culture and a buffer to human interaction.

---

Dave Thomas:

• Novice - Needs to know when they are done.  Experts  use different language, they use metaphor and story.   Using Drefus Model to look at programmers.
• You cannot treat people uniformly, different people have different needs.  There is no such thing as a 6-pack of developers.

Poppendieck Video

Competing On The Basis Of Speed:  Google Tech Talks December 15, 2006:

Companies that compete on the basis of speed create a huge competitive advantage. But going fast is not easy. Speed requires a precise understanding of value: who, what, when, where, how, and why people will love your product. And it means getting value to them without complexity creeping into either your product or your process.

Complexity comes in three basic flavors: 1. Inconsistency - Anything that is uneven, unbalanced, or irregular. 2. Overload - Any excessive or unreasonable burden. 3. Waste - Anything that unnecessarily takes up time, effort, space, or money.

All three flavors of complexity are rampant in software development processes, and you can't go fast until you root them out.

....

See also 12 Questions with Mary Poppendieck

QCon - Thursday

User Stories - Rachel Davies

Philosophy, stories and lifecycle of agile covered as an introductory session.

Agile aims to satisfy the customer - this does not mean that it is somehow cheaper or needs less developers.

Rachel made a very interesting point that traditional requirements documents are based on the traditional model of knowledge transfer - a model which was exemplified in teaching with lectures where the expert can pass knowledge directly to a student (who will then retain it).  The view is that knowledge can be poured out, captured, recorded and then delivered on to other people without a loss.  This view has changed, with increasing education activities focussing on reflection, group activity and tacit knowledge.  The same change could be seen in the shift from requirements capture to user stories. 

User stories are a way to work with other people, and to encourage communication.  If you haven't had a conversation about the contents of the cards then something has gone wrong - they are promises for discussions.

The Ron Jeffries three C's:
Card - Facilitate
Conversation - Discuss using agreed language
Confirmation - Acceptance Test

Traditional Form:
"As a <User Role> I need <Capability> so that <Business Benefit>"

It also helps when the story has a name.

Development Cycle:
Exploration -> Release Planning -> Iterations to Release -> Production

Create a roadmap of deployable releases - all iterations should be deployable but it may not be possible in the business case that it can be deployed each time.

Each iteration has the stories and features planned - generally estimated in story points.  There is normally more detail in the plan for the closer iterations.  At the end of each you review and refine the plan, adjusting and adding detail accordingly.  However the release dates are always fixed.

Generally in an initial planning meeting the business sponsor will present the case, allowing the development team to ask questions.  The development team can then go on to have a more detailed technical conversation.

Business people and developers must work together - and welcome changing requirements.

---

Steve Freeman - Test Driven Development

The motivation for the talk was to encourage people to go away and try it out.

So, why use TDD? - arguably because you end up with half the defects but similar productivity.  It helps to give the confidence to get the job done, and you don't need to worry so much about side-effects.

"    Write a test
"    Make it pass
"    Refactor

Tests are best named after what they will do for us and not the methods that they are testing.

Never stray far from the green bar.  This ensures steady continual progress (real not illusory), focussing on one thing at a time.   It also encourages neat, clean simple code and modular design.

Listen to the tests, analysis effort can be put into tests.  Refactoring supports design aspect by removing duplication and helping to express intent.

Code is more reliable, needs less debugging - and shorter!

Encourages test-driven management.

---

Boris Gloger - Heartbeat Retrospectives to Amplify Team Effectiveness

The idea of a retrospective is to tell a tale - the history of the team or a project.

Why retrospectives? We would like to improve what we have done in the past.

Disappointment of expectations stops learning.  Retrospectives need to occur after events to encourage learning.

6 step process
- security first
- collect facts
- ask: what went well?
- ask: what could be improved?
- who is in control?
- Prioritise activities

Security first: Prime directive - everyone has done the best job they can given their knowledge of the situation at the time.  What happened was the only thing that could have happened.

Collect Facts: Create shared team history or story.  Each person writes important event on post-it and adds to timeline on the wall, while briefly talking about it.  Only tell about your own story when you put it up, but once it is up there it becomes a team event and part of the team story.

What went well? (Creates positivity)

What could be improved?  (no manager enforcement, all ideas come from the team)

Who is in control? (who can make this happen?  The team?  The organisation?)

Prioritise activities: Create team backlog and impediment backlog.  The latter is hard, but important to make visible.  Important but hard to do and takes bravery.

Heartbeat retrospective can last 10 to 90 minutes. Use a dedicated room, not a project room, preferably in a secure environment that is not the team work area.

Some say project retrospectives should take at least 3 days - these are longer, more details as they cover a longer project in its entire history.  They also try to create solutions.  Heartbeat retrospectives are more designed for iterations.

Make conflicts visible, don't try to hide them.  However, safety is built over time as the team is built.  Hard to deal with highly charged situations in such a short time frame.  Talk about things on wall and not about each others.

By telling the story you get the information.

---

At this stage in the day the internet came back, however so did people in my room.  The talks that followed had up to 140 people and required more attention from me.  I even got to briefly work the video camera.

Am now in greatly enjoying the Martin Fowler / Dan North keynote, so had best go back to listening and stop typing.  I will have a lot of videos to watch when they go up on the qcon website.

QCon - Wednesday

Once I got past the security scanners at QCon I immediately found myself in my role as a student helper. 

Here a student helper role involves: helping with directing people, attending two meetings a day, manning the registration desk, counting heads in rooms and collecting feedback.  Mostly that means a lot of free time to attend the sessions you are interested in, and a host of free items (as well as free attendance at what would otherwise be a very expensive conference).  The exhibitor area was rife with flyers, pens, stress balls and notepads advertising some very nice companies (I am easily convinced by free toys). 

As I was not so interested in the talks I helped out on the registration desk (fending off the people from other conferences who wanted our conference bags for free) used the lovely wireless facilities, had a pleasant telephone interview for some business training, bought a replacement train ticket then headed back down to Brighton for 6pm eager to return the next day.

My photos are up on flickr here.