Scrum-based Translation
Introduction
What is Scrum-based translation? A translation team that works with Scrum frequently releases portions of translated Scripture. This makes it clear to involved parties where the translation project is going. It enables the translation team to make course corrections based on the facts. Burndown charts and the product backlog provide the product owner and others with a permanent overview over the translation status and progress. Scrum is an agile process that enables self-organizing translation teams to deliver high translation output and accuracy in a short time. Using iterative translation, it releases portions of translated Scripture every iteration, say, every month. At the end of the every sprint, anyone can see the translated portion, and decide whether to release it to the congregations and community for feedback or continue to enhance it.
The introduction and the following explanation just outlines the mechanics of Scrum-based Translation. It does not make clear what difficulties and issues you will run into trying to implement it. It only hints at the agile spirit that’s required to make it work. If you’re interested in implementing Scrum-based translation, do some reading, watch videos, follow a course, find a mentor or coach.
Product Owner
The Product Owner represents the stakeholders. He or she is the voice of the target audience, that is the Bible reader. He understands the requirements for the Bible. The Product Owner may also be a group of people in a committee.
He is responsible for ensuring that the team delivers accuracy and reliability to the Bible translation. He knows about accuracy and reliability.
He defines items that focus on desired features. He makes decisions as to whether to implement footnotes or leave them out. In the same way, he defines other features, like headers, introductions, or decides to leave them out. He decides about use or non-use of a dialect.
He sets the priorities for the work to be done. He adds the items to the product backlog.
Scrum teams should have one Product Owner. The Product Owner may be part of the Translation Team, but it is recommended that his role not be combined with the role of Scrum Master.
Release Planning
The release planning shows which parts of the Bible will be translated and delivered during which Sprint. It is convenient to define a Sprint in months, so that the release planning mentions January, February, and so on.
It is often helpful to stick the release planning to the wall so that everybody can see the grand picture.
The advantages of a release planning are:
1. It gives the team a common vision about what needs to be achieved, and when.
2. It guides the team to make decisions during detailed planning.
3. It helps prioritize the actions.
4. It resolves conflicts and guides the teams toward the right balance on trade-offs.
Release each completed Bible book to the community and get their feedback. This implements the important principle of continual improvement.
The release planning is a simple way of doing top-down planning. It is an estimate, simple and quick to do. It is based on the Product Backlog.
Product Backlog
The product backlog is an ordered list of requirements that is maintained for the Bible translation. It consists of translation tasks, checking tasks, testing tasks, comprehension tasks, whatever needs to be done to deliver a reliable manuscript.
The Product Owner prioritizes the items on this list. It is used to determine the work for the next sprints. Each item has an associated estimated time to complete.
Sprint
A sprint typically takes one month.
This is where the translaton work (translate, review, approve, test) occurs.
Each member of the team translates independently and in a responsible manner. In case a translator is sure of a required change, he enters it without consulting others. If a translator thinks a proposed change needs discussion, he notifies his colleagues.
All members of the translation team review the changes made by the team. This is to make sure that all changes are reviewed by all members, that no mistakes occur. The reviews take place every day.
This way of working is based on personal responsibility and mutual trust. It speeds up the translation procedure because there’s more actual translation work going on, and less discussions. The newer members of the team learn from the more experienced ones through the daily reviews.
Bibledit has the concept of daily Change Notifications. A member can opt to receive the Change Notifications through email. This email can be viewed online also. Or a member can opt to have the Change Notifications generated for him online, and can review and approve them there.
Sprint Planning Meeting
During this meeting the team selects the portions to translate, review and test it believes it can commit to in a sprint.
The team breaks the portions down into tasks and provided estimates for those tasks as to the time it takes to complete them.
Sprint Backlog
The sprint backlog is a list of tasks to be completed in a sprint. The tasks are created by breaking down the product backlog items during the planning meeting.The tasks have estimates in hours or days associated with them.
For a team it is vitally important to have a clear goal to work towards. Thus everybody is focused on the desired outcome, and keeps a good pace. Without a clear goal, the team may still do a lot of things and work hard, but the produced results may not have the desired value.
Team
The team consistes of the Bible translators, their assistants, and the consultants.
The team organizes itself to carry out the work and deliver a reliable and good Bible translation.
The team is quick but does not hurry. The team goes fast, but always has an eye on translation quality.
Scrum Master
The scrum master organizes the translation process.
He or she keeps track of the progress of the translation team.
He removes obstacles from the path of the team.
Daily Scrum Meeting
On each day of a sprint, the Bible translation team holds daily meetings. These meetings are called: Daily scrum meetings. The scrum meetings are held in the same place and at the same time. The meetings are typically held in front of Task Board. The daily scrum meeting is best held in the morning, because it assists in setting the context for the work of that day. During the meeting, all members stand, as this keeps the discussion short and relevant. The scrum meeting is strictly time-boxed to 15 minutes.
There is a difference between people who are ‘committed’ to the Bible translation project, and those who are ‘involved’ in it. Scrum affords special status to those who are committed. Many teams enforce a rule in which only those who are committed are allowed to talk during the daily scrum meeting.
All team members are required to attend the scrum meetings. The Scrum Master and the and Product Owner (usually the Bible Translation Manager) are committed team members. They are expected to attend and participate. Anyone else, for example a Church leader, a Committee member, or a Translator from another team, is allowed to attend but is there to listen only. This makes the daily scrum meeting an excellent way for a scrum team to disseminate information. If you are interested in hearing the status of the project, attend that day’s meeting.
The scrum meeting is not the place for solving problems or resolving issues. Issues that are raised are usually dealt with by one or two team members immediately after the scrum.
During the daily Scrum, each team member answers the following three questions:
1. What did you do yesterday?
2. What are you going to do today?
3. Are there any impediments in your way?
The Scrum Master asks each team member to answer these questions, the member speaks, the Scrum Master thanks the member, and then goes to the next member.
By focusing on what each person did yesterday and will do today, the team gains an understanding of what work has been done and what work remains. The daily scrum meeting is not a status update meeting in which the boss is finding out about who is slow in his work. Rather, it is a meeting in which team members make commitments to each other. If a translator says: Today, I will prepare chapter 10 and 11 of Matthew, everyone knows that in tomorrow’s meeting, he will say whether or not he did finish. This has the wonderful effect of helping a team realize the significance of these commitments, and that their commitments are to each other, and not to anyone else.
Any impediments that are raised in the daily scrums become the Scrum Master’s responsibility to resolve as quickly as possible. Typical impediments are:
1. My … broke and I need a new one today.
2. I still haven’t got the … I requested a month ago.
3. I’m struggling to understand … and would like to discuss it with someone.
4. The … has asked me to work on something else for a few days.
In cases where the Scrum Master cannot remove these impediments directly himself, he still takes responsibility for making sure someone on the team does quickly resolve the issue.
Every day a different person leads the daily scrum meeting. This gets the entire team involved. It opens up new channels for communication. It builds trust between the Translators and the Scrum Master. Team members can learn from one another’s techniques. The Scrum Master ensures to set a good example for leading the daily scrum meeting.
The scrum master uses the information from the meeting to update the burndown chart illustrating progress.
Side conversations are taken offline.
Burn down chart
A burn down chart is a graphical representation of work left to do versus time. The outstanding work is on the vertical axis. The days of the sprint are on the horizontal axis. It is useful for predicting when all of the work will be completed.
Sprint Review
The Product Owner looks through the sprint’s work and provides feedback.
The Translators may demonstrate features.
The Team owns up to deficiencies with the translation.
This attitude helps to build trust with the Product Owner.
Sprint Retrospective
The Team reviews what went well and what went poorly.
They use retrospection techniques to find potential for improvement.
They pick one or two areas to focus for improvement.