The use of the Scrum method in IT companies

in Pirkanmaa areaM.Sc. Thesis, Jyri Vuorinen

Selected comments from the 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.

”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.

Selected comments from the 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

Selected comments from the interviews

Thesis based on an interview 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

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.

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

Demographics of the companies 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.

The benefits of Scrum method

• Team feels that working makes moresense and more motivating.

• A spring gives the team a possibility to seedevelopment regularly.

• Scrum offers a clear and simple enough way of working.

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.

The problems and challenges of 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.

• The deployment of scrum is challengingand time consuming.

• The Product Owner role is challenging. He doesn’t have time to invest on the project orhe 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.

The problems and challenges of Scrum method

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.

Nokia Test results

0

1

2

3

4

5

6

7

8

9

10

C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11

Company

Points

Average

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.

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.

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.

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.

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.

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.

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32

C1C2C3C4C5C6C7C8C9

C10C11

Company

Smallest and largest team size / employees

Sprints

• A few companies didn’t use Sprints, theyonly had a larger top-lead plan to follow.

• Sprint duration varied from two to four weeks. Twoweek Sprint were said to be most efficient.

• Longer Sprints didn’t work because the companiescouldn’t predict that long to the future and the workestimates were no longer accurate.

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.

Specifications

• Some companies did all the specificationsbefore any iterations.

• User stories and use cases were used more often thanstrict formal specification documents.

• Many of the interviewees emphasized that agilitydoesn’t mean that the specification work can be leftout.

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.

Product Owner

• The Product Owner role was hard to fit into the organization.

• Communication chain was either too short or too long.

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.

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.

Burndown Charts

• Burndown Charts were used in most of the companies, only three companies didn’t think it wasuseful.

• 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 teamknew it’s velocity and Product owner usedvelocity data in backlog planning.

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.

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.

Team work environment

• Almost every company aimed at organizingthe 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 bedistributed in different spaces.

Distributed software development• 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.

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.

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.

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.

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.

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.

Scrum recommendations

• Use your own common sense in adaptation.

• Create your own internal training package to Scrum.

• Organize monthly agile development bulletins.

• 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.

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.

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.

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.

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.

Scrum recommendations

• Gather feedback regularly and observe the trend.

• Measure customer satisfaction regularly.

• Guide your interest groups in Scrum operations.

Scrum recommendations

More information

Jyri Vuorinen

+358 400 77 63 57jyri.vuorinen@gmail.comhttp://fi.linkedin.com/in/jyrivuorinen