February 13, 2014 / by Henrik Niklaus / Software engineer / @

Suited scrum

Practicing scrum in real live projects is sometimes a tedious task. If you don’t suit scrum to your needs while retaining all basic principles you will probably fail. This snapshot of scrum practice at shopping24 reveals some of these required adaptions.

Our daily starts at 9:25 am. Usually our productowner is present and all in the sprint participating developers. Our daily is for all java developers (the so called “base team” at shopping24) and all guest developers from other teams. Hereby it is ensured that everybody is up to date concerning the state of all running java projects.

Burn down

One characteristic at shopping24 is our issue management tool. To be more exact we use nothing more than a whiteboard. Directly after the standup we update the burn down graph on our whiteboard to receive a perception of the current project status. The currently used graphs have evolved over time to now three graphs named total, not ready and to deploy.

• The total graph visualizes an important issue for us as usually the amount of stories rise during the sprint.
• not ready contains all stories which are in the backlog or are in progress.
• The to deploy graph is obviously the technichal dept.

Our Definition of Done (DoD) covers explicitly the live deployment of the story or task. Nothing is really done without a live deployment and therefore the verification everything is functional within a production environment.

We leave out the graph of the ideal burndown just to not get distracted by the whole amount of graphs in the chart.

Coffee

Coffee is an essential building block of our work as a developer at shopping24. Drinking coffee is like beeing a smoker in the old days. If you do not attend, you are not getting involved in the decision process of the important things ;). If you don’t like coffee you are lost or you choose a “Mate” from our stomachshop24 :)

Work

After the coffee break we search our pair and begin work on the story with top priority. The pairs are usually formed at the beginning of the iteration and last for the two weeks until the next review. Pair programming is another building block of our work. It ensures a better quality of the code and eases and supports the focus on the current task for all participants. Allthough we are completely committed to pair programming we nevertheless do not pair all the time. It is common to do some of the daily tasks alone, especially if the task is simple or the end of the day is close.

After completing the story we try to deploy it instantly. An automated continous deployment process is unfortunately not yet active but we are working on it :). The deployment is currently a manual task explicitly initiated by a developer. We nevertheless have a working continous integration chain in progress which includes integration tests and additionally some UI tests.

We have no process of a codereview integrated in our daily work. If the implementation of a story or task is noteworthy or questionable we mark that story with a ‘R’ for a wished review of the implementation and do the review at a regular team meeting later on.

If a story is very complex or its description too vague it is practice to discuss the story and its details beforehand with the whole team. Basic architectural decisions are also made together.

Quirks

Using no digital issue management or bugtracking tool at all - besides our analog whiteboard - implicate some real advantages:

• The productowner is forced to communicate with the team directly. If he wants to prioritize a story or if he found a bug he has to come physically to the whiteboard and talk to us. This prevents common misunderstandings while writing endless comments in jira tickets…
• The daily standup is simplified due to the direct visibility of current stories and their state
• You’ll get an immediate impression of a projects state by just looking at the wall
• Last but not least it is a very satisfying action to move a story towards the ‘ready’ or ‘done’ field on the board!

In contrast to scrum the amount of stories for an iteration may rise. Part of the cause for this is our vague definition of a story. A task and a story is defined to be nearly the same. The difference is actually not important for anybody. A task gets its own story card as does a story. During the iteration we often realize that the originally extracted stories are not exact enough or we forgot an aspect of the whole epic while planning the iteration. Some of these new stories are discussed with the productowner and some have only a technichal relevance. Although the amount of cards rise and the length of the iteration is not growing we almost always burn down all of our stories. Naturally not considering the technichal dept which is is sometimes shortly above.

There is currently no scrummaster for the base development team who assists the overall scrum process. We actually do not have the need for this position, as the process is near the optimum and every team member is activly supporting it. If there are still discrepancies e.g. between the productowner and the team, we still can access our team leader and/ or discuss the issues at the retrospective.

Result

The one and only scrum process appears to be non existent in real life. Every team has to search for its own version of an for them ideal scrum process. Technically this is one of the basic messages of the agile manifest namely responding to change over following a plan.