Notes from Agile Portugal 2016

Last time I attended Agile Portugal was 2 years ago for the 2014's edition. The leap couldn't be bigger. The number of attendants and the quality of the talks showed how the adoption of Agile methodologies is growing and maturing. I have to congratulate the organisation for this amazing event and hope to attend it again next year (hopefully again in Porto).

Some of my notes and thoughts from the first days talks. (Unfortunately I was unable to attend the second day of the conference)

As a professional programmer, how do I learn new skills? by Emily Bache

Emily presented Coding Dojos as a medium for programmers to learn new skills.

Coding Dojos are based on martial arts dojos where a master teaches his students by repeating a series of Katas (movement patterns performed solo or in pairs). In the case of a Coding Dojo, a Kata is just an exercise - usual a concise programming challenge - design to practice a given skill.

With an experience of some years facilitating and promoting these Dojos, Emily showed some tricks that will certainly make Coding Dojos more interesting.

Create some constraints on the tools you use:

• Only use the keyboard to promote learning keyboard shortcuts on the IDE of your choice;
• Use Plain Text Editors to promote independence from auto complete and improving memorisation of your language APIs.

Create some constraints on the Design level:

• Really small methods (2 lines max)
• No conditionals
• No loops

Create some social constraints:

• Collective green deadline - all tests must be passing in x minutes;
• Ping-Pong Pair Programming
  Pairs can't talk with each other. 
  On a Dojo to practice TDD have one person only writing tests and another writing the code. You can really push for TDD skills if the person writing the code does it in such a way that it is only writing the minimum code necessary for the tests to pass forcing the person writing the tests to be more creative.

One example of a skill that many developers have an interest learning about but fail to arrange time for it is TDD. There are a lot of screencasts online you can use as guide if you don't have a "master" in the skill you're promoting that can facilitate these sessions.

Having some experience with Testing Dojos, I'll definitely help promote Coding Dojos in Blip as something that can help developer improve or learning a new skill and that can improve the sense of community and engagement.

Agile Gamification in an enterprise SAAS by Pedro Castro Henriques

I have a long time interest in Game Design. This was my field of research in the University and led me to co-found a video-game company shortly after I left University. Since then I follow discussion of Gamification in the workplace or in schools and I don't miss a talk about this subject and it was with increased interest that I saw Gamification applied to Agile Development.

Pedro presented how Strongstep implemented Gamification features on Scraim, a Project Management SaaS solution. Users of this solution will get points for following best practices and completing actions like filling out information on Work Items, closing them, etc. You can configure what process you follow (Scrum, Waterfall and a few others) and the rewards you get for each task and daily challenges for your users and then you wait for the competitive spirit to improve engagement and commitment.

Being in a company with 20-something teams following different variants of Scrum, ScrumAnd, ScrumBut, Scrumban, Kanban and any other flavour known and unknown and trying different experiments - NoEstimates, Work Items with no tasks, etc - I'm fully aware that one size doesn't fit all. My concern with Gamification in this context is that it may promote consistency across teams which is not necessarily a good thing.

Please share in the comments any good or bad experience with Gamification in the Comments.

Sociocracy 3.0 by James Priest

Sociocracy is governance system that advocates the distribution of leadership and decision-making throughout the organisation. As James put it: "Let the people close to the  work decide how to do it."

The seven principles of Sociocracy 3.0 are:

1. Consent Decisions are made only in the absence of reasoned objection from those affected by them. 
2. Effectiveness Devote time only to that which brings you closer to achieving your objectives.
3. Equivalence Everyone affected by a decision has the power to contribute towards the formulation of decisions and to withdraw consent on the basis of reasoned objection.
4. Transparency All information is accessible to anyone in an organization. Confidentiality requires consent.
5. Empiricism Build knowledge on experience and constantly re-evaluated that which is believed to be known on the basis of new experience.
6. Continuous Improvement Evolution is more effective than revolution (most of the time).
7. Accountability The process of entering and keeping agreements, and managing expectations in any relationship. Note: with equivalence and consent in organisations, people are naturally more accountable.

Another great quote that resonate with me:

Make decisions that are good enough for now and safe enough to try.

I have been seeing decisions taking too long to take to make sure it's the perfect decision when we really should be adopting a Lean mentality to it that this quote embodies.

I won't expand very much about this for now since I haven't taken time to assimilate the full extent of this system but you can learn more about Sociocracy in their official website and the official handbook. 

Other resources about self-managed organisations: (not related to Sociocracy but can also be of interest)

• The Future of Work podcast episode How to Go From Fear-Driven to Freedom-Centric Organisations
• Ted talk by Ricardo Semler, How to Run a Company With (Almost) No Rules
• Hidden Brain's interview with Google's Chief People Officer, Laszlo Bock

TDD for people - jointly designing change in our team by Douglas Squirrel

Douglas has a very good metaphor by applying the TDD mantra "red/green/refactor" to how we should "climb" the Ladder of Inference.

To make sure you climb every step of the ladder when agreeing with someone to take action.

You start by making an observation on data and evidence and evaluate the response from your counterpart. If she agrees with you you are in green status and you can climb one step of the ladder. If she doesn't you are red and you have to refactor your statement evaluating again the status. Like with TDD you should go back and forth until you are green so you can move forward. When you are at the top you and your counterpart should agree easily on action to take because you have a common understanding of the problem. Of course that we can't always reach the top and sometimes you just have to give up.

I love this model and I'm set to experiment it whenever I have the chance but I'll find it hard to have the peace of mind and the ease of just going through all these steps. I have no doubt it's helpful it's just that it should be really hard to do this in the beginning.

A nice collection of resources on the Ladder of Inference and other Action Science concepts can be found here.

Daily meetings - more than just standing up and sharing by Marco António Silva

Marco shared some techniques for improving Stand Up meetings that I found really useful.

One of the techniques mentioned by Marco is really popular in Blip right now: going through the user user stories and sharing the updates on each user story rather than going through each team member. 

But what jumped to my eyes was a simple question: why ask only three questions? Marco was referring to the usual three questions people usually answer in the stand ups: what have I done yesterday?, what I will do today? and what are my blockers? If your team has set goals for it why not ask during the stand up what have you done to attain the team's goal. And why do we have to ask what have we done yesterday? We are not there to report anything to anyone so any piece of work that has been completed should be already reflected in the board.

This really made me think that we should question the basic stuff that everyone considers good practices and that are common practice everywhere.

Onboarding with Scrum by Rona Steinrücken and Jeff Campbell

Rona and Jeff described Rona's onboarding process on Meltwater and all the small steps they took to improve the process for the company.

The key moment of this talk for me was not the onboarding process they described or any of the improvements they had put into practice but a small two minute break they introduced by the end of the presentation for the attendees to discuss take-aways with people next to you. Being there with two colleague we were able to quickly discuss Blip's onboarding process and generate ideas to improve it.

It amazed me how it never occurred to me until that very moment to apply such a basic concept that should be in the heart of every Agile practitioner. I often attend conferences with colleagues and it never crossed my mind to do a short retrospective after each talk. Something I'll try to put into practice on the next conference.

Please share in the comments your highlights of the conference or share any experience you have with any of these subjects.