Craft Conf 2018 Recap~ 15 min.

The Craft Conf took place in the beautiful city of Budapest on the 10th and 11th of May. I was very happy when I got the email that I was granted a diversity ticket for the CraftConf, otherwise it would have been impossible for me to take part in this awesome conference.

I arrived a day before the conference and made the best out of the time by walking around Budapest and doing some sightseeing. 14km later with hurting feet and after sweating in the heat, I was in love with the city.

The conference is really huge. Almost 2000 participants traveled to Budapest from 38 countries – how cool is that!? The topics were all very different and it was very hard to choose between the tracks, but have a look at the talks that I visited and the sketchnotes I‘ve made about them:

What the fuss about serverless

Simon Wardley
Simon started with talking about what a strategy should look like. Basically he followed the Strategy Cycle from Sun Tzu. It consists of a purpose, a landscape, a climate, a doctrine and leadership. He continued by talking about the situational awareness you have to keep in mind – like who are you talking to and what might be the best way to present things. Maps can really help you to visualise it in the context. The main parts of maps are the anchor, the position and the movements. Then he talked about patterns – there are 30 different business patterns and you have to keep in mind that characteristics change. As serverless is on its way, DevOps might be the new legacy. Also Simon thinks that there is no choice over serverless and that it is just a question of time, but you will use it. In short you have to learn from what happens and challenge your assumptions. Think about efficiency, speed and worth and focus on the user‘s needs. Think small and use the appropriate methods. Try new things and build things with smaller components. Think about and monitor capital flow. There is nothing magical about serverless.

Power games for high-performance team culture

Richard Kasperowski
Hierarchy and power distance destroy high-performance organisations – that was Richard‘s first statement. Culture is the collective programming of mind and culture dimensions are:

• Power distance
• Individualism
• Masculinity
• Long term orientation
• Uncertainty avoidance
• Indulgence

Power distance is about the gaps in organisations or groups of people – you might be dominant or subordinant. Then there were some games in which we as talk attendees first had to mirror one another with a partner and then perform a one hand hynosis, where one had to put his hand in front of the other‘s nose and that one had to keep his nose 10cm from the hand, even during movement. How to move towards high-performance? Think about positive bias (non-negativity, no negation, pretend), freedom (pass, core commitments, check out), self-awareness (ask for help, personal alignment, check in) and connection (check in, ask for help, investigate, intention check). In short: use core protocols, do activities to explore power distance and increase team emotional intelligence.

Testers can write good code too

Corina Pip
Once testers got into the mood of writing code, they love doing it. Their mindset is needed to create test scenarios, but a developer‘s mindset is needed to write the code for it. What we want from test code is:

• Not being just a sequence of assertions
• Should follow coding standards
• Being easy to read
• Being easy to maintain
• Being beautiful
• Have repeatable results

Before writing code you should make sure that the requirements are clear, spend time on identifying the best solution and then write, draw and visualise. According to the lazy principle devs want to write as little code as possible and write efficient code. Use existing libraries for that. QA should be included in code reviews and such code reviews should be a part of the definition of done. Refactoring is allowed if you have a more optimal solution. If your environment is to be blamed for test failures – repair it instead of writing workaround code. There should be separate tests for production and development – at best two separate code projects. Keep up with your framework, learn constantly and find good sources of information. Some other tips are:

• Use proper naming
• Reuse code, don‘t copy/paste
• Mind try/catches
• Use lists for similar items
• Don‘t sleep, wait

Stress and depression – the dangers of a burnout

Gitte Klitgaard
Gitte, who herself has suffered from a burnout, was talking about stress that can lead to depression and burnout. Nowadays we don‘t take some time to do nothing, as we live in a performance culture. We rather close our eyes than talking about stress and depression, instead of listen to our body and change something – at least go see a doctor/professional about it. There are always more things to do than we can manage, but you have to rest every now and then and take time to get better. More info can be found in my sketchnote.

The well-rounded architect

Patrick Kua
An architect is a role, that even might not exist as such in a team or consist of multiple devs, but not all devs can play this role. All architecture is design, but not all design is architecture. Architecture is about significant design decisions that shape the system. The architect decides on the architecture and he nurtures it. The elements of good architects are:

• Leadership skills (shepherds everyone in same direction)
• Being a good developer
• Be systems focused (deployments, monitoring, fixes, constant change)
• Have entrepeneur thinking (cost/benefits, do experiments)
• Have strategic technologist‘s thinking (languages, tools, frameworks, techniques)
• Being a communicator (vocabulary fitting to team members, inwards and outwards)

There is no right shape for being a well-rounded architect, but there is a minimum to be an effective one. Everybody has his own strenghts. A journey could be:

1. Just starting
2. Improving
3. Capable
4. Well-known
5. Industry leader

SWARMing: scaling without a religious methodology

Dan North
People ask Dan to help them. When he talks about how they use the wrong methods and explains the difference between cost accounting and throughput accounting (more info in sketchnote), they tend to say, that agile will save them. Some time passes and they discover that agile didn‘t save them and that the thing they tried was working ok, and then it stopped working. As time passes, some things are inevitable. There is degradation which stimulates maintaining and transforming, dysfunction that stimulates innovating and challenging and expiry that stimulates creating and starting over. This happens because there is change that drives the need to adapt, interdependency that drives the need to collaborate and imperfection that drives the need to iterate. Packaged methods don‘t last because they can‘t pass due to time that passes. Therefore there are some table stakes that are necessary, but not sufficient:

1. Education (learn new tricks)
2. Practice (implement things)
3. Time (3-5 years)
4. Investment (time costs money)
5. Influence (not just in one team, but whole org)
6. Communications (different people, messages, formats)
7. External help (ask people who have experience)
8. Leadership (consistent, invested, resilient)

Keep in mind some simple principles:

• People are basically good (everyone tries to help)
• Sustainable flow of value is the goal (learn metrics, techniques)
• Theory of constraints: one constraint at a time

Start small and get data, learn from mistakes, iterate, don‘t be foole, you can‘t defeat the universe, mastery is working with the grain, there is no magic formula, but there is hope.

Five key challenges for software quality tomorrow

Gojko Adzic
Think about who is using our products. Now there are loads of algorithms instead of humans. How to deal with them if they sometimes act faster than humans can!? What are our products doing? In times of big data and machine learning the machines get better in some things than humans. But they also do some mistakes. AI/machine learning makes it hard to assert correctness. Where is the risk in our products? It shifts from units to integration. Don‘t trust third party data as everything is connected to each other. When do risky things happen? They shift from before deployment to after deployment. How do users interact with us? They move away from keyboards and screens. Now there are things like voice devices and internet of things. Do all those changes mean, that the testing pyramid has to be turned? You need to chsnge from prediciting things to monitoring. You need approval instead of verification and maybe there are new things coming like machine-guided exploratory testing.

Five XP practices for agile development

David Bernstein
Scrum teams tend to break down if they don‘t do technical practices. So David spoke about 5 practices that could help.
1. Integrate continuously
This is very valuable and powerful. You get feedback at a high level and continuous integration is the heartbeat of every project. Things can be done (they run), done done (they run and are integrated) and done done done (they run, are integrated and refactored). Build things to be releasable to create continuous deployability. Automate the build and integrate early and often.
2. Collaborate
It is crucial to work together with your team. Communication is key to that. To start you can try to pair programm, use buddy programming or even do some mob programming. Time box the unknowns and do code reviews and retrospectives. Amplify learning – be mentoring and mentored.
3. Create CLEAN code
Cohesive, loosely coupled, encapsulated, assertive and non-redundant code is important. Let the code qualities guide you.
4. Write the test first
Start with thinking what can go right, then go over to problems. Good tests are unique and provide rapid feedback. They should be units of behaviour rather than units of code.
5. Refactor legacy code
Think about if things are an investment or a debt. Pay technical debt off fast. Before creating new features, clean up the older ones. Refactor to accommodate change. Do it right the second time.

7 (+/- 2) ways your brain screws you up

Jasmine Zahno & Joseph Pelrine
Willpower is the ability to resist short-term temptation to meet long-term goals. You have about 227 times per day to show that ability, because that is the number of decisions people do on average. Determine academic performance over intelligence. Willpower predicts good adjustment, interpersonal success and wealth.

How to boost your willpower?

• Establish motivation
• Focus on one goal at the time
• Be authentic and express your emotions
• Physical exercise
• Eat regularly
• Mindfulness practices

We often have to make decisions. But keep in mind that we are being manipulated all the time. Estimating is also something we do very often. Relative estimating means comparing things to each other. An estimate is a range, not a number. Keep in mind that words can influence your estimation. Also there are limits on the capacity of processing information. The magical number is 7 +/- 2. Language does create reality. People are not as good with numbers as they think:

• Ignore the base-rate
• Law of small numbers
• Overestimate likelihood of rare events
• Overlooking statistics when story is involved

When we work in teams we assume that the other one is like us, which isn‘t true. Also we overemphasize personal characteristics and ignore situational factors when judging about others. We overevaluate things that we do ourselves. People believe things more if they start with „studies say…“.

Designing a high-performance team

Alison Coward
How do you do your best work? And how to bring your team members together so that they can do great work together? Teamwork is changing. Teams consist of members with diverse expertise, they are fluid/dynamic, teams are autonomous and self-organised. Individuals have their own skills, knowledge and expertise. Therefore teambuilding is very important. Ask if your team can learn to work together (growth mindset, continuous improvement). Collaboration is a skill. What new ways of working can you create together? How will you and your team start to work differently (behaviour change, team habits). Communication and trust are the factors of effective teams. The how is more important than what you are working on or who you are working with. Most effective teams…

• Communicate frequently
• Talk and listen in equal measure
• Engage in frequent informal communication
• Have dynamic conversations

Start with you as an individual and build up some self-awareness. People work very differently. Therefore you should bring your knowledge about the team members on how to work best together during the project kickoff. Share your expertise, talk about how you‘ll work together and clarify the roles. Better meetings and workshops have a purpose, have the best formats for them and follow a meeting rhythm. Take your inspiration from the workshops (equal contributions, collaboration, clarity, good content, motivation and creativity). But don‘t forget to balance individual work and collaboration. Have some time to be alone, to socialise and think about how to meet and to share ideas. Team habits should start small, be planned and constantly reviewed.

Simplifying the stack

Matt Aimonetti
Always try to follow the KISS principle: keep it simple stupid. Most systems work best if they are kept simple, so this should be the goal in design. Simple is when there is no simpler solution. The reader should get the code right away without any surprises. But watch out: simple doesn‘t mean easy. Simple is the architecural flexibility gold. But simple is really hard, can be determined objectively and it pays off. Make simplicity a value by talking about it and by repeating the value of simple code. Setup a process for simplicity: build a culture around it, do audits of your code, mob/pair program, test and review your code, do a code complexity analysis and use an RFC template. Afterwards you have to celebrate – be proud and give it a value.

Estimates or no estimates: let‘s explore the possibilities

Woody Zuill
The problem withprojects is, that the estimates often are off, requirements aren‘t clear upon the start and the requirements keep changing. If this happens over and over again, you are in a cycle of continuous no-improvements. People say that an estimate is a guess about the time or size of something for the planning in software development. The problem is, that our requirements don‘t tell us all we need to know. Estimates help us to make decisions – good decisions. How to make sure that they really help us with that and how to get from where we are to wonderful? We are afraid of losing control and are sometimes forced to do estimates. But does everything really need an estimate or should we rather focus on the value of things we build? Most of the things that matter can‘t be measured. 80% of the use of an app comes from 20% of the features. And 80% of the use of the features comes from 20% of it‘s implementation. Discover the real value and turn up the good. Good things will happen if you put up an environment in which good things are allowed to happen.

The most important things I‘ve learned about good design

Mark Miller

1. Emphasis and importance: emphasis should always match the importance of things
2. Contrast and readability: things need to be easy to read, sufficient contrast on perceived brightness spectrum
3. Proximity and layout: physical proximity should match contextual proximity
4. Borders and spacing: borders should be thin (not more than 1.5x a space) or low contrast
5. Fill and corners: buttons should be filled, corners should be round
6. Information dimension: contextually related information should be shown in parallel
7. Discoverability: due to this the customers learn how to use the interface
8. Gradient backgrounds: they distort the perception of color
9. Polarity: prefer to use black text on white screens

Experiments: the good, the bad, and the beautiful

Linda Rising
Going agile mostly isn‘t a scientific decision as there are no studies about if agile is better than other methods. We hear a lot of good stories which are more intersting/fun than data. People say „aren‘t we experimenting“? But no, actually they are „trying“, because there is:

• No clear hypothesis
• No randomization
• No control group
• No analysis

Also A/B tests aren‘t scientific, as they don‘t build up to a theory or a real learning and the results are context-sensitive and can‘t be applied elsewhere. Often you try to „prove“ something, but one try doesn‘t prove anything and you have to validate things in different environments. Science is a method, not content. Often even scientists are biased (placebo effect). What we can do, is:

• Small, simple, fast, frugal trials
• Change things (context, number of participants,…)
• Try again

You can get rid of the notion of failure by using „learning“ instead. Think about making things even smaller and even cheaper. Begin with an end in mind (time box). Often we do trials to „show people“, but data isn‘t convincing (backfire effect). Involve other people in your trials – probe, sense and respond. Trials don‘t solve problems as there might be undesirable outcomes. Uncover ideas for more trials instead of looking for THE answer. Be prepared to be surprised. Simply test things and you kill the hippos (highest paid person‘s opinions). But be aware that correlation isn‘t causation! Create a culture of experimenting and learning. Be open to changes and to try new things. Take little steps and learn after each one.

As you can see the topics of the Craft Conf are very diverse and those are just the talks that I chose, there were 5 times that many talks. I can say that the quality of the talks that I attended was really high and all of them were amazing. Also I have to mention that, although I didn‘t make a sketchnote about it, I attended the keynote held by Damian Conway, which was just hilarious. You should absolutely watch the recording of it – no sketchnote can capture it.

I hope you like the recap and my sketchnotes and hopefully you get something out of it. Feel free to share your opinion and tell me, if you need a sketchnote in a higher resolution.