Rune Lippert offers an update on the Scrum efforts at the leading Danish media group Jyllands-Posten (better known for their Islamic cartoons): ‹After a long process implementing Scrum in a distributed team and taking a few shortcuts/’optimizations›, we regrouped in the summer of 2011, and restarted a new team. We started following the Scrum guidelines to the letter, and it was a great success, so great that in the summer of 2012, we added new teams to the mix. Since then we’ve found that teams adapt to Scrum very differently and that your abilities as a Scrum Master is continuously tested in new ways.›
Jyllands-Posten’s team develops the journal’s websites. The web has become a business critical channel, hence the focus on improving the development team’s performance. 9 out of the 10 most busy Danish websites are provided by media corporations.
As per usual with teams Jyllands-Posten also has a core team that has been there from the beginning, new teams and people that look for new challenges.
The team is using Atlassian’s issue tracking tool Jira with the agility plugin Greenhopper. They estimate backlog items by story points but then during a sprint they track Jira sub-tasks that are not longer than one day tasks. This still allows for velocity tracking and according forecasts. Estimation is strictly separated from planning meetings at the beginning of a sprint. Retrospectives after finished sprints are paramount. Everything is visualised on walls and large screens.
‹Done› criteria need to be defined properly, especially when pursuing continuous integration with automated builds and deploys, automated tests and numerous deploys.
Jyllands-Posten uses two week sprints, yet sometime the planning still is way wrong…
The burndown chart sometimes can go very wrong, especially when new technologies are involved that the development team doesn’t know yet.
Jyllands-Posten looks to have a good flow, i.e. the skill set should be up to par with the challenge level.
Sometimes support or correction tasks creep into a sprint. This obviously hampers the velocity and the performance. But it’s normal. You need to visualise the time spent on these tasks in order to prevent issues with stakeholders like product owners or management. ‹Loosing› time on this type of issues may become very expensive from a business perspective.
Jyllands-Posten limits administrative resources during a sprint to 20 hours (time boxed approach). They do very compressed daily Scrums three days a day. It’s close to micro management but it also has advantages since no issues are pursued that don’t offer business value.
