Presented at Gymnázium Brno-Řečkovice.
For those, who has attended Robot Framework workshop on Test Crunch conference you can find more details about environment setup, source codes and books below.
Installing Robot Framework on your computer
- Download and install Python 2.7 (32/64 bit based on your OS) from https://www.python.org/downloads/
- Add Python location into Path environment variable (e.g. c:\Python27\;c:\Python27\Scripts\)
- Download and install wxPython 2.8 with unicode support (32/64 bit based on Python version) from http://sourceforge.net/projects/wxpython/files/wxPython/188.8.131.52/
- Install pip (package manager) by opening command line and running command python get-pip.py
- Open command line and run following commands to install Robot framework and additional libraries
pip install robotframework
pip install robotframework-ride
pip install robotframework-selenium2library
- Start RIDE by running ride.py in command line
Workshop source code
Books and other study materials
- Dive into Python from Mark Pilgrim http://www.diveintopython.net/
- Dive into Python 3 from Mark Pilgrim http://www.diveintopython3.net/
Recording from workshop will be available soon.
Stay tuned and enjoy Robot Framework.
Learn more about FFFI.
The process of forming the team, it’s stages, team roles which should be represented in a team and many interesting issues about team coordination, cooperation, communication and productivity. All of that was discussed during agile community meeting, which Y Soft was hosting last week in Brno office. In this text I want to highlight most interesting issues we have discussed and found ways hoe to handle it.
Short introduction by Michal Vallo was about Tuckman’s stages of group development as life-cycle of team construction and Belbin Team Roles as guide to what characters should be included in each team. Later, each participant propose one topic to be discussed, then everybody vote for the one which he likes. I will present three of them which were discussed the most.
Need of Junior/Senior positions
Team consists of different roles and people. One of way how to differentiate team members is usage of Junior and Senior labels. There were many interesting inputs to this topic.
One of the opinion reflected in real company policy was to remove these formal roles. Reasons to do such a thing are more. There is no race in a team to reach senior position. If starting new project and forming new teams, you will prevent situation with low interest in junior positions in a team. But you still have to differ skills and knowledge, reward courage and motivation. It’s should by done by assigning responsibilities, competences, work tasks with different difficulty. And do not forget about money, company benefits and other materialistic stuff.
On the other hand, especially bigger companies has defined career paths, so they need to differ positions on formal level. It also works if these career paths are well defined and they are not limited by project budget or head count calculated on HR. Because there was also one case discussed, where team is limited by budget and even they had chance to hire great senior guy, they couldn’t because of restrictions on number of senior positions.
Low performance of one member in a team
An interesting discussion was about dealing with low performance of one team member, who is lowering teams overall performance. Well working team should identify such a member itself without intervention from higher positions. Move to another team, relocate to another department or fire him are another “simple solutions”.
But what if this member is e.g. external contractor and you cannot get rid of him like this? Again more working solutions were discussed, but think about two types of people. Ones who will get better if you will push them and ones who are too lazy or incompetent for this work type and load. For the perspective ones, motivation is the key. If direct motivation is not successful, try to do it other way. Make them work in pairs with team members which are more productive, make them responsible for something and force them to present work results to the team e.g. on daily stand-ups. They will be shamed maybe, but it should show the difference. For the lazy ones, try to assign them work tasks which are easier, maybe not popular, or just ones that are the cheapest in case they will screw it.
But do not forget. That it’s not only about performance. Team member with lower performance can have e.g. greater social influence for the team, so it’s affecting the team performance also.
How to motivate team and its members to perform better? In the beginning I want to explain difference between motivation and stimulation, because both approaches were discussed. Motivation refers to the will to act, work, create, etc. On the other hand, stimulation deals with encouraging on an initial effort or in supporting an already existing action. Most of discussed motivation practices were:
- Allowing self-development of team members, based on their will and needs of the team
- Giving challenging and interesting task to team members
- Take inputs from team members seriously, try to give valuable feedback
- Trust the team and let them make decisions, give responsibilities to each team member
If there are some activities in the team like supporting the product or bugfixing, which are not as popular as e.g. new development, distribute these type of tasks over the whole team by rotating engineering role every iteration or distribute it evenly across all team members.
It looked like everybody has took something from this meeting, and I am looking forward to another interesting topics to be discussed in further community meetings.
The idea behind unconference is that attendees create and plan content.
How we organized it?
We presented rules of unconference to attendees:
- submit your topic for discussion
- place topic which you like onto the planning board
- join similar topics into one topic
- topic owner should kick-off discussion
- enjoy the discussion
- feel free to leave room when you do not find topic interesting and join other group
We made 3 iterations of topic discussion. Duration of each iteration was 20 minutes followed by 10 minutes break.
We were running 3-4 parallel tracks and many discussions were happening in corridors.
What was the feedback? It was positive. Attendees liked opportunity to learn about challenges or experience from the other company.
Attendees suggested that discussion time should be longer. Twenty minutes were not enough to dive deeply into the topic.
We’re looking forward to attend next unconference with our friends from Kentico.