CodeMash 2014

CodeMash 2014 is winding down and as usual the conference was a blast! Lots of greats talks, lots of fun activities, and last but not least good time to be had in the waterpark! Outside of the talks they had activities such as lock picking, jam sessions, early morning 5K run, astronomy, 3D printing, game rooms, open spaces, lightning talks, kids fun at KidsMash, a StarTrek simulator, various parties, bacon bar, and on and on. This was my 4th year attending the conference and it is without a doubt my favorite developer conference. Hats off to the organizers!

This year I was fortunate enough to not only deliver one, but two talks at the conference. On Thursday I gave a talk on Web Service testing and Friday I did one on Kanban. The first talk went sort of ok.  I was very nervous, felt I stuttered too much through the material and didn't feel very sharp in my thoughts, so I didn't feel super good afterwards. I had a talk with Leon Gersing in the evening and he gave me some great pointers on delivering presentations and dealing with nerves. I went ahead and rehearsed my second talk several times in the evening and then delivered it the following morning and felt way more relaxed, sharp in my thoughts and quite enjoyed giving the talk. So thanks, Leon, for the tips! Now I am waiting for my family to join me at Kalahari, so we can hit the waterpark tonight and tomorrow.

The slide decks from my talks are available on Slideshare:

and

The slides have also been uploaded to the conference GitHub.

Presentation - Kanban Case Study

Here are slides on a Kanban Case Study that I presented at agileLUNCHBOX today.  I basically recapped my experience using Kanban at Hugsmiðjan (maker of Eplica CMS), and showed how our Kanban board evolved over time.  I went over basic Kanban theory and covered a few advanced topics like associated metrics.  I also talked about how we integrated Kanban and Scrum.  The talk was well received and afterwards we had some good agile discussions.  

Agile Tips from Remote Seminar with Henrik Kniberg

Last week Agile netið organized a remote seminar with Henrik Kniberg, award-winning keynote speaker and author of multiple Agile and Lean books.  The seminar was held at the Grand Hotel in Reykjavík, where around 10 Icelandic Agile enthusiasts gathered to remote connect to Henrik via Skype and Google Hangout.  We listened to Henrik talk about lessons learned at one of his recent projects and then had a long Q&A session, where we got to ask him all sorts of Agile and Lean related questions.  Despite an initial technical hiccup with poor sound quality the event was very enjoyable and informative.  Here are some of my take-aways. Basically random tips from the discussions that I found useful.

• If you need to explain to someone the benefits of limiting work in progress when running Kanban, use a traffic jam analogy: When there are not that many cars on a given highway, everything runs smoothly and we have a lot of cars running through the highway. But as we add more cars on the highway, basically everything starts slowing down to a jam and we have fewer and fewer cars that are able to drive the highway to the end.  The same thing happens in Kanban if we don't put WIP limits on our queues. Starting more tasks actually causes us to end up finishing fewer.

• If you ever need to sell to management the need to pay off a technical debt and refactor some legacy code: print out the longest class, tape the pages together and bring it with you to a meeting!  When you show up with a 5 meter long paper strip, showing some monstrosity of a class, people have an easier time visualizing the problem.
• When running a Scrum team, think about establishing a rule that each team member that completes a user story needs to ask the team if he can help out with a story that is already in progress before he is allowed to start work on a new one.  That encourages cooperation and limits work in progress, increasing the likelihood that we have fully completed stories at the end of the sprint, as opposed to stories that are partially done.  If our sprint backlog is 10 stories we would much rather have 8 fully completed stories at the end of the sprint than 6 completed stories and 4 partially done.
• According to Henrik, research has shown that incorporating QA into your agile development teams (testing continuously) saves on overall time spent in testing and bug fixing.  Meaning that if you test and bug fix as part of each sprint, as opposed to doing a large round of testing at the end of the project followed by a lot of bug fixes, you save time.  One reason for this is that when it comes time to fix a bug the code is still fresh in the developer's mind.  Also the continuous QA feedback encourages developers to deliver higher quality code.  This is visualized in the following illustration from Henrik's slides:

• Size doesn't matter.  According to Henrik having the team categorize user stories into small, medium and large before implementation is not very useful.  At the end of his project he calculated actual times spent on user stories and found out that it actually took about the same time on average to implement a story that had been categorized as small as it took to implement a story that had been categorized as medium.
• When you are on a large project that comprises multiple teams, try doing finger voting to assess the overall confidence that the project will get delivered on time.   Basically, in weekly meetings ask team leads to hold up fingers on one hand representing their confidence that their team will get the required work done on time.  Where 5 fingers mean "definitely", 4 fingers mean "likely", 3 fingers "it's a gray line", two fingers "probably not" and one finger means "no way".  Track this on a weekly basis.  If you get few fingers in the air, you know you have a problem that needs to be addressed.
• Try to make your development teams cross functional.  Each team should comprise all the skills required to fully deliver a feature (e.g. graphics designer, front-end developer, back-end developer, DBA, tester).  If a resource is needed at least 50% of the time put him on the team.  Make sure everyone has a home team, even though they might be outsourced to other teams from time to time.
• To check the health of a Scrum team use the Scrum check-list.

Kanban with David Anderson

This week I enjoyed attending a two day Kanban training class by David Anderson, the Father of Kanban-style software development.  The class provided an overview of Kanban and offered many tips on how to get the most out of Kanban.  David rolled through a deck of some 150 slides and answered various questions.  On the practical side, the class was divided into four teams and each team had to design a Kanban board for an actual company and then play an entertaining Kanban game, which turned out to be quite competitive.  The team I was on, Grand Kanban :) managed to squeeze out a slim victory with around $62,000 in revenue, which according to David was a pretty good score ;-)

Few points from the class:

The Kanban Method is based on three core principles:

•    Start with what you do now
•    Agree to pursue incremental evolutionary change
•    Initially, respect current processes, roles, responsibilities & job titles

The five keys to a successful Kanban implementation are:

•    Visualize Workflow
•    Limit Work-in-Progress
•    Manage Flow
•    Make Process Policies Explicit
•    Improve Collaboratively (using models & scientific method)

Key class takeaways according to Dave were:

• Kanban is like water 
• It goes around obstacles and slowly changes them, rather than removing them like a bulldozer
• Change has to come from within
• How many experts does it take to change an organization?  Answer: One.  But people are going to have to want to change

Surprising fact from the class:

According to a research done by David, getting more done only ranks number 4 on most manager's lists!  The list of their preference being:

1. Predictability
2. Business Agility (ability to respond to changes in market)
3. Good Governments (managing budgets, money spent the way intended, etc.)
4. Getting more done

Playing the Kanban game

All in all a good class and I look forward to continuing the improvement of Kanban at Hugsmiðjan where we develop the Eplica CMS.