![\"geifon](\"http:\/\/leanmagazine.net\/wordpress\/wp-content\/uploads\/2011\/04\/geifon-copy.jpg\")
<\/p>\n<\/p>\n
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\u2019s public authorities. The assignment \u2013 in keeping with the times \u2013 was to make three mobile telephone services publicly available. One of the developers who took the train across the \u00d6resund Bridge was Tina Lenshof, an M.Sc. in Electrical Engineering educated in Lund.
\n\u2018I\u2019d only recently arrived at the company, so this felt like a real challenge. Until then we\u2019d 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.\u2019<\/p>\n
Rock-solid team-building<\/strong> Daily contact with the client Essential feedback Task completed \u2013 energy dissipated<\/strong> The competitive instinct can be counter-productive<\/strong> 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 […]<\/p>\n","protected":false},"author":16,"featured_media":437,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23,59,83,51],"tags":[],"_links":{"self":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/408"}],"collection":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/comments?post=408"}],"version-history":[{"count":14,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/408\/revisions"}],"predecessor-version":[{"id":1098,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/408\/revisions\/1098"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media\/437"}],"wp:attachment":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media?parent=408"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/categories?post=408"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/tags?post=408"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nBefore the project got going, the team was brought together on home ground in Malm\u00f6 by its coach Ola Sundin. The first task was to build up the team members\u2019 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.
\nJust 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\u2019s positive attributes while still making clear \u2013 gently \u2013 what they were less good at.
\n\u2018When you can recognize your deficiencies and admit them to others, you\u2019re well on the way to winning their confidence,\u2019 says Tina Lenshof. The group also discussed various personality types and looked at the whole team\u2019s results. This allowed them to see which attributes were represented in the team and which ones they needed to cover between them.
\n\u2018Ola 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\u2019re 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 \u2013 and towards him in his role as coach \u2013 if conflicts arise.\u2019<\/p>\n
\n<\/strong>Motivation needs more than a list of requirements, so Ola Sundin got eveevery team member to formulate one or more personal goals, such as \u201cto become a specialist within a technical field\u201d or \u201cto strengthen my leadership qualities\u201d. Later during the project he followed up how far team members had managed to fulfil their goals.
\nA 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.
\n\u2018Being able to take the initiative and get immediate feedback on design proposals made our team very effective,\u2019 says Tina Lenshof. \u2018We 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.\u2019 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
\nThe work with the client started with a \u201cSprint Zero\u201d 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\u2019s project leaders, while the role of Scrum Master was shared between the team members. The scrum team was housed at the client\u2019s offices in a room dominated by linked desks where they sat and worked in concentrated silence, each with their own laptop.
\nIn all, the project comprised 12 sprints of 1\u20132 weeks.<\/p>\n
\n<\/strong>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.
\n\u2018We 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.\u2019 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.
\n\u2018Getting personal praise from other members strengthens your own positive attributes and increases your motivation,\u2019 says Tina Lenshof. \u2018The 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\u2019t happen again. It\u2019s also a great opportunity to bring up worries for the future, so that the team and coach can manage them together.\u2019
\nIt 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\u2019s solution to both problems is pair-programming.
\n\u2018Working together has several benefits,\u2019 says Tina Lenshof. \u2018You 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\u2019s an efficient way of spreading knowledge and skills across the whole team.\u2019<\/p>\n
\nWith 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?
\n\u2018We brought it up with our coach Ola Sundin at the next retrospective,\u2019 says Tina Lenshof. \u2018We eventually decided that the problem was that we had reached our goal too early \u2013 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.\u2019
\n\u2018When you make frequent deliveries, you keep your focus. You get an overview of what\u2019s needed to complete a delivery and can estimate how long it\u2019s 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.\u2019
\nSomething which also affected the team\u2019s 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.<\/p>\n
\nThe 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.
\n\u2018Eventually 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,\u2019 says Tina Lenshof. \u2018We got stuck in an emotional discussion where prestige was more important than technique.\u2019
\nIn the retrospective, the team came to the conclusion that when there\u2019s no way of measuring the quality of different solutions, it\u2019s better to discuss the different proposals\u2019 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.
\n\u2018When 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.\u2019<\/p>\n","protected":false},"excerpt":{"rendered":"