Blog

Running The Perth Code Dojo

Shortly after moving to Perth I decided to set up a local Code Dojo. It is a great way to improve as a programmer, learn, share with others and be part of a community (which gives you a warm fuzzy feeling).

Previously I had been a member of the London Code Dojo and had ran dojos as a way of training TDD and programming practices for clients. In this post I will share my experiences in attending code dojos and some tips on how to run your own.

Code Dojos are targeted at professional programmers and college / university graduates. This is unlike the ‘CoderDojo’ initiatives, which have gained in popularity and aims to teach youngsters to code. It is great to see this development on the concept being used by a non-profit group set up to help the next generation. This is certainly something I have enjoyed participating in with my own daughter.

Definition of a Code Dojo

A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there to have fun and to engage in Deliberate Practice in order to improve their skills.

What Have I Personally Got Out of Attending Dojos?

I like seeing the way others approach a problem. Pairing up with new; like-minded developers and seeing how they work. At the different Code Dojos I attended I gained exposure to different programming languages and tool sets. Often participants are more than happy to show people their ways of working share tips from their domain. As a professional programmer you can refine your skills and get a chance to mentor others.

You can practice the katas used in Code Dojos on your own, but I recommend finding your local Dojo (or starting one) and getting involved.

The Perth Dojo

The Perth Code Dojo was started in 2014 and focused on software craftsmanship and XP practises (TDD, Pairing and a little bit of refactoring). The process of setting up the dojo was fairly straight forward, although it does take some time commitment and put me out of my comfort zone a couple of times, which in itself was a form of deliberate practise. I had to promote and seek sponsorship and learn to speak as an authority on programming practises in-front of a crowd of strangers (most of whom where decent programmers). I gained some great experience in logistics for running events, speaking in public, group facilitation and got to know some of the best developers in town, as well as improve my own programming skills – what’s not to like!

Some Tips Running a Code Dojo

Safey

As the facilitator of a dojo you must foster a safe environment so people feel comfortable to ask questions and reach out for help. Make it clear that the purpose of the dojo is to provide a place to learn away from the usual business pressures of delivery. When sharing code amongst the group be watchful of people being too critical, especially if it is not constructive, and applaud and appreciate everyone’s attempt at solving a problem. Remember we were all new to programming once and any good programmer will always have an open mind and a lot to learn. No one likes a know it all!

If need be, take individuals aside and ask them to be a bit more forgiving and concentrate more on helping others in the correct manner.

The Host

You do need to have a good understanding of TDD and general programming practise. But you do not need to be the best programmer in the room to host a successful dojo. I found it a great way to improve my own skills by facilitating and taking part.

I recommend you do the kata yourself beforehand, so you can experience the challenge and provide people with guidance. By doing the kata in your own time you can also push yourself a little further as you are not time constrained. This means you can try out new languages or techniques. You also have more time for research and reviewing your own approach with what others may have done online.

Do Not Assume Peoples Skill Set

Skilled programmers often do not like admitting they are stuck or do not understand something. I recommend being a little obtrusive at times, ask to see peoples code and especially unit tests; if practicing TDD. I have found that sometimes the most vocal members of a dojo might be missing a crucial point and this can lead them to not gaining as much as they otherwise would from the exercise. A vocal person such as this can also lead their pairing partner down the wrong path and instil the wrong types of practices. Do not be afraid to challenge people in the right way. The key is being respectful and making sure your intention comes across correctly – you are there to help and not criticise.

Walk the Room

A good way to do this is to visit each pair shortly after the kata has begun and ask to see their tests. Ask questions such as;

Did you write your test first? – Programmers who are not used to TDD can find writing the test first very difficult and jump straight into the code

Is that the simplest test you can write? – Learning to break down the problem is crucial to good TDD flow. People may need guidance.

Is that test too simple? What is verifying? – Often even programmers with a good understanding of TDD can find themselves writing tests that verify a null is returned. I have been guilty of this myself in the past, but it is not a good starter test as it doesn’t actually verify anything apart from a method exists with the name you have chosen.

There Are Plenty of Katas Out There

You do not have to reinvent the wheel when running our own dojo. It can be nice to dream up your own katas and also give back new ideas to the community but there are plenty of pre-existing out there that you choose from. This keeps the down complexity as an organiser.

Some great resources include:

Dave Thomas’s Code Kata Website – codekata.com

TDD Kata by Garora on Github – github.com/garora/TDD-Katas

John Jagger’s Cyber Dojo is another a great source of Kata and a pretty interesting tool in itself – cyber-dojo.org

SleepyFox’s collection of London Dojo examples on Github – github.com/sleepyfox

Deal with Anti-Social Issues

Sexism, racism, homophobia and bullying are all toxic to any the learning environment. Nip anything like this in the bud immediately. I recommend encouraging wider participation of different demographics, as having people from a variety of backgrounds creates the right atmosphere for learning. An alpha male sausage sizzle is not conducive to great learning. Encourage people to get to know each other and swap pairs.

The Format

For the Perth Codo Dojo I took the format used at the London Code Dojo and SleepyFox kindly assisted me with some advice on setting up. The details are below;

  • Give people 15 minutes to arrive, grab a drink and say hello to their fellow code crafts people
  • Begin with a round robin asking people to introduce themselves as an ice-breaker. An interesting fact about themselves or something they got up to at the weekend. This is crucial as it helps the other members to get to know each other and by having individuals speaking early on encourages participation – much the same as it does with any workshop or retrospective.
  • Start with a brief intro explaining the concept of the dojo and the format for new arrivals and as a reminder to old hands. Explain the rules and ask people to be respectful of everyone’s commitment to learn and turn their phones to silent.
  • Provide an introduction to the chosen kata then ask people to pair up. Give them 15 minutes to discuss and set up their environment: Language of choice, IDE, test framework, etc. If there is an odd number than a group of three is fine.
  • Use the Pomodoro technique, with 25 minutes focused time on the kata and 5 minutes down time – I find this works great for paired programming and not just Codo Katas. Generally, three Pomodoros is a nice time to spend on a kata before people begin to lose interest or you might find some people finish simple challenges. Ideally you want the challenge to remain unfinished for all; they can always finish or polish it after.
  • Leave time at the end for a mini retro and sharing exercise. Ask pairs to volunteer and hook up their machine to a big screen to run through their approach. People are often willing to share and this discussion at the end is very valuable for socialising learning amongst the group.
  • Get some pizza – if you have some sponsorship. Sharing food is another great way to encourage a group atmosphere where learning is encouraged. And people like pizza. Plus, it is a convenient food to eat when trying to work.
  • Prize – a nice touch if sponsorship permits. Doesn’t have to be anything super expensive

Checklist for the Venue

  • A big screen or projector to present the format, kata and sharing code at the end
  • Plenty of desk space for people to pair with adequate power points for laptops
  • A sign on the door and directions so people can find you!

Links to GitHub / slides

My code examples can be found on GitHub

The slides can be found on SpeakerDeck and are re-usable under Creative Commons

Thanks to @sleepyfox and our sponsors – Kiandra ITAjilonRobert Walters and Spacecubed

Losing your way with scaling

I was working with a very Agile experienced business unit recently, they were having some issues with “momentum” in building a new product offering.

Within the business unit, there were 5 teams working on the minimum viable product offering, and 2 teams working on other products. The teams had all participated in incepting the work, and by all accounts it was a successful inception. Each team consisted of established team members, who together were high-performing and agile knowledgeable. There was one product backlog where features were defined. Each team was capable of delivering all the way to production. All the elements for success, it seemed was there.

They were tackling a brand new build, new technology and 5 teams all working on the same product. They launched into their sprints full of energy and enthusiasm. However, after several sprints, no business value was delivered, and their enthusiasm was replaced by stress.

Continue reading “Losing your way with scaling”

Delivering Agile 101 Training at Curtin University

Friends reached out for some training for a few people in their teams at Curtin University, they were initially looking at about maybe six people. Fast forward a month and we had delivered three runs of our “Agile 101 with a Focus on Scrum” course for just short of 60 people across Technology, Marketing and People & Culture. Wow, what fun we had!!

Continue reading “Delivering Agile 101 Training at Curtin University”

Experiences on the Organisation & Relationship Systems Coaching (ORSC) Intelligence Course

Last week I attended the ORSC Intelligence course in Singapore, the second in the ORSC™ series. This blog is about my experiences which I found very valuable for Agile Coaches and Scrum Masters working with change in Organisations and Teams.

IMG_5680.jpg

This was the awesome group of coaches I got to work with lead by our awesome facilitators David Darst and Abi Shilon.

Continue reading “Experiences on the Organisation & Relationship Systems Coaching (ORSC) Intelligence Course”

Delivering Goal Orientated Scope

shutterstock_62162533-300x225

Abstract

My last blog was focused on what I learnt about the Scaled Agile Framework (SAFe). The theme quote for that blog was:

“If you’ve lost the ability to do small things then you’ve not scaled, you’ve just gotten big and slow!!!”

So what are the small things we should do well at the team level or at scale? Breaking the work up, avoiding big batches, and letting the work flow was one of the recommendations.

This blog will focus on the integration of techniques to deliver goal-orientated scope (that breaks up the work) and take a look at how you might start to visualise and manage the flow at the portfolio level.

Continue reading “Delivering Goal Orientated Scope”

Scaling Agile using the Scaled Agile Framework (SAFe)

Scaled Agile Framework (SAFe) Agile Release Train (ART)

“If you’ve lost the ability to do small things then you’ve not scaled, you’ve just gotten big and slow!!!”

Abstract

The Scaled Agile Framework (SAFe) has become a hot discussion topic in the agile community as a solution to scaling agile in the enterprise. Amongst the options available to scale agile, SAFe appears to be leading the pack as the popular choice for consideration and implementation. The framework has got its critics and some prominent respected people in the agile community have spoken out against it. With everything you read you have to consider motivations beyond the narrative to evaluate how impartial a critique actually might be. I decided I needed an education in SAFe to develop an informed opinion on the advantages and disadvantages of the framework and when it might make sense to use it. Last week I flew to Melbourne to undergo the SAFe Program Consultant (SPC) certification training. This blog gives an account of what I learned (the good, the bad and the ugly), the opinions I have formed and what recommendations I would make.

Continue reading “Scaling Agile using the Scaled Agile Framework (SAFe)”