Looking for inspiration on how to gain a shared insight in the current state of your team? And curious how to find actions for your team to improve? Read below about the ‘thermometer session’, a workshop that we designed to improve our own business unit. The goal of these sessions is to get an insight in the current & desired state of the unit. In other words: how does the team feel currently about the unit and how do they think it should be. Based on these insights we take action to further improve our unit, which results in a happier working environment for everybody.
We as humans make numerous decisions every day without even realising it. Even when making decisions which have a relative big impact on our lives, we often do this rather irrationally. How else for example could it be that a majority of people under-save for retirement? This is not based on a careful evaluation of cost and benefit.
So you see, even when it comes down to economic decisions-making, we see that this is most often based on something other than rational thinking. Our decisions are often susceptible to systematic biases in which our brain responds to impulses and external triggers in a predictably irrational manner.
Insights drawn from fundamental research in behavioural science make it possible to influence human behaviour and to be able to make predictions in how humans will respond to certain triggers. As a UX Designer, Marketeer or entrepreneur you are looking for ways to apply principles that influence customers and which lead to significant measurable results.
To which triggers does our human brain respond and in which way? How can we steer human behaviour and how can we apply design principles? These and other questions were answered, during the hands-on workshop at the Multichannel Conference Utrecht on April 19th 2018, by Eva Hörner and Harm Jan Luth, both UX Lead at Xebia.
Introducing the SPACEMAP! A 'map' to gain insight into motivational problems within an organization/department, so that coaches and managers no longer have to talk about vague motivation problems, but instead tackling the lack of autonomy within the teams.
The map consists of generic 'work factors' that are required to create a motivational environment.
I remember when the Product Owner stepped into our room with a new user story. He asked if we could make a minor change to one of our web pages. What he did not know is that nobody understood the code, nor the ancient documentation that was written for this webpage. After running a few tests we even discovered that half of the features did not even work. We made a proposition: we implement this user story if we get three extra weeks to rebuild this page and rewrite the documentation. Luckily our awesome Product Owner understood our situation and we managed to get these extra weeks.
I was 21. I just graduated from MBO college, it was night and I was strolling around town with a couple of friends. We just celebrated our graduation and did not want to go home. After a few hours, we got lost and arrived at this big haunted mansion. We saw a sleek figure standing at the entrance. He was looking directly at us, and asked: “Would you like a tour?”, inviting us in. For a second we looked at each other and then we succumbed to our curiosity, following the man into the mansion. With no idea what could happen next.
Throughout my life, I have done several stupid things like the example above. And I knew these were not my brightest moments, but my curiosity simply took over. I wanted to explore or discover something (and I also love to get a good story out of it).
But whether you love taking risks and doing stupid things, or you prefer to dive into books and study in a safe zone, we all have the same internal drive to learn, to grow and to become the best version of ourselves. This is called ‘mastery’ and it is the subject of this blog post.
What are we doing? Why are we implementing this sorry excuse of a user story? What will this user story achieve in the bigger picture? Is there even a bigger picture?
I have attended several refinements as a coach, where I was waiting for those questions to arise... Unfortunately, they are rarely asked. Usually, because there is no easy answer to these questions. The difficult truth is that we all like to please others, so we would rather stick our heads in the sand and hope everything will turn out fine.
And that is exactly what we get. Instead of having an awesome job, doing cool stuff and making a difference: our job will be just that, it will be fine. And it could be so much better, with some practises I will share in this blog.Read more →
Deze blog post is de eerste in een reeks van posts ter wegneming van misvattingen rondom het thema testautomatisering. Zie hier voor het inleidende artikel.
“Testautomatisering is de oplossing voor al onze problemen rondom testen en kwaliteit.”
Dit is helaas nog steeds een gangbare opvatting onder voornamelijk, doch zeker niet uitsluitend, ongeïnformeerde stakeholders op (lijn-) managementniveau. Daarbij blijft deze misvatting ook vaak onuitgesproken. Vanwege dit impliciete karakter, blijft deze zienswijze doorgaans lang bestaan, omdat zij niet (of te laat) onderkend en daarmee ook niet (tijdig) gecorrigeerd wordt.
De geschiedenis van testautomatisering beslaat inmiddels een periode van enkele tientallen jaren. Deze discipline is echter pas de laatste jaren écht in een stroomversnelling geraakt en ze lijkt nu voor het eerst ook definitief door te breken en zich te bestendigen, als een relatief volwassen vakgebied.
Deze ontwikkeling is een gevolg van onder andere de maturatie van tooling en frameworks, de adoptie door grote spelers zoals Google en de succesvolle opkomst van software development methodologieën die testautomatisering als randvoorwaarde hebben of waarvan testautomatisering een logisch gevolg is.
Omdat testautomatisering in deze zin genomen nog maar een relatief jong vakgebied is, bestaan er binnen dat vakgebied nog steeds een hoop misvattingen (en daarmee valkuilen). Zelfs ten aanzien van allerlei fundamentele thema’s. Deze misvattingen bestaan in een organisatie vaak niet alleen binnen allerlei (hogere) managementlagen en groepen van (meer direct betrokken) business stakeholders (zoals product owners), maar zelfs binnen allerlei groepen van practitioners (zoals developers en testers).
One of cool things I get to do besides being a consultant is (helping) organizing NG-NL. This is the annual conference in Amsterdam dedicated to the Angular framework. As you might expect, a lot of preparation goes into hosting a conference like that and this blog post is meant to give you a sneak peek of what we all did behind the scenes to make it happen.
We do a lot of software projects at Xebia Software Development. We work most of the time at our client’s location, in their teams. Together we improve the quality of their software, their process, and engineering culture. As such, we’ve seen a lot of projects play out. Most of these efforts succeeded but some failed. Recently we did a retrospective to learn from these experiences. The result is this opinionated list of characteristics of successful software projects. Read more →