Craft Conf is a two day conference in Budapest, aimed at talks surrounding the ‘Software as a craftsmanship’ idea. JWorks was present this year on the 10th and 11th of May and we would love to give you an overview of some of the talks we attended.

Table of Contents


Power Games for High-performance Team Culture, Psychological Safety, and EI - Richard Kasperowski

Richard Kasperowski Richard Kasperowski is a speaker, trainer, coach and author focused on high performance teams. Richard is the author of The Core Protocols: A Guide to Greatness. He leads clients in building great teams that get great results using the Core Protocols, Agile, and Open Space Technology.

During this talk, Richard provides an overview of some of the conditions that need to be met for the team to become a high performance team. In order for this to happen, it’s very important that companies realize that they need to focus on getting the right people together instead of focusing on achievements.

Hierarchy and power distance

A company needs to achieve the best possible team culture. But what does this mean?

What is culture?

The collective programming of the mind which distinguishes the members of one group or category of people from another. - Geert Hofstede

Richard talks about six different culture dimensions, researched by Geert Hofstede:

  • Power distance: Expresses the degree to which the less powerful members of a society accept and expect that power is distributed unequally.
  • Individualism versus collectivism: Individualism can be defined as a preference for a loosely-knit social framework in which individuals are expected to take care of only themselves and their immediate families. Collectivism, however, represents a preference for a tightly-knit social framework in which individuals can expect their relatives or members of a particular group to look after them in exchange for loyalty.
  • Masculinity versus femininity: The masculinity side of this dimension represents a preference in society for achievement, heroism, assertiveness and material rewards for success. This society is more competitive. Its opposite, femininity, stands for a preference for cooperation, modesty, caring for the weak and quality of life. This society is more consensus-oriented.
  • Uncertainty avoidance: This dimension expresses the degree to which the members of a society feel uncomfortable with uncertainty and ambiguity. The big issue here is how a society deals with the fact that the future can never be known: should we try to control the future or just let it happen?
  • Long term orientation: Every society has to maintain some links with its own past while dealing with the challenges of the present and the future. Societies who score low on this dimension prefer to maintain time-honoured traditions while viewing change within the society with suspicion. Those with a culture which scores high, on the other hand, take a more pragmatic approach: they encourage efforts in modern education as a way to prepare for the future.
  • Indulgence versus restraint: Indulgence stands for a society that allows enjoyment of basic and natural human drives related to enjoying life and having fun. Restraint stands for a society that suppresses enjoyment of needs and regulates it by means of strict social norms.

The talk further focuses specifically on the power distance dimension.

Power distance

Power distance entails hierarchy, the gaps between people in the company. A lot of power distance means a lot of hierarchy.

Next, we did some activities that let us experience hierarchy. The first one was with a partner of our choice where one of us was the ‘leader’ and the other was the mirror. Naturally, the mirror had to imitate everything the leader did.

For the next exercise one of the two persons was again the leader, but now the other person had to keep his or her nose at a distance of 10 centimeters from the palm of the hand of the leader at all times.

The last exercise was with a few volunteers from the audience where one person played the CEO, a few people played the Senior Vice Presidents and some people played the Vice Presidents. The CEO stood in the middle of the room and directed the SVPs, the SVPs directed the VPs. The people who were being directed were again said to keep their noses at a distance of 10 centimeters from the palm of the hand of the person that directed them.

These were very interesting activities that showed that having too much hierarchy and people who direct other people can lead to chaos when for example the leaders moved too fast for the others to be able to follow the directions. Directions are much easier to handle when there are less people involved and more trust is created.

What do we need to build a high performance team?

At the core, there are six building blocks for high performance teams:

  • Positive bias: Non-negativity, accept a positive mindset
  • Freedom: Every team member can choose and make decisions by themselves
  • Self awareness: Listen to yourself, use check-ins to discover, articulate and achieve what you want
  • Connection: Listen to others, connect great people into a great team and support each other towards a common goal
  • Productivity: Focus on results
  • Error handling: Ensure we are maintaining the positive bias, freedom, self-awareness, connection and productivity

Hierarchy and power culture erode high performance so when setting up and trying to maintain a high performance team, these building blocks are essential. To achieve high performance, increase the team’s emotional intelligence and psychological safety. This will decrease power distance and hierarchy. The Core Protocols are a way to reach this goal.

More info on the Core Protocols can be found here.

Perceived performance: The only kind that really matters - Eli Fitch

Eli Fitch Eli Fitch is a frontend developer with a passion for web performance, animation and all things 3D.

When talking about performance, we need to account for both objective time and subjective time. Usually, we tend to optimize for objective time by using tools like lazy loading. But how feasible is this?

Even a 20% increase in objective speed is unnoticeable to the user. So we have to aim for an increase of 30% or even more. Of course this is not easy at all, especially when taking into account that when working with multiple teams (possibly over different time zones), all the teams have to align on this.

So how do we get the user to perceive an increase of performance? We focus on the subjective time!

Active vs passive phase:

What does a passive phase entail? Our passive phase kicks in when we are waiting for something to happen, say for our water to boil. Time spent in passive phases feels ~36% slower!
There are two ways to prevent users from getting bored during a passive phase and keeping them interested enough to wait:

  • Keep users in an active state
  • Make passive states feel faster

How do we keep users in an active state?

There are three ways to achieve this:

  • Don’t tell users they’re waiting: Use loaders wisely because they can prematurely put users in a passive state
  • Respond to users immediately, even if nothing is happening
  • Keep users in flow with more responsive event listeners

To respond to the users immediately, we can implement an optimistic UI. 99% of requests succeed so why not take advantage of this by first updating the UI and only then doing the actual request.

We can also do our best to react as soon as the user signals intent. For example, why use the onclick event when the onmousedown event exists as it shows intent much earlier? This will provide you with a nice 100-150 millisecond head start. This is also usable on touch devices.

Using :active animations also buy you more time. An animation that lasts ~200 milliseconds will provide you with 50 milliseconds extra time keeping the user in an active state.

Onto topic two: how to ‘unsuck’ passive states.

A wait of 1-4 seconds is long enough to lose people’s interest. There are three ways of preventive loss of interest:

  • Use the right loading animation
  • Adapt the loading scheme to the user
  • Distract with shiny objects!

Uncertain waits feel longer so make sure to use progress bars and loading animations when appropriate. For example: bands with accelerating bars feel 12% faster!

What about spinners?

“Meh” - Eli Fitch

  • Less than ~1 second wait: Don’t indicate loading
  • More than ~2 second wait: Use progress bars!

Spinners are only useful between a 1 second and 2 second wait.

Don’t forget that most progress bars are fake! This is due to the connection differences between the user’s connection and the backend. However, we can use adaptive loading. Measure the actual requests done! You do need baseline times to know how long to expect it to run. Of course this needs to be normalized for the resource or payload that needs to load. Again, adapt the loading scheme to the user that is requesting data. For example, you can check the user’s connection to give him a personally optimized experience.

We can also learn a lot from game developers. Remember FIFA who made you play a mini football game while loading the game in the background?

Predictive preloading:

What if we could predict the user’s intent? One easy to setup option is to start loading the app and data in the background when a user has just started entering credentials in a login form. This quick win will give you a 4 second head start!

Another option is to exploit behavioural quirks:

  • People tend to watch hover animations: Fancy hovers buy you ± 600 millisecond extra time
  • People slow down when approaching the target: Load on mouse deceleration!

When combining above two techniques (hover animation + futurelink) we can get a ± 1.5 second head start. But: Use predictive preloading wisely! You will get it wrong some of the time. Do some dry runs first and try to mitigate risk by using metrics to improve.

A quick summary

  • Perceived performance is low hanging fruit since you can provide the user with immediate, accurate and live feedback
  • Tailor your loading solution to individual users
  • React as soon as users signal intent
  • Introduce predictive loading bit by bit, implement it at the places in your app where it has the most impact

At the end of the day, what matters is how it feels.

Eli also covers this talk on his website.

SWARMing: Scaling Without A Religious Methodology - Dan North

Dan North Dan North has been coaching, coding and consulting for over 25 years, with a focus on applying systems thinking and simple technology to solve complex business problems.

Business stakeholders, developers, infrastructure, the project management office and change groups don’t understand each other. What are they doing wrong?

They are aiming at the wrong target!

Wrong target: Cost accounting!

Large businesses tend to look only at costs and profits since they are too big to be able to keep an eye on everything in the organization. Local performance targets are viewed as extremely valuable, such as reducing head count or sticking to the budget.

Right target: Throughput accounting!

The whole business creates value. People in the organization are either directly creating value, or they are at least enabling others to do so. The business tries to identify and resolve bottlenecks. They care about lead time and throughput: How quickly from identifying a need can they meet that need and how much value can be pushed through the organization?

How can they reach the right target?

“Agile will save us!” - Everyone

The two people still waiting for Godot might help you with this one. Agile is no holy grail and people desperately holding on to the agile transformation will realize this soon enough.

Q: How do we always end up at, “Whatever we did was okay, but somehow it stopped working”?

A: Some things are just inevitable:

  • Degradation: things start to wear out because of time
  • Dysfunction: once things wear out, they stop working
  • Expiry: after they stop working, things start to decay and fall away

However, these also stimulate positive change: degradation stimulates the idea of maintaining things and transforming them. Dysfunction drives innovation and challenging things and expiry stimulates creating and starting over.

Why does this happen?

  • Change drives the need to adapt. If we’re not adapting, things are going to fail.
  • Interdependency drives the need to collaborate.
  • Imperfection drives the need to iterate.

Surprise, surprise: adaption, collaboration and iteration are the drivers of Agile and Lean methods!

What are our options?

SWARM!

Scaling Without A Religious Methodology

religion (n): The structures, constraints and rituals we humans accrete around a kernel of faith because we crave answers and we fear uncertainty. - Dan North

The table stakes are:

  • Education: we need to learn some new tricks.
  • Practice: it’s not enough to learn them, we also need to implement them (possibly with a few failures in the process and trying again and again).
  • Time: minimum 3-5 years to have an impact.
  • Investment: time costs money.
  • Influence: we need to reach up and down in the organization. Everybody needs to participate.
  • Communication: needs to be in the plan from the get-go or it will not work.
  • External help: both Amazon Prime and Netflix run on AWS. They don’t block each other, they learn from each other.
  • Leadership: needs to be consistent, they need to be invested and resilient.

If you don’t have these factors in place, SWARM won’t work.

These are based on simple principles:

  • People are basically good. “Everyone is trying to help”. Assume this is always true.
  • Sustainable flow of value is the goal. We need to learn new metrics and techniques.
  • Theory of Constraints: only tackle one constraint at a time.

Underlying principles:

  • Visualize -> stabilize -> optimize! You cannot change a system if you don’t know what that system looks like, so visualize! Use event storming, value stream mapping or whatever you need. Stabilizing means that even if the system is horribly bad, you want it to be consistently horribly bad because only then can you observe what impact your changes actually have.

  • Start small, get data.

“If we have data, let’s look at data. If all we have are opinions, let’s go with mine!” - Jim Barksdale

  • Learn from mistakes, iterate.

Summing it up

  • Don’t be fooled! It’s easy to believe that this time will be different.
  • You can’t defeat the universe. Mastery is understanding how to work with the grain. Don’t try to fight all the universal, inevitable things. That means adapting, iterating and combining techniques for your context and the changes around you.
  • There is no magic formula! But there definitely is hope.
  • This all takes education, time, practice and other things like investment and leadership.

Seven (plus/minus two) ways your brain screws you up - Joseph Pelrine & Jasmine Zahno

Joseph Pelrine Jasmine Zahno Joseph Pelrine is a senior certified Scrum Master Practitioner and Trainer as well as one of Europe’s leading experts on eXtreme Programming.

Jasmine Zahno is an agile coach who is passionate about the people side of product development. Her master’s degree in organisational psychology uniquely qualifies her to deal with the human issues that arise when the agile paradigm collides with traditional organisational structures.

Joseph and Jasmine talk about a few subjects that they found to be powerful in understanding the complexity of ourselves and software craftmanship.

The first of these subjects is that men find women who wear red to be more attractive. Men actually don’t realize this. A woman in red also triggers an exceptional reaction in other women. These women tend to react more aggressive towards women who wear red. Also, men who carry a guitar are found more attractive than men who carry a tennis racket.

The next part of the talk will cover some subjects about our psychology that are relevant to use in our field, but also just fun and interesting topics.

FACT: We use more than 10% of our brain. Even when we sleep, we use more.

Willpower?

Willpower is the ability to resist short-term temptation in order to meet long-term goals. Each day, we make 227 choices. These are all chances to follow your long-term goals. This has absolutely nothing to do with your intelligence and everything with willpower.

Willpower determines academic successes over intelligence.

Willpower deteriorates!

After multiple choices that required willpower, your willpower will start deteriorating and you will start making worse decisions. This is actually something that supermarkets use. The fruit and vegetables aisles are always presented to you first whilst you pass the sugary items right before checkout, when your willpower is at its lowest.

How to boost your and your team’s willpower?

  • Establish motivation - for example, align the action items in a retrospective to the team’s motivations
  • Focus on one goal at a time
  • Be authentic
  • Express your emotions - hiding your emotions deteriorates your willpower
  • Physical exercise - it will actually increase your willpower!
  • Eat regularly - for example, foresee fruit instead of Snickers to keep up the willpower since some will try very hard to not eat that Snickers bar
  • Mindfulness practices

Relative estimating =/= estimating!

Social compliance is very important to keep in mind during planning poker. Once the numbers are out there, it will influence the people who have not yet voted. See the example of the five subjects to say which drawn lines are the same length. Among these five people there is one actual test subject while the other four are deliberately giving the wrong answer. The test subject will actually adjust his answer to match the others’ answers even though it is clearly the wrong answer.

There are multiple factors that influence our estimations. Let’s discuss a few.

Seven plus/minus two

There’s actually a limit on our capacity to process information. This means that the number of objects an average human can hold in working memory is 7 ± 2. This is frequently referred to as Miller’s law. It has nothing at all to do with memory. It has everything to do with the way we make decisions.

Linguistic priming

The way the Product Owner formulates the story has a big impact on how it is estimated. Let’s say for example that two cars had an accident. The following five words that were used in the experiment gave a different result:

  • Collided
  • Bumped
  • Contacted
  • Hit
  • Smashed

The question here is which word would give the highest estimate of speed? The answer is the following, where 1 represents the highest estimate and 5 the lowest:

  • Collided - 2
  • Bumped - 3
  • Contacted - 5
  • Hit - 4
  • Smashed - 1

We are not as good with numbers as we think we are

  • We tend to ignore the base rate: If, for example, the yellow taxis take up 80% of all the taxis in Budapest and the red ones take up 20%, when we see 10 yellow taxis pass by we will assume that the next one will be red even though the actual chance is still 20%.
  • The law of small numbers: We tend to believe small numbers more than large numbers because it’s easier for us to process
  • We overlook the statistics when a story is involved because we tend to be more emotional than analytical

Joseph and Jasmine also refer to the Monty Hall problem:

Suppose you’re on a game show, and you’re given the choice of three doors: Behind one door is a car; behind the others, goats. You pick a door, say No. 1, and the host, who knows what’s behind the doors, opens another door, say No. 3, which has a goat. He then says to you, “Do you want to pick door No. 2?” Is it to your advantage to switch your choice?

The answer here is actually ‘Yes!’, however counter intuitive that may be.

We are not good psychologists

The Dunning-Kruger effect: The less intelligent a student was, the smarter they thought they actually were. Reduced intelligence leads to a reduction in the ability to self-reflect on their own intelligence.

Working in teams

We have the tendency to overemphasize personal characteristics and ignore situational factors when judging others’ behaviour.

  • When we are late, it’s because we have a good excuse
  • When a team member is late, he was probably just lazy

IKEA effect

We have the tendency to overvalue the things we build ourselves. One example here is using pancake mix. These mixes didn’t sell properly until people were actually required to add their own set of eggs to the mix.

To finish, Joseph and Jasmine showed us and discussed some more interesting research papers about the human psychology. Their talk is available on the Craft Conf website.

Designing a high-performing team - Alison Coward

Alison Coward Alison Coward is the founder of Bracket and author of “A Pocket Guide to Effective Workshops”. She is a strategist, trainer and workshop facilitator. With over 15 years of experience of working in, leading and facilitating creative teams, Alison is passionate about finding the perfect balance between creativity and productivity.

Team work today is cross-functional and self-organizing. AirBnB for example has core teams and expand the team with the necessary expertise from within the organization when necessary.

A team is made up of multiple individuals which creates a new team culture when putting these teams together. The team’s dynamics also tend to change on different projects. So we cannot apply a preset way of working to a new team or a familiar team working on a new project.

Three principles for creating High Performance Teams

  1. Can your team learn to work better together? With a fixed mindset you believe that talent is fixed. However, with a growth mindset, you believe that anyone can improve with practice and persistence. See the value of continuous learning. These teams were more successful in the past and tend to perform much better. They challenge each other and learn together. Don’t forget that this can actually be developed. Each team has the potential to improve.
  2. What new ways of working can you create together? Apply a design approach and a design mindset. Design a way of working that works for that team!
  3. How will you and your team start to work differently? Behaviour change and building new team habits. What team habits, what rituals can we create to help our teams work better together?

Two factors for designing effective teams

Communication & trust.

How you work together is more important than what you’re working on and who you are working with.

MIT Human Dynamics Lab

The research conducted by the lab concluded the following: The most effective teams

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

Google’s project Aristotle

A few years ago, Google was very interested in finding out what the factors were that made up the most effective teams. They concluded the following:

  • The people could see the impact of the work they were doing
  • Meaning of work, they could see why they were doing the work
  • Structure and clarity, everybody knew who was doing what and what they were working on
  • Dependability, they knew they could depend on each other
  • Psychological safety, the individuals in the team were able to make mistakes and take risks in front of each other

It had nothing to do with IQ and individual talents of the people in the team and everything to do with how they worked together.

Self-awareness

95% of us think we are self-aware, while actually only 10-15% is!

Self-awareness exercise:

  • What time do you naturally wake up?
  • When are your most productive hours?
  • When do you get your best ideas?
  • What does your ideal work day look like?

We can use these answers to set up new ways of working within the team.

We can do this during the project kickoff:

  1. Share team expertise, share what your role is and what you can bring to the table
  2. Clarify the roles, everyone needs to know who can do what work
  3. Talk about how you will work together, how you will meet, when you will meet, how to communicate, etc.

Organize better meetings and workshops

Make your meetings count!

  • What is the purpose of the meeting?
  • What is the best format of the meeting? How long do we need? Do we need to split up the meeting?
  • Set meeting rhythms

Amazon’s two pizza teams:

If a team is too large to be fed by two pizza’s, then the team is just too large.

Google Ventures Anxiety Parties

Every three or four months they would get together with a list of all the things that were bothering them about their performance and would share that with their team. An example of this might be that they weren’t sure if they were spending too much time going to conferences or if they’re working too slow. They would share these concerns during the anxiety party and the team members could respond whether they felt this actually was an issue or not to them. Someone could then find out that what they saw as an issue wasn’t being considered an issue at all by the rest of the team, or perhaps even vice versa. These conversations build trust and better connections within the team.

Take inspiration from workshops

Great workshops have the following in common:

  • Collaboration
  • Creativity
  • Equal contribution
  • Good content
  • Clarity (on what needs to be done)
  • Motivation

The next paperclip exercise shows you how to make your meetings more effective: The first question Alison asked us was, ‘Come up with as many ideas as possible on what you can do with a paperclip.’ This question was followed with, ‘Which idea would make a good business proposition?’

Two different activities came up during this exercise:

  • Divergent thinking: Trying to come up with as many ideas as possible, the focus was on the quantity.
  • Convergent thinking: Applying criteria to your ideas and being critical.

It’s very important to keep these two activities separate during your meetings. Our goal is to have productive conflict and constructive discussions. Watch out for group thinking by making sure everybody gets heard, introverts and extroverts alike. Equal contributions are very important!

Don’t forget about check-in rounds! Use the first five minutes of a meeting to ask a personal question to encourage equal contributions and build trust in the team.

Team habits

How do you change behaviour?

  • Start small! One step at a time works best instead of a big bang!
  • “Implementation intention”: Make a plan!

When you have these team habits in place, it still needs a constant review to keep improving. We need the following loop:

Design -> Test -> Iterate -> Repeat

Starting a new High Performance Team

  • Determine how you meet
  • Determine how you share ideas and how you can learn from each other
  • Social times, find ways to get to know each other
  • Alone time, don’t only think about collaboration

Summary

  • Team work is changing
  • Having a growth mindset, design approach and behaviour change
  • Make your meetings count
  • Build a ‘workshop culture’
  • Create better team habits

More information on how to run effective workshops can be found here.

Estimates or NoEstimates: Let’s explore the possibilities - Woody Zuill

Woody Zuill Woody Zuill has been programming for 30+ years and works as an Agile Coach and Application Development Manager. He and his team are the originators of the Mob Programming approach to teamwork in software development and he is considered one of the founders of the “#NoEstimates” discussion.

The first part of Woody’s talk is about his own personal experiences. He was involved in a project that included over 200 developers. He concluded that the same ‘lesson learned’ kept popping up after each iteration: ‘Our estimates need to be better!’ It was always the same lesson learned, there was never any improvement. Woody calls this the ‘Cycle of Continuous No-Improvement’.

How does one get out of this cycle? Is it safe to question the status quo?

There is a bigger idea behind these questions:

“The object isn’t to make art, it’s to be in that wonderful state which makes art inevitable.” - Robert Henri If you set up the environment for good things, then good things will happen.

Woody’s suggestion was very simple:

How about working with no estimates?

The tweet that started it all in 2012:

#NoEstimates Tweet

What is an estimate?

Working definition: An estimate is a guess of the amount of time (usually work time) to create a project, a feature or some bit of work in developing software.

We use estimates to help us make decisions and spark a conversation (to ultimately make a decision).

Afraid of change

Why is it that we want control and certainty over time, cost and schedule? We don’t need help to make decisions, we need help to make good decisions. Are estimates then really the only way to make them? Are we even able to draw the right conclusions? Perhaps ‘on time’ and ‘on budget’ are actually not a good measure of the results of our decision if we had to cut in our feature to be able to deliver?

But why hold on to estimates?

“Fear of losing control is a big barrier for change.” - Bjarte Bogsnes

We tend to hold on to what we know. A few quotes in favor of breaking the cycle:

“Alternative to estimates: do the most important thing until either it ships or it is no longer the most important thing.” - Kent Beck

“As teams progress they first struggle with estimation, then can get quite good at it, and then reach a point where they often don’t need it.” - Martin Fowler

When starting a project, requirements are handed over to the development teams in an orderly fashion, very neatly organized and containing everything that needs to happen. Or so the stakeholders like to think. The project itself, however, usually ends up being a lot more disorganized with features being added, removed or changed with no way to tell early on what the end result will look like. Then why try to get estimates for the project if most of the requirements tend to change anyway?

“It’s in the doing of the work that we discover the work that we must do.” - Woody Zuill

Rather than size and smallness, look for the following qualities in a story:

  • Potentially valuable
  • Understandable
  • Cohesive - does it belong together
  • Distinct - is it clearly separate from other stories -> These don’t require estimates! When these qualities are found, we have something we can work on.

The Twelve Calculations example

  • 80% of the use of the app comes from 20% of the features
  • 80% of the use of a feature comes from 20% of its implementation

This means that with only 4% of the implementation effort (20% of 20%), we can cover the 20% of the features being actively used.

Let’s try to have many, small, inexpensive attempts at value. Let’s do, discover, validate and steer. This is what being agile is all about!

What do you think would have more payoff? Turning up the goods on getting our estimates better? Or turning up the goods on our ability to rapidly deliver potentially useful software?

Let’s learn to control our urge to control things. Let’s quit worrying about whether we will get done in three months for now. Let’s get good at being done everyday.

On Woody’s website, you can find more info on his take on estimates.

Interested in more?

As we were not able to attend all the talks at CraftConf, we only covered the ones we’ve attended in the blogpost above! Hope you find this blog post as interesting as we did the conference!

If you’re interested in more details; all the talks were recorded and can be found on the CraftConf website.

Thanks for reading, everyone!

Craft Conf

Derya is a Scrum Master at Ordina Belgium always trying to better herself in Agile frameworks. She enjoys being challenged and as the Competence Leader Agile, she tries to improve her own skills continuously, while hoping to share her knowledge and help others with their understanding of Agile frameworks.

Nils is a Senior Software Engineer at Ordina Belgium. Passionate about frontend frameworks. Scrum master-in-training.