Going Agile With Scrum

A friend of mine, Aslıhan Hilal Uyar (Hilal Aslı), as part of her master study, wrote a paper on Scrum, one of very popular agile methods for software development projects, and how it is applied in Turkey. She first briefly explains what Scrum is and its main roles, artifacts, etc. and then with the help of Erdem Seherler, another friend of mine and an experienced Scrum master, she tells about the position of Scrum in Turkey and how it is applied in software projects. Here is the paper:

1. INTRODUCTION

As people and resources around them have changed, there has emerged a necessity to change also the way people work. Traditional methods could not respond to the needs of this changing world. It is this point where we started to face with agile methods. Although some ideas involved within “agile” have been around since 1970’s, they could begin attracting noticeably more attention only in 1990’s when they were harmonised with some new ideas to form what we call “agile” now.

Underlining the software development aspect of “agile”, the movement resulted in a number of agile methods some of which are Extreme Programming (XP), Crystal Clear, Scrum, Feature Driven Development (FDD).

In this paper we will talk about Scrum, which is a specific agile software management process, and have a look at how it is being applied in Turkey.

2. SCRUM IN GENERAL

Scrum is a structured agile approach for managing software development process. It indeed is a term in rugby describing the situation in which the whole team tries to reach the goal altogether through concentrated team effort. Its foundation roots in the Japanese manufacture industry.

Scrum enables the customer to prioritise the work to be done and the developers to conform to this priority. It is both iterative and incremental. Projects proceed through a series of small iterations called sprints, which are time-boxed at the start of the project and are no more than a month long. At the end of each sprint, the work done in that sprint is delivered to the customer.

Two important factors that give Scrum its strength are:

• Team Empowerment: Find good people, let them do their job and delegate responsibility to them. This is what team empowerment imposes. The team in Scrum is self-organising, managers do not tell the team members how to do their work. Or a leader does not tell a member to write codes and another to test. It is all up to the team how to fulfill the assigned tasks.
• Adaptability: Scrum draws a framework which mostly underlines the basic rules instead of giving detailed specifications of how these rules will be implemented. So it permits adaptation to some extent: It is adaptable to changing environments. You should adapt it to your own organisation to get satisfying outcomes, of course without destroying the basic concepts. The important thing is that you should not make it a disordered structure which is not Scrum any more.

Now we will have a look at the roles, artefact, and activities in a Scrum project and identify some important terminology related to Scrum.

2.1. MAIN ROLES IN SCRUM

There are three main roles in Scrum:

• Scrum Master adapts Scrum to fit the project and the customer best, coaches the team to get highest level of performance and ensures that problems are getting solved. He makes sure that the work is delivered with the highest quality possible. He indeed is a facilitator for the entire project.
• Product Owner indeed represents the business, the stakeholders. He prioritises the product backlog, which will be mentioned in Part 2.2.
• Scrum Team is the core team which grows the software. Generally there are no role names such as programmer or tester in a Scrum team. The team is empowered and it is self-organizing in that no one says who will do a particular task. It is up to the team how a task will be fulfilled.

2.2. MAIN ARTEFACTS OF SCRUM

There are 4 main artefacts in Scrum:

• Product => The main artefact of a Scrum project is certainly the product itself. The team should make the product ready to be delivered at the end of a sprint.
• Product Backlog => It is a complete list of  feature requirements to be added to the product and is usually in the form of user stories to enable the product owner to fully understand what is being mentioned. Thus, it is better prioritised by the product-owner, enabling the team to work initially on the most significant features.
• Sprint Backlog => It is a list of  features to be delivered at the end of a sprint. It is prepared at the beginning of a sprint.
• Burn-Down Chart => It has two types: Sprint Burn-Down Chart shows the tasks left to be performed until the end of the sprint whereas Release Burn-Down Chart shows the tasks left to be performed until the release.

2.2. MAIN ACTIVITIES OF SCRUM

There are 4 main activities in Scrum:

• Sprint Planning Meeting => It is the first activity in a sprint. In this meeting, the team and the product owner talk about the Product Backlog items of highest priority. Team members decide on how many of those items can be fulfilled within that sprint and create the Sprint Backlog.
• Daily Scrum Meeting => It is performed on each day of the sprint and lasts no more than 15 minutes. Participants talk about the tasks done and problems faced the previous day, and what will be done in that day. It is a tool to increase communication between team members, product owner and Scrum master.
• Sprint Review => It is performed at the end of each sprint. In this meeting, what has been developed in that sprint is demonstrated, thus enabling feedback from all the participants some of which are the invited guests such as stakeholders. Within this meeting, Product Backlog may be revised.
• Sprint Retrospective => It is performed at the end of each sprint. All team members, Scrum master and product owner participates in this meeting and they review the team’s performance for the last sprint to prepare for the new sprint.

3. SCRUM IN TURKEY

Scrum is rather newly getting known in Turkey. Although there is still a long way, the job advertisements related to Scrum is slowly increasing in number. As it becomes more popular, more companies will seek to adopt Scrum, with no doubt. Here, the necessary conscience about the method has to be built in and around the organisation. Training is crucial to the improvement in results. It may be provided by external courses or as inter-corporate training. Thus, all people involved in the project gets a better understanding of what is tried to be achieved with Scrum. If you are forming a new team, training to be given to Scrum master and Product Owner should be about their role and responsibilities and for team members about estimation and daily activities.

The biggest difficulty faced when applying Scrum in Turkey, excluding the lack of knowledge and training, emerges about support of management. For instance, it is a Scrum Master’s duty to remove impediments on the way ahead of the team, making it very important to get management support. Removing impediments certainly necessitates a strong communication. You should establish the necessary conditions to optimise communication and widen your area of effect.

As far as my interviewee knows, there are no Turkish software solutions to support Scrum projects in Turkey yet. But there are some people with this intention. Before, most of the Scrum documentation was implemented through post-its, boards etc. Later, it became possible to use Microsoft Office applications such as Word and Excel, and then Jira (an issue tracking product) with Greenhopper (a plugin for Jira) on for the same purpose.

If we talk about the difficulties of applying Scrum in Turkey:

• Project or product development sponsors’ lack of knowledge in process may cause trouble since it will exaggerate the expectancies and do no help in removing the impediments.
• Project or product development sponsors’ insistence on “Fix Scope” may cause another trouble with regard to “Fix Time Fix Budget” concept. As sprints are time-boxed, “Fix Time” is okay. Since who will work in the project is determined at the start, “Fix Budget” is okay as well. Then the only constraint that might be changed is scope. Customers want to satisfy their “Fix Scope” with a “Fix Budget”. In fact they should enforce the scope items which are the most valuable and can be performed in the sprint.
• Another problem occurs when the customer does not adopt the Product Owner role and so does not exist in the project team as the Product Owner. Since the Product Owner has to prioritise the Product Backlog and represent the customer in general, his nonexistence may cause serious problems in project progress. As communication level will decrease, Scrum may not be able to fullfill the expectancies.
• The team should have the same understanding of what should be accepted as “done”.
• Beyond all, the establishment of mutual trust is another difficulty.

If the project and product development sponsors have sufficient knowledge on the process, we may talk about some benefits of applying Scrum:

• It is easy to manage change through Scrum.
• Meetings with the Product Owner let him observe and follow the project apparently and transparently.
• Scrum is beneficial in terms of defect prevention. As told in software-related books, defects result mostly from misunderstanding – or not understanding at all- the requirements. Since both the one demanding the requirement (PO) and the ones building it participate in meetings from the beginning, communication gets stronger reducing misunderstandings to the least and ensuring that the team gets the right point.

Let me exemplify the topic with 2 Scrum projects implemented in Turkey. Due to privacy issues, project or company names will not be mentioned.

• Project X: Team consists of 5 people. The sprint length was determined at the beginning but because of the change in both development demands and backlog content, sprint length varies for every phase and time-box structure can not be applied successfully. Although daily meetings are held regularly, we can not tell the same for all other meetings.

• Portal Project: Team consists of 7 people. All meetings are held regularly. The Product Owner follows the Burn-Down Chart and participates in all meetings. Because of defects, work can not be finalised within the planned interval but as the efforts are seen transparently, re-planning is implemented with the customer.

4. CONCLUSION

Scrum enables a flexible management structure for software projects. Daily Scrum meetings provide transparency and a high level of communication between all parties. By the time the corporate conscience about the topic gets built, more successful results will be acquired by applying Scrum. For Turkey, there is a long way to go, but shorter than before. As the project and product development sponsors get more knowledge and experience on the process, positive examples will increase in number.

5. ACKNOWLEDGEMENTS

I would like to thank Akın Kaldıroğlu for connecting me to the right person who can answer my questions, and being that right person, Erdem Seherler for his valuable answers about Scrum practices in Turkey.

References

Anderson, David James. Agile Management For Software Engineering: Applying The Theory Of Constraints For Business Results. Illustrated ed. Prentice Hall PTR, 2004.

Charvat, Jason. Project Management Methodologies: Selecting, Implementing and Supporting Methodologies and Processes For Projects. Illustrated ed. John Wiley and Sons, 2003.

Cohn, Mike. Succeeding With Agile: Software Development Using Scrum. Illustrated ed. Addison-Wesley, 2009.

Cohn, Mike. User Stories Applied: For Agile Software Development. Illustrated ed. Addison-Wesley, 2004.

Cooke, Jamie Lynn. Agile Principles Unleashed: Proven Approaches For Achieving Real Productivity Gains In Any Organisation. 1st ed. IT Governance Ltd, 2010.

Haugan, Gregory T.  Project Management Fundamentals: Key Concepts And Methodology. 2nd ed. Management Concepts, 2011.

Jones, Capers. Software Engineering Best Practices: Lessons From Successful Projects In The Top Companies. Illustrated ed. McGraw Hill Professional, 2009.

Pries, Kim H. and Jon M. Quigley. Scrum Project Management. Illustrated ed. CRC Press, 2010.

Stober, Thomas and Uwe Hansmann. Agile Software Development: Best Practices for Large Software Development Projects. Illustrated ed. Springer, 2009.

Toplam görüntülenme sayısı: 2913