Using Scrum at subshell
This post is about how we at subshell organize our software development using the agile methodology “Scrum” and how we adjust our interpretation of Scrum to our own requirements. After 80 sprints, Scrum meanwhile structures working life at subshell into two-week-sprints. One sprint starts with a Sprint Planning Meeting and ends with a review and a retrospective.
Preparing the Backlog
Our Backlog is a simple OpenOffice-Calc sheet with a ranking of tasks, sorted by priority. We update the Backlog after each sprint. During the sprints we collect lots of findings and information from multiple sources e.g. concept meetings, our product development, consulting of our customers and bug reports.
Although we have a clear plan for the current and the next release, the fact that we want to organize the entire work for the development team in one sprint, has the effect that there are lots of different things to take into account. Beside nice new features for Sophora or Toromiro there are other things to do, for instance new features for our website, Sophora training, consulting for our Sophora customers, installation of new releases for customers with special support, improvements of our build process or working on our own technical infrastructure.
Hence between two sprints we have a short meeting to collect all the tasks for the next sprint. This meeting is open for everybody how wants to bring in a task. In this meeting we try not to discuss any details of the task. We just collect the tasks and sort them by priority. The result is the Backlog for the next Sprint Planning Meeting.
Sprint Planning Meeting
The Sprint Planning Meeting starts on Monday at 10 am and lasts at maximum until 5 pm. Usually we complete the meeting at 3 pm. Because a 6 hour meeting is no bed of roses, we use to have 15-minute-breaks every 60 minutes and a two-hour-lunch-break from 12 am to 2 pm.
At the beginning of the Sprint Planning Meeting we calculate how much work is likely to be done during the next sprint. Therefore we count the number of days each member of the team will be available and multiply the sum by our focus factor. Currently we calculate with a focus factor of 50%. The focus factor reflects how focused and concentrated we work. It is the velocity with which we proceed the work through the sprint. The relatively low focus factor is the tribute to the fact that the team has to do product support for our customers during the sprint.
We go through the tasks in the Backlog one by one and estimate the time it needs to complete them until we have as many tasks as fit into the sprint.
Each task is presented by the Product Owner or a developer. In case there are questions, they are discussed until everybody is able to evaluate the costs of the task. If necessary, we split the tasks into subtasks. We only accept tasks that take three days or less. For the estimation we play “Planning Poker” (http://en.wikipedia.org/wiki/Planning_poker). Planning Poker is a consensus-based technique for estimating. Planning Poker can avoid the effect that especially strong personalities influence the estimations of others. This effect is called anchoring. Our deck uses the sequence: ?, 0, ¼, ½, 1, 2, 3. In case the estimation indicates that a task takes more than three days, we split it into smaller pieces and estimate them again.
We think, it is very important for each sprint to has a goal. A goal is like a magnet that adjusts all tasks and prescribes thereby the way which has to be gone to achieve the goal.
The output of the Sprint Planning Meeting is the sprint backlog. After the Sprint Planning Meeting we first ensure that there is a JIRA-task for each entry in the backlog. Then we visualize the sprint on our big glassboard. For each task we print a DIN A5 card that tells the priority, estimation of effort, title and description of the task.
Our sprintboard has the sections “aufgaben”, “termine”, “in arbeit”, “review”, “test”, “abnahme”, “merge” and “done”. We have configured the corresponding status in JIRA. At the beginning of the sprint, each card hangs in the section “aufgaben”. During the sprint, the cards move to section “done”.
When we started with scrum, our scrumboard only showed the sections “aufgaben”, “in arbeit” and “done”. We have added the sections “review”, “test”, “abnahme” and “merge” one by one.
One reason for adding “review” was the lack of acceptance for pairprogramming in our team. Anyhow, there was a consensus that beside the author at least one other developer has to read and understand each new or changed line of code. The entering of reviews is our reaction to this situation. And it works just fine. In addition to that, the reviews have raised the quality of code.
Nevertheless, there were too many bugs in our releases which caused lots of repair work and therefore retarded our development of new features. The obvious conclusion was that we have to do more and better testing. Hence we have established the section “test” to our scrumboard and have backed it up with own personnel. This has definitely raised the quality of the software and reduced the number of bugs.
The approval finally is an overall check of the implementation of the task. This includes especially the check if the implementation of the task fits into the entire concept of the particular product. If not resolved by now, in the approval at the latest it will be asked whether the ticket has to be merged in previous releases. If a merge is necessary, the card will move back to “review” afterwards.
On the Scrumboard, our Burndown Chart which informs us about the progress of the sprint is additionally displayed. The Burndown Chart shows everybody who is interested the condition of the sprint. In our blogwe have described how we automatically calculate and visualize the Burndown Chart.
Every normal working day starts at 10 am with the standup for all of us. Who comes latest, starts with reporting what he or she has done the day before, what kind of problems he or she has and which task he or she wants to tackle today.
Afterwards everybody starts with his or her chosen task or search a partner to work together.
Sprint Planning Meetings and insufficiently specified functions
Years ago, when we start using scrum, we had some annoying problems in the sprint planning meeting with underspecified task. Have you ever tried to discuss how to implement a really complex task with about 15 people? Don’t do it. It leads to nothing but long and frustrating meetings with no results.
After we had tried it for some times, we decided to stop a discussion immediately after a few minutes of fruitless debating. In these cases, we now only plan the specification and conception of the task for the current sprint, but not the implementation. The implementation costs cannot be estimated until we know what we have to do anyway. We only accept tasks that can be estimated in the sprint planning meeting. The implementation will be planned at the earliest in the next sprint planning meeting - after the task has been specifiedThis strategy causes an obvious problem for the “Product Owner”: He cannot be sure that a high promised feature will be implemented in the next sprint. But meanwhile it is commonly accepted that this strategy is without alternative, and even the Product Owner has learned to cope with it. He schedules complex or potentially unclear features as early as possible or tries to resolve dubiety upfront.
And in the rare case that the future of the company depends on one special “killer feature”, we have the opportunity to exchange an unplanned task against another normally planned task of the sprint, which then of course cannot be released in the same sprint.
How we keep a constant workflow with Scrum
Another challenge was to uphold a continuous workflow during the sprint and to avoid jams at neuralgic steps in our process. Due to our Scrumboard, we recognize jams very clear, because they appear as amassments of cards. Very prone to jams are the sections “review” and “test”.
A typical sprint with jams in the review has the following characteristic: Tasks will be completed during the first half of the sprint, but do not get into the review continuously. As a result, in the second half of the sprint there is a heavy jam at the step “review”. Now an alert developer points to the mess. Thereupon everybody concentrates on making reviewsand finally – but too late - the bulk moves on to “test”.Another behavior pattern that as well leads to a jam during the test phase near the end of the sprint is a common phenomenon called “sprint end panic”. At the end of a sprint, the developers try to solve or review all the remaining tickets. Mostly they don’t make it completely and of course not in the necessary quality. Now the testers find lots of bugs and reopen the tickets. But meanwhile the sprint is over and the corrections cannot be implemented. What remains is a big mess: Lots of started and not completed work that has to be taken into the next sprint.
This situation is unsatisfying and discouraging for all. And that is obviously no good omen for the next sprint in which it normally does not get better.
What have we done against jams?
Surprisingly we haven’t reached the main improvement of our flow by an explicit change in our process or on our scrumboard, but in the sense of scrum.
We have studied the concept of Kanban (http://en.wikipedia.org/wiki/Kanban_(development)) as well. We tried to introduce limits to the sections, but this simply doesn’t work for us. It is not useful to artificially reduce the work in progress in a heterogeneous team that has to work on thematically different tasks. Taking the limits seriously would lead to idleness for some members of the team. To avoid this, they actually start working on their tasks, but hide it by not moving the respective cards to the section “in process”.
What brought the most noticeable effect was discussing the problem in the retrospective. The team by itself recognized that jams are an extreme impediment and that work is more fun when there is a steady workflow throughout the sprint.
After all members of the team have been sensitized for this problem, they now make sure that no cards accumulate anywhere on the scrumboard. The awareness that a constant workflow has its own value in combination with the visualization of the sprint progress on the scrumboard finally has led to the prevention of jams.