The story of a group of software developers who formed a team, travelled to Denmark and found joy working on an agile software project.
In the spring of 2009 Softhouse was contacted by a Danish client looking for a development team with skills in web technology. The client develops electronic infrastucture for Denmark’s public authorities. The assignment – in keeping with the times – was to make three mobile telephone services publicly available. One of the developers who took the train across the Öresund Bridge was Tina Lenshof, an M.Sc. in Electrical Engineering educated in Lund.
‘I’d only recently arrived at the company, so this felt like a real challenge. Until then we’d been spread out as consultants at a number of different companies, and only a few in the team had actually worked together before. As far as I knew, we had quite different technical backgrounds, and not many in the group had thorough experience of agile working practices.’
Rock-solid team-building
Before the project got going, the team was brought together on home ground in Malmö by its coach Ola Sundin. The first task was to build up the team members’ trust in one another. Exercises included everyone presenting themselves in a variety of ways. This helped people both getting to know each other and finding their own place in the group.
Just before the first sprint in the scrum project, everyone did a personality test. Put simply, each person had to choose among words to describe themselves. The test was designed in such a way as to emphasize each participant’s positive attributes while still making clear – gently – what they were less good at.
‘When you can recognize your deficiencies and admit them to others, you’re well on the way to winning their confidence,’ says Tina Lenshof. The group also discussed various personality types and looked at the whole team’s results. This allowed them to see which attributes were represented in the team and which ones they needed to cover between them.
‘Ola Sundin, our coach, explained how a team develops and goes through different phases. He was careful to explain that it is natural for conflicts to arise when you’re on the way to becoming a high-achieving team. He pointed out how important it is for team members to be open towards each other – and towards him in his role as coach – if conflicts arise.’
Daily contact with the client
Motivation needs more than a list of requirements, so Ola Sundin got eveevery team member to formulate one or more personal goals, such as “to become a specialist within a technical field” or “to strengthen my leadership qualities”. Later during the project he followed up how far team members had managed to fulfil their goals.
A further motivational factor for scrum team members was that they were directly responsible, together with the client, for formulating requirements and determining goals for all the sprints.
‘Being able to take the initiative and get immediate feedback on design proposals made our team very effective,’ says Tina Lenshof. ‘We had daily access to the client if we needed to ask questions, which made it easier for us to fully understand the aims of the project. It also meant that we became even more engaged in the project.’ At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The work with the client started with a “Sprint Zero” which aimed to present the team to the client and stakeholders, to set up the working environment and servers, and to produce a proof-of-concept in line with the project. The role of Product Owner was taken on by one of the client’s project leaders, while the role of Scrum Master was shared between the team members. The scrum team was housed at the client’s offices in a room dominated by linked desks where they sat and worked in concentrated silence, each with their own laptop.
In all, the project comprised 12 sprints of 1–2 weeks.
Essential feedback
Every morning the team held stand-up meetings to synchronise their work, to take new information on board, and to deal with any unplanned work which had emerged. Guiding principles for the meetings were to keep them short and not to discuss solutions.
‘We agreed that we would have a specific aim for each meeting and that we would close the meeting as soon as the aim had been achieved. This made sure that we saved both time and energy.’ The team was re-energized with a retrospective after every sprint. By sharing their experiences from the sprint about what worked well or badly, team members were able to communicate and share their expertise, and all were better prepared for the next sprint.
‘Getting personal praise from other members strengthens your own positive attributes and increases your motivation,’ says Tina Lenshof. ‘The retrospective is also a sort of forum where you can raise problems, find ways of solving them, and sort out how to make sure they don’t happen again. It’s also a great opportunity to bring up worries for the future, so that the team and coach can manage them together.’
It emerged during the retrospectives that when team members worked alone on difficult assignments, they found it difficult to focus, and on other occasions they spent unnecessarily much time fixing details. The coach’s solution to both problems is pair-programming.
‘Working together has several benefits,’ says Tina Lenshof. ‘You maintain your focus on the task, you reach a solution more quickly, the solution is automatically reviewed and is often better. At the same time, it’s an efficient way of spreading knowledge and skills across the whole team.’
Task completed – energy dissipated
With the Danish spring at its most beautiful in May, the team experienced a sudden dip in energy levels. It was hard to explain, as it happened immediately after several weeks of unexpectedly high productivity and satisfactory results. What had happened?
‘We brought it up with our coach Ola Sundin at the next retrospective,’ says Tina Lenshof. ‘We eventually decided that the problem was that we had reached our goal too early – the task was completed before the sprint was over. Instead of finishing the sprint early, we tried to find new tasks, and this led to frustration. From then on we never extended a sprint just to suit the schedule.’
‘When you make frequent deliveries, you keep your focus. You get an overview of what’s needed to complete a delivery and can estimate how long it’s going to take to reach your goal. On the other hand, dragging tasks out just to make time pass decreases motivation and energy. By having a goal for every sprint, the team knows when to bring the sprint to an end and congratulate itself on a job well done.’
Something which also affected the team’s energy levels positively was being given new challenges. As a result, they were determined to deliver fully working software. It saps the energy to have to repair something which used to work once upon a time, while new challenges increase energy. Occasionally the team had to go back and improve its deliverables. Taking time to reflect on solutions and rework the code gave increased satisfaction, since the team knew they were delivering an improved product.
The competitive instinct can be counter-productive
The team managed for long time to avoid conflict, until it was divided into two to develop two different solutions for the same product. This put a damper on the feeling of solidarity achieved earlier in the project. The competitive instinct took over, and the two groups started to rile each other. Instead of being a spur, the competition actually stistifled creativity, and the only goal was who would get there first.
‘Eventually we found ourselves in a situation where the client had to choose between two different solutions, though there was no way of deciding which solution was the best,’ says Tina Lenshof. ‘We got stuck in an emotional discussion where prestige was more important than technique.’
In the retrospective, the team came to the conclusion that when there’s no way of measuring the quality of different solutions, it’s better to discuss the different proposals’ motivation at the outset, before development begins, and let the best motivation determine the outcome. Team members also felt their motivation shrink when they were compared with each other, and were prevented from working together.
‘When we summarized the project we concluded that there were three factors that were vital to building up team spirit. Firstly, that we had access to a team coach thoroughly immersed in agile development and group dynamics. Secondly, that we were open towards each other. And finally, that we placed great importance on improving our working practices and following agile principles for a software project.’
