Lady Vader strikes again
I had a chance to meet wonderful people and share inspiring ideas. It was an unique opportunity to hear about personal experiences and best practices worth to share.
As I wrote many times before:
How to become Jedi Master?
I do believe that every software tester is a kind of Jedi Knight. He fights for quality and the Quality is his light saber.
Who is a Jedi Master though? A person, who understands agility, quality and has a need for working together.
My best example of Jedi Master, who should lead all Jedi Testers, is Master Yoda. The same one, who talks about Agile:
“You must unlearn what you have learned”
Going further, I’ve asked people 3 – in my opinion important – questions about cooperation in an Agile team:
- How to communicate?
- How to introduce new people?
- How to share knowledge?
How to communicate
Nowadays, it is in job advertisements, small and large companies, everyone works in Agile.
When scrum team sits together – it is a perfect situation.
My concern was if a spread team (team located in several cities or countries) is still an Agile one.
I – Kinga Witko – claimed that spread team is not a real scrum team.
No one agreed with me 😦 Fine. (Misa no wise)
On the other hand, I need to underline here the one and only truth, that emerged as a discussion result:
Spread Agile team MUST use CAMERAS. And talk. Talk. Talk. All the time.
This is the fact, which everyone put their attention on. I do agree with that. When we don’t sit together – we talk, ask questions, get angry and happy together. However, when we work together, but there is no day-today interaction between us, we need to stay as close as possible to one another. Talking, laughing (even swearing) are the team-building features.
We are all humans, we have better and worse days. All of us need attention and understating. It is not possible to be achieved via Skype chat or other Slack-ish tool only. Conversation is the key to success within a team.
There is no team without little chats or coffee breaks, sorry!
The other important thing in agile approach is a mindset. If a team member is not eager to cooperate, denies flexibility or talking – it is maybe not the right place for him (or her).
I do agree that agile approach to software making is not suitable for everyone and is not fitted to every project. It is fine.
It is also OK if you are more comfortable with working on legacy code, together with a waterfall approach. You don’t need to force yourself do be AGILE. There is a lot of space within software industry for every style and every tester or developer. Chill!
New team members
In every Jedi Master’s life this day comes – he has to train young ‘Padawans’. Either a new team member, company member or a trainee.
Some time ago I was asked if there is a good way to introduce people into the project? The next question is – how will you know that the new team member IS READY to perform on his own.
Surprise! Surprise! (there is none)
People are not robots, it is not possible to predict what will happen. Going this direction – there is as many ways as Masters. The way you teach usually depends on your skills, empathy and understanding. And good will, of course!
There are such things as company values or project – related directions, but – AGAIN – conversation is the key.
People on my discussion panel suggested clever solutions, such as:
- never imprison new testers with boundaries – let them explore your software
- teach through example
- less talking – more doing
- provide documentation and lot of freedom.
Again, it depends on your skills and new-joiner’s abilities, what is possible to be achieved. Another point in this discussion is a recruitment process. If a correct person is selected, he’ll perform good testing in a short period of time.
People spotted also, that a new team member is fantastic benefit and opportunity for ourselves. In the position of trainer we are able to:
- learn how much do we know
- acknowledge our limitations (Context Driven Testing)
- explore with a fresh look (Exploratory testing)
- find unknown bugs
- fix old bugs (for example those, that everyone got used to)
- avoid knowledge silos.
Modern companies have lot of ideas to share knowledge. Most of the times, employees are able to run or attend cross-team / cross-technology workshops or presentations, take part in training or read books.
As I love to collect clever knowledge-sharing ideas – I’ve asked people “How do you share knowledge in your teams/organizations”.
Some of you may already know Michał Buczko – he encourages developers and testers to work in pairs (Pair people!) – it is a convenient way of broadening your horizons and extending knowledge.
In order to share knowledge, you may also “rent time”.
It may be an hour / day of a developer, tester or other team or company member.
How to do that? Just book a time with the person and take part in his / her day. You can exchange afterwards – it’s up to you.
I know that there are companies, which even “swap” jobs among completely different departments to FEEL the other person’s real working environment (I’m talking about you – Ocado:). All of those brilliant ideas may seem tiny, but they really work and empower people to do ingenious things.
Maybe some of those practices shall be a software company standard at some point?
I wish it to all of my test-buddies and to myself as well.
Should you have any comments, ideas, things that work fine at your company and you would like to share – comment down below or stalk me on Twitter.
I hope you’ve enjoyed the summary – see you all on my next discussion panel 🙂