Office kitchen

When we kicked off our Wrocław office we had only around 20 people, almost all developers, plus the head of the office. One day, the head came to us saying the office needed a development manager. Someone to help run the organisation, move us in the right directions, overcome obstacles, and inspire people. He asked each and every of us to help with the recruitment. We were going to recruit our manager.

Where to begin

The first thing that came to my mind after getting this breaking news was, ‘cool’! I, a software engineer, would have a real impact on who my manager would be and consequently what my everyday work would look like. I felt the power! But then I realised that with great power comes great responsibility…

So I started thinking about how I imagined my ideal manager. What’s important for me as a developer? And how should I measure whether a potential candidate meets the criteria?

Obviously, we were not left alone with our thoughts. We scheduled an internal meeting to discuss what we wanted to achieve and how our recruitment process would look. Our mission was to find a person who would be able to create and support happy teams in a highly effective organisation.

A development manager is neither project manager nor architect for us. We don’t require deep domain and technical knowledge. Instead, we felt the person needed to fit well in our working environment and help move us another step in our direction of travel. Sounds good, doesn’t it? But how to define a happy team or a highly effective organisation?

Some details about the way we work

The company is distributed between multiple locations (Hatfield, Kraków, Wrocław, Sofia, Barcelona). We work in small agile teams. Some of them do Scrum, some Kanban, and the rest… ‘Scrum-ban’. A few teams work as squads, without formally assigned leaders. All of us have great autonomy  —  this is one of our core values. Development managers support teams and help them grow. They look for potential improvements and directions in which we want to develop as organisation.

One of the few constants in our company is a change. We like to experiment: not only with technology but with Agile and management practices as well.

What makes organisations effective?

For me, the two main ingredients of effective organisation are: effective individuals, and good cooperation between them.

Good cooperation requires even better communication. Free and direct communication across the whole organisation (between all levels) is now a mainstream trend in all kinds of companies. It’s easy to say but harder to practice. Creating a respectful environment in which people are not afraid of voicing their opinions freely, their voices are heard and listened to, and there is trust in good intentions, is not a trivial task.

And what makes teams happy?

Sometimes I find it difficult just to define what makes me, as an individual, happy – and there are six of us in my team. One thing I am confident of is that a team cannot be happy without each and every of its members feeling happy.

Management 3.0 gives us some universal tricks when it comes to making people happy. Here is the list of twelve steps to happiness:

https://management30.com/wp-content/uploads/2015/06/12-Steps-to-Happiness-v1.00-Poster-color1.pdf

Looks easy, doesn’t it? But is the list complete? Does it work for everyone?

To sum up what a development manager means to us

The role is more about helping others than managing resources. It’s about listening and observing instead of talking. And most importantly, about making people learn what they need to be happy and effective and how to achieve it. Helping them by giving tools, knowledge, tips, and the freedom to use them how they like, instead of enforcing ready solutions.

The recruitment process

At this point, you should have a better feeling how this role is defined in our company. Let me shed more light on how the team played a part in the process of recruiting our manager, what we learnt from it, and how it impacted our further work.

Every candidate was scheduled a team interview – a 1.5 hour meeting with developers in our company. The aims were to:

  • Decide if the candidate would fit well in our environment and if we wanted to work with them
  • Give the candidate an opportunity to meet their potential colleagues, learn about our working environment, and decide if working with us looked like fun

At the beginning of the meeting, the candidate was asked to give us a presentation about developing great teams. This was just an entry point to the further discussion.

The course of the meeting was driven both by us and the candidate themselves, and usually differed slightly with every session. Our idea was to make it as natural and interactive as possible.

Most questions were based on the presentation, however, we had a few prepared in advance (in any interview we always want to know what a candidate expects from the role, what’s their vision, and what value they can bring to the organisation). We were also interested in their approach to handling conflicts and difficult situations, development of people, projects, teams and organisation.

We also made sure that there was time for questions from the candidate. It’s important to bear in mind that the team interview was more focussed on relations with our future coworker than on checking their knowledge.

How well did it work?

The first time we applied this process was at the end of last year, and the first successful candidate joined us in March.

Since then, we’ve found it very beneficial to get candidates exposed to the broader group of people, to the whole team with whom they’ll be working. Every person is looking from a slightly different perspective, which helps us making more informed decisions, and it gives candidates a broader insight into the company. It also helps to establish a better relationship with our future colleague from the very beginning.

We’ve found it especially important in the case of leaders and product owners. The first day our new development manager came to work I felt I knew him already, which made the conversation very natural.

He had very similar feelings. Wojtek – our first Development Manager in Wroclaw – shared his thoughts about the newly created process:

“During the team interview you have the possibility to meet the people you will be working with – hear about challenges in their daily work, what they like/don’t like. It allows you to make more informed decisions, not only compared to the recruiter or interviewer but also the website. You just feel the company culture. And believe me, it is much more important to feel this culture inside the team, during the team interview, than hear about it from a manager. It’s more impressive when (as in my case) you first observe the culture during the team interview, then hear about it from office head. You realise that you’ve just observed in practise what they are talking about. You know that it’s not a culture on paper but a living one. Last but not least, after a team interview, you’ve got ‘buy in’ from the team. You know that they accept you as their new colleague and manager and are open to work with you.”

Having software engineers involved in the decision process gives us a real impact on building the organisation, helps us to identify with results and take responsibility for them. However, it creates also some challenges, like putting aside personal objections to accept a group decision. The process is also time consuming and engages a lot of people.

Should you help recruit your next manager?

Introducing the team interview into the recruitment process turned out to be a very successful experiment, and I’d recommend you try it.

We’ve carried on with this approach for development manager positions, and have extended it for product owners as this role requires a lot of communication and coworking with the teams. Maybe one day we will do it for other positions as well…

Even if you are not interested in being a manager, it’s still good to remember ‘Management is too important to leave to the managers’ (Jurgen Appelo). Everyone has an impact on, and is responsible for, the environment around them. So be the change you are looking for!

Dorota Wojtalow, Software Engineer

July 21st, 2016

Posted In: Blog

Tags: , , , , ,

Team size notes

Productivity and team size

What is the ideal team size? Many suggest seven people – give or take one. Small teams in my experience are more efficient and need less management oversight. Recently our Business Planning Systems (BPS) team reached 10 people. We started to experience a declining trend in productivity, so we had to rethink how we were structured.

But it was not just team size

Our productivity decline was not just limited to team size. We were also struggling with having applied an emerging design model, new requirement process, and a lot of new team starters.

What could we do?

I did not want to reduce the number of team members, we have so much work to do! I also didn’t believe the solution was to switch to a new Agile framework and I didn‘t want to split our product backlog. This left a few options to experiment with:

  1. One product backlog with two sprint backlogs and two teams
  2. One product backlog with one sprint backlog and two teams
  3. One product backlog with one sprint backlog and two or more self forming teams.

The BPS team lead had pondered on this for a while and together the decision was made to go with Option 3: one product backlog with one sprint backlog and two or more self forming teams. We ran the experiment for four months at the start our winter roadmap.

The difference with Option 3 was the team could form as many teams as they felt necessary to work off the one sprint backlog. For example, two teams equally split, two teams formed of six and four people, or three teams formed of two, four and four people. This also meant a change for the BPS team lead; he remains team lead but delegates more accountability to the team.

Benefits

  • Team is empowered to take action, without team lead and PO involvement.
  • Cross skilling of team members increased. One sprint you might be working with Fred and Steve and the next with Larry and Barry.
  • It was far easier to get new starters up to speed in smaller groups.
  • We retained one weekly entire-team ‘grooming’, so everyone was familiar with the business requirements and backlog.

What we monitored

  • Would teams always form into the same group to work on the same type of issue, thus impacting team dynamics and cross skilling?
  • Velocity of work coming out of the team.
  • Number and type of issues identified in retrospectives.
  • Team happiness.
  • Delivery to business and their satisfaction with outputs.

How did the model work?

  • Velocity of work continued as normal.
  • Commit-to-sprint backlog stayed as normal.
  • At sprint planning Phase 2 the team discussed stories and how to structure itself to best service those stories. For example, three stories involve UI so group those, three other stories focus on refactoring, security and support so group those.

Now the team could decide who wanted to work in which group. It is the team’s responsibility to make sure there’s a) enough work for the number of people in that group b) enough people to work on the stories in that group.

What else to address declining productivity?

I mentioned it was not just team size affecting productivity, but also applying an emerging design model. By not focusing on future architecture for complex features, we were spending considerable time refactoring and make compromises. We decided to trial an opt-out-of-sprint option.

  • A team member could choose to opt out for a sprint or some of the sprint, to focus on an issue.
  • We would reduce our expected sprint velocity for the upcoming sprint, based on the amount of time the person would need.
  • At the end of the time allocated the team member would present their findings to the entire team, and we would then make a number of decisions i.e. work on the issue now; work on it later; the solution didn’t work so look into an alternative next time etc.
  • There is no restriction on how often a team member can take the opt-out-of-sprint option. In the last four months only two people have chosen to do this and both times it was very valuable.

What was the end result?

Success! This is now how we work. The team loved the new approach and productivity improved. Disclaimer, to my knowledge the team did not break out into dance moves like the below image, but I like to think they did…

Dancers

To wrap up, we gained the benefits of working in small teams but also of moving as a collective towards the one overarching product vision. Job well done team!

Ali Major, Product Owner

May 6th, 2016

Posted In: Blog

Tags: , , , , , , ,

Anna Miedzionwska

Communication is important. Not just for a Product Owner, but the whole team. Especially if it’s not a collocated one.

Here is an excellent test for your team: a fun exercise that will uncover communication issues that nobody was aware of.

Setup:

  • Time needed: 45 – 60 minutes (30 minutes for the exercise + time for discussion).
  • Number of people needed: 4-6.
  • Divide the team to 3 groups.
  • Groups A and C go to different rooms.
  • Group A gets a picture only they are allowed to see (a childlike drawing works well).
  • Group C gets a pen and a sheet of paper.
  • Group B, called ‘Runners’, stays with group A for now. Their task is to communicate between Group A and Group C.
  • Communication exercise-01

Exercise

How it works:

  1. Group A and Runners discuss what’s on the picture. Runners can ask any questions they want, but they can’t see the picture and they can’t take notes. Group A can see the picture at all times.
  2. Runners move to Group C and convey the information.
  3. Group C draws a picture based on what they are told. They can ask additional questions about anything.
  4. Runners come back to Group A to ask for more details.
  5. Steps 2,3,4 are repeated as many times as needed until the time is up.
  6. The person facilitating the exercise should spend some time with each of the groups, silently observing.
  7. At the end, ask the teams how well they think they performed.
  8. Show both pictures to everyone and discuss. What went well? What could be improved? Any actions?

Some things to pay attention to:

  • Does the team start with the big picture or the small details?
  • Does the team optimise the way they work during the exercise?
  • Is the team aware of time and how fast they are progressing?
  • Is the team focussing on the most important elements?
  • What assumptions are made?

How my team performed:

Drawn by the team

What we observed:

  • The team jumped straight into details. Only 10 minutes into the exercise did they discuss the proportions of some key elements.
  • Runners split after the first exchange to save time. They didn’t, however, communicate between themselves, which meant they asked the same questions twice. Surprisingly, they sometimes got different answers to the same questions, which required extra communication.
  • Group A also split, so they could deal with Runners separately, which resulted in one member not knowing if the horse was going to be present on the team picture at all at the end of the exercise.
  • The team didn’t plan the execution for the time given. This caused rushing at the end and asking for extra time to complete.
  • Some key elements were described in detail, while others were very basic.
  • An assumption was made that characters on the picture sit at a table. It was quite quickly rectified though.
  • The overall result was good, but the team didn’t think so.
  • The team enjoyed working together and want to repeat the exercise in a few months to see if they can perform better.
  • The team is proud of their work.

It was definitely great fun and a good learning experience for the team. Try it yourself.

For more ideas about communications in non-collocated teams, see Ali’s posts, and check out my own blog for more product ownership ideas.

Thanks to my colleague, Lukasz Kucharski, who introduced me to this exercise!

Anna Miedzianowska, Product Owner

January 26th, 2016

Posted In: Blog

Tags: , , , , , ,

Scroll Up