Venue/Host: Trifork Amsterdam
Costs: Free of charge
Speaker: Gitte Klitgaard
Food & refreshments included
18:00 Registration & Food
18:30 Short Intro
18:35 Gitte Klitgaard
19:30 Short break
19:45 Lightning talks by You (be brave!)
20:45 Ending with beers
• • •
"You have to be brave in order to change the world!" by Gitte Klitgaard
You have to be brave in order to change the world! This holds true professionally and personally. “So what does this have to do with me” you might think; “I just want to do my job – not change the world.” At work we face challenges all the time that require courage; from asking for help to quitting your job; from admitting a mistake to saying that you did something good. Being brave and vulnerable is necessary. Standing by who you are, having the courage to be different, making yourself vulnerable, speaking up when there is something important to you, sharing your fears and joys requires courage. Courage is individual and there is no such thing as a little courage. Being brave is not about removing fear or not being afraid – it is about doing what is necessary even when you are afraid.
I live this personally; I have to be brave (even have a tattoo with it). And it is a big learning I try to pass on to the people, I coach. In my session I will talk about why I have to be brave and vulnerable, give examples of how I am courageous, and why being brave is a big part of my work life.
Gitte Klitgaard is an agile coach, hugger, friend, and much more. She lives and loves agile. She took the oath of non-allegiance. Why fight over methods when we can use that energy to help people?
Gitte wants to change the world by helping people make the right product, doing it right and very important: have fun doing it.
She has a great interest in how people function, how the brain works, what motivates us, how we can feel better about our selves, how to be perfect in all our imperfections. She is a geek and passionate about a lot. :)
Twitter: @nativewired (https://twitter.com/NativeWired)
• • •
"Lightning talks" by You (be brave!)
Herding cats is about the new way we collaborate within day to day teams and across the whole hierarchy.
We would like to hear your experiences how you tackle the problems but also how you make it fun to work together. This evening we have a couple of slots for short talks (approx. 10 minutes) for you to talk.
We got response from four great speakers. Here is where they will talk about:
"Trust(ing) Teams" by Marjan Venema
Using BRAVING to assess and grow your self-trust.
When you find yourself unwilling to make yourself vulnerable to the words and actions of someone else, I am willing to bet a lot that they acted in ways that eroded your trust for them.
Brené Brown's Anatomy of Trust's BRAVING acronym helps you figure out what that was so you can talk to them about it without entering a mine field. It also helps you assess how trustworthy you behave towards others, and, far more importantly, how trustworthy you are towards yourself.
In this short talk I will explain the BRAVING acronym and talk about how I used it to grow my self-trust.
"How to prevent bad architecture decisions?" by Wilco Koorn
Software architectures are often found to be sub-optimal and many developers complain about choices made. To improve decisions regarding software architectures we recently learned that these decisions are mainly the result of human communication. Software architects, communicators by nature, are influenced by people in their context as well as by their past experience. In this communication process we find a well known psychological phenomenon known as "cognitive bias". It is well known in psychology but not in IT..... There are many of these biasses and they all have a negative impact on the quality of software architectural decisions!In this talk we will introduce "cognitive bias" and show how we may improve our decision making process regarding software architectures.
"Secure performance while developing software in an Agile environment" by Michael Kok
Performance is usually excluded from the Definition of Done. There are several reasons why. First of all performance testing based on load and stress testing is expensive and complicated. It needs scripting by specialists, a production like test environment and much management attention. As a consequence the feedback loop takes so much time that it does not fit in the Agile scheme. Hence it is quite normal to deliver the code and performance test it at a later stage. Then if the test is not positive it is difficult to go back and optimize the code. More than once a complete redesign must be done that ruins the time to market of the project.
Predictive analysis techniques allow for performance testing on a different paradigm, enabling Devs to do it themselves. The feedback cycle is shorter than 10 minutes and code is delivered with guaranteed performance the first time. Such an approach neatly fits in Agile development, is applicable in small software shops and may even change the world a bit. In this talk Michael will show you some views on the matter.
"Tailoring the methodology according to the project" by Andreja Dulovic
Term “Agile” has been so abused and misunderstood in the software industry that it practically lost its original meaning. I think everyone knows about some real life examples where this area of software development is misunderstood and good ideas are misinterpreted. That is why I become extra careful whenever I hear a dogmatic approach to any process.
Being a good PM requires both technical and social awareness, it is not a job of delegating tasks and demanding solutions. PM should create a process that benefits everyone. Sometimes (depending on the participants) the solutions are counter-intuitive and require working out of the well-known paradigms, or combining them.
To keep things going well, a PM needs to remember two basic parts of their work: 1) to maintain the conditions in which the team members can deliver, 2) constantly manage stakeholder's expectations. It only works in an environment of honesty and integrity.