My head feels a little dizzy, but outside my hotel window, the sun is again shining from a clear blue sky, little birds are singing, and it’s looking to be a wonderful day today. Runö, the conference venue, is a really nice place- and so is Let’s Test! If you’re here, you will know what I mean, if not you just have to believe me: Never have I been with such a friendly and bright bunch of people! I love it!
After the opening keynote yesterday, I went to on my presentation for today. I was almost done, but then the team (that’s me!) decided to refactor everything! Oh dear! But it had too many slides, and they just didn’t work well together, and that’s a showstopper, right?
The good news is that the I got the presentation fixed: The refactoring succeeded! Thanks to friends and colleagues for allowing me to reflect with you on the subject (there’s the friendly thing again!).
The bad news is that I had to skip the tutorial I planned to go to.
I didn’t skip tutorials completely, though, as Iwas very kindly allowed to jump in on Henrik Andersson and Leo Hepis’ tutorial “Now, what’s your plan?”, which started at 3 pm.
I’m sure all the workshops were excellent, but this was really, really cool: During the 3 hours, we got to develop test strategies for our testing team, incorporate really challenging context changes, learn about what context is, and discuss buth our own and other team’s approaches and solutions to the challenges we were put through.
Normally, context is something which is “just there”. As a team member, I’m often not given all the needed knowledge about context, but still I have to relate to it anyway and develop my own test strategies, or when I’m given management responsibilities, the strategy of the whole team. Still, the context is shaping my strategy and it does so in so many ways. And then we have context change: Things aren’t static, right? Although we all prefer working in stable environments, things do often change: Sometimes to the better, sometimes to the worse, sometimes just to something different, but the point is that we cannot disregard context changes, since they affect us whether we want it or not.
How do teams react to context changes? I observed at least four different “reaction modes” within the teams during the workshop:
- “Ok, what’s this?”: It’s a completely new situation and there are no prejudices or previous context to take into account. This is fun and generally feels good.
- Resistance, chaos, integration, new status quo – i.e. all of the phases of the Satir Change Model. This can be a difficult process, especially it the team resides in the “chaos” phase for long.
- Relief: A context change clears everything up, and the project can go from “problem fixing” to “solution mode”. This feels very good too.
- Panic: The context change is sudden and feels like a bomb had been dropped in the middle of the project and is now threatening to blow everything up: The team panics. Hopefully, the bomb can be defused and the panic can be cleared.
- The variables which significantly influence the task
- Those aspects of the total environment that seem important/relevant
- Context is anything that changes my model
What’s your definition?