The use of the Scrum method in IT companies in Pirkanmaa area
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


The use of the Scrum method in IT companies in Pirkanmaa area

Uploaded on

A presentation made from the results of my Master of Science Thesis: "The use of the Scrum method in IT companies in Pirkanmaa area" ...

A presentation made from the results of my Master of Science Thesis: "The use of the Scrum method in IT companies in Pirkanmaa area"

In finnish:

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 30 30

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. The use of the Scrummethod in IT companies in Pirkanmaa area M.Sc. Thesis, Jyri Vuorinen
  • 2. Selected comments fromthe interviews ”Often our project model resembles a 19th century steam train model, where there is one set of fixed rails to follow.” A developer’s comment on the company’s current project model. ”Scrum started from a single person crusade and the change has taken a long time.” A development manager’s comment on Scrum.
  • 3. Selected comments fromthe interviews ”We don’t care as long as it gets done. Don’t tell us about making software, we only want to hear about the finalized software.” A customer’s comment when the Scrum method is presented. ”Do not bother us until the software is finished.” A customer’s comment on a meeting request.
  • 4. Selected comments fromthe interviews ”We have the management’s silent approval for the Scrum. They don’t disturb us – at least not too much.” One ScrumMaster on the management’s attitude on Scrum. ”Computer nerds don’t always even speak with their nearest co-workers in the office.” A developer tells about the communication problems in their meetings
  • 5. Thesis based on aninterview study• 11 companies were interviewed• Small and middle sized companies from Pirkanmaa area, Finland• 18 persons were interviewed: project, development and quality managers and developers.• 46 interview questions
  • 6. Objectives of the thesis• To learn more about the agile methods used in companies.• To find out how well the Scrum practices have been adopted and how well the method is followed.• To identify the benefits achieved using Scrum method.• To identify the problems and challenges using agile methods and to find solutions for them.• To identify and spread good agile practices.
  • 7. Interview topics• Company demographics• Following the Scrum method, ie. The Nokia test• Single Scrum practices and how well they are followed• Benefits, problems and challenges using Scrum
  • 8. Demographics of thecompanies interviewed• 5 companies were specialized in embedded software• 2 companies were specialized in mobile software• Other companies did all kind of software development• Companies had from 15 to 175 IT employees.• 10 companies used Scrum, one company used their self-made agile method.• Most of the companies had Scrum experience of 1,5-3 years.
  • 9. The benefits of Scrum method• Team feels that working makes more sense and more motivating.• A spring gives the team a possibility to see development regularly.• Scrum offers a clear and simple enough way of working.
  • 10. The benefits of Scrum method• Scrum enhances open communication both with the team and with the client.• Scrum increases transparency, because everyone is aware of how well the project is going and all the risks are visible.• By priorizing the backlogs, the working time of each team member is directed to the right tasks.
  • 11. The problems and challengesof Scrum method• Customers don’t understand the Scrum method or they cannot commit to the Scrum practices.• It is very challenging to adjust Scrum to the companies inflexible organizational culture.• Management isn’t committed to Scrum or sees it as an obscure method.
  • 12. The problems and challengesof Scrum method• The deployment of scrum is challenging and time consuming.• The Product Owner role is challenging. He doesn’t have time to invest on the project or he gets too much involved in the teams work.• There tends to be a lot of disturbance in the Sprints, extra maintenance tasks and bug fixing are alway bothering.
  • 13. Nokia Test• The Nokia Test has 9 questions on different areas of Scrum.• Each question is given 0-10 points.• Average value of these points describes the company’s agile performance in Scrum.
  • 14. Nokia Test results 10 9 8 7 6Points 5 4 Average 3 2 1 0 C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 Company
  • 15. Nokia Test results• From the interviewed companies average value in Nokia Test was 4.5• A few companies, who told they were using Scrum but according to this test they actually didn’t, can be distinguished from the results.• Two companies succeeded better than others and got six or more points in the test.
  • 16. Nokia Test results• Company size or earlier Scrum experience didn’t correlate with the points in this test.• When comparing the answers from this test to international data, the following areas could be improved: – Agile specifications, Product Owner’s behavior and utilization, and preventing disturbances• The usage of backlogs was more advanced than in the international data.
  • 17. Scrum training• Agile awareness and good practices were spread in Scrum trainings.• Some companies sent all their employees to ScrumMaster trainings, other companies sent only their team leaders.• Many had invested on their own training material or on Agile book library.
  • 18. Customer response• Customers were only interested in the final product.• They may not even want to understand the method used in software development.• Customers praised the more open and regular communication and flexibility.• Fixed price project with heavy change management process is hard to fit on Scrum.
  • 19. Organizational culture• Half of the interviewed companies told that Scrum fits together with their organizatinal culture.• Management support to Scrum varied a lot, but many were very excited about the results.• There were of course resistance to change when moving to Scrum method.• Two companies had their whole company operations based on the Scrum principles.
  • 20. Scrum teams • Most of the companies aimed at teams sizes of four to six persons. • Teams were mostly self-organized and the team members skill overlap had increased. C11 C10 C9 C8 C7 C6 C5Company C4 C3 C2 C1 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 Smalle st and large st te am size / e mploye e s
  • 21. Sprints• A few companies didn’t use Sprints, they only had a larger top-lead plan to follow.• Sprint duration varied from two to four weeks. Two week Sprint were said to be most efficient.• Longer Sprints didn’t work because the companies couldn’t predict that long to the future and the work estimates were no longer accurate.
  • 22. Testing• A lot of improvement is needed in test automation.• Continuous automatic unit testing was used only in a few companies.• Basic unit testing was used everywhere.• Four companies used separate acceptance criterias or acceptance testing.
  • 23. Specifications• Some companies did all the specifications before any iterations.• User stories and use cases were used more often than strict formal specification documents.• Many of the interviewees emphasized that agility doesn’t mean that the specification work can be left out.
  • 24. Product Owner• Product Owner role was very challenging. He was expected to manage various different tasks.• Two companies didn’t use Product Owners in their projects.• Majority of interviewed companies had internal Product Owners.• Two companies had an external Product Owner from the client.
  • 25. Product Owner• The Product Owner role was hard to fit into the organization.• Communication chain was either too short or too long.
  • 26. Product Backlog• Every company used Product Backlog, but priorizations were made by various different criteria.• Some of the companies had a larger release plan that controlled the Product Backlog, but majority of the companies had a Produt Owner to control the Backlog.• Using and managing the Product Backlog requires a lot involvement and expertise, because very complex dependencies has to be taken into account.
  • 27. Estimating• Estimating was mostly done by teams.• Estimates made by the project manager were more inaccurate.• Estimating itself teaches everyone what kind of work it takes to build a new feature.• Poker planning was used in half of the companies and it was often described as a fun method.
  • 28. Burndown Charts• Burndown Charts were used in most of the companies, only three companies didn’t think it was useful.• Burndown Chart was used to follow team velocity. Teams knew their velocity in four companies.• The concept of velocity was seen quite problematic.• Most advanced companies generated the Burndown Chart automatically from the Sprint Backlog, the team knew it’s velocity and Product owner used velocity data in backlog planning.
  • 29. Team Disruption• A regular problem for the team’s work were the frequent disruptions and interruptions from multiple different sources.• Maintenance tasks from other projects, support requests, client requests and own project managers were most common cause of disturbance.• These extra tasks usually weren’t listed in the Sprint or Product Backlog.
  • 30. Retrospectives• Increased openness and communication in projects.• Retrospectives gave a lot improvement ideas, some of which were realized later.• Improvements were taken in use quickly, but spreading them to other teams was difficult.• Shortening the feedback loop was seen as an important goal.
  • 31. Team work environment• Almost every company aimed at organizing the team to work close to each other in the same room• One company even demolished walls in the office to get the team to work close together.• Cubicles were also popular, but often shouting over a screen was necessary.• It was a major drawback if team members had to be distributed in different spaces.
  • 32. Distributed softwaredevelopment• Distribution was used in many levels: single team members were in different locations or teams from different locations were collaborating.• Distribution resulted in many annoyances, e.g. communication and cultural problems.• Tools couldn’t replace face-to-face communication.• Only one company was satisfied with their distributed way of working.
  • 33. Subcontracting• Subcontracting was used in one way or another in projects. Some companies were subcontractors themselves, others were subcontracting.• Subcontracted employees were often in same premises as the regular employees.• Employee turnover rate, strict work hour monitoring, communication and contract issues were challenging.
  • 34. Documentation• Documentation needs were often discussed with the client, and no irrelevant documentation was necessary to be produced.• Many used wiki-based documentation. Wiki was also blamed to be unclear or confusing.• Architecture level and interfaces were documented most often, other documentation was made according to customer’s needs.
  • 35. Scrum and quality systems• Six companies used ISO 9001 quality management system. Two companies used CMMI lvl 3.• Some were satisfied with the quality system, others told that it doesn’t affect the Scrum. Some didn’t even want to use them because they saw quality systems were difficult.• Scrum was also said to be lightening the quality management systems.• Quality standards are an advantage in public procurements.
  • 36. Definition of Done• The criteria were for instance: – Passed acceptance testing, completed code and documentation, passed unit tests, passed code rewiev, completed localizations or adequate test coverage.• Criteria was not always clearly defined with clients, so that everyone in the team and the client knew them.
  • 37. Tools used• Many companies wanted the tools to be as light as Post-it notes, but at the same time tools that enabled distributed working and possibility for backups.• Post-it notes and Excel sheets were the most used Scrum tools.• Some companies also used special Scrum software or self-made software.
  • 38. Scrum recommendations• Use your own common sense in adaptation.• Create your own internal training package to Scrum.• Organize monthly agile development bulletins.
  • 39. Scrum recommendations• Set a team size of 5-9 persons.• Make if possible for teams to self-organize.• Experts and novices balance each other in Scrum teams.
  • 40. Scrum recommendations• The direct manager shouldn’t be given the role of ScrumMaster.• Shorten the feeback loop with two week sprints.• Use a team sprint, where they can occasionally decide the spring backlog independently.
  • 41. Scrum recommendations• Make it possible to communicate through documentation.• Organize retrospectives lead by professionals.• Do not forget the architechture design or specification work in agile development.
  • 42. Scrum recommendations• Use test automation and build automation.• Keep the top of the Product Backlog always analyzed.• Poker planning is a fun way to do the estimates.
  • 43. Scrum recommendations• Do not distribute software development.• But if you anyway have distributed your team members or teams, you should regularly bring them to meet each other face to face.
  • 44. Scrum recommendations• Gather feedback regularly and observe the trend.• Measure customer satisfaction regularly.• Guide your interest groups in Scrum operations.
  • 45. More informationJyri Vuorinen +358 400 77 63 57jyri.vuorinen@gmail.com