After working with Scrum for some time, I’ve finally became a certified ScrumMaster (SM) at the zilverline course with Marco Mulder en Bas van der Hoek. Addtionally I met one of the inventors of the Scrum software development process. Jeff Sutherland at our company yesterday!
Scrum is like a homing missile
The old school and dreadful IT project style: The customer wants a new website and makes sure to write an extensive project plan beforehand. Better be extra detailed to make sure we’ll get this project right! The customer assumes the project is clear and believes that developers should be able to give a detailed and trustworthy scoping. Planning commences and the project starts. Within no time, unforeseen occurrences happen and the made promises are broken. Both parties eventually become more hostile towards each other and IT has to work overtime to finish and the customer isn’t happy with the final result. Sounds familiar?
The waterfall method described above is like a cannonball. The customer sets a target in the distance and the developers have one shot at hitting it with their cannonball. The shot is taken and is in vain as in fact, the target was moving and there was unforeseen wind, the outcome became clear when it was too late.
An alternative to this is the scrum approach. The empirical approach in which the customer is closely aligned to the developers, releasing software often makes that demands are discovered along the way. Customer happy, developers happy.
Whilst finding roots in software development it’s also applied at banks, healthcare and government around the world, in the Netherlands there’s even a high school applying scrum at a class, where students show increased collaboration!
Epics and roadmaps
I’ve experienced firsthand that trying to scrum a traditional waterfall/Gantt planning can create a lot of friction in an organization. It starts with acknowledgement that Scrum is nice and all but targets are made for an entire year, the ‘business side’ (as apposed to the IT side) should be able to get some commitments over the year.
This doesn’t mean that one should make a roadmap, we’ve learned that roadmaps are too messy of a prediction. A roadmap feels a bit like a large project. The chances of making it are small.
Source: Standish group
But… when will the project be ready?
You’ve haven’t even started with the project yet but usually the costs need to be made clear in advance, and marketing activities planned. Expectations have to be given. “When will you finish?” is a pesky question without a roadmap. This is where one needs to be clear. Scrum allows you to produce a realistic planning after some time of development. By reducing size of projects and always focusing on the single most important thing, you will deliver something quickly, and more can be said about the time left for the rest. Tasks are put on a backlog, with most important things in top an detailed. Abstract things for the future at the bottom.
Cone of Uncertainty
Finishing sprint after sprint, you will be able to estimate with more confidence. As you know how many storypoints you burn per sprint. Apposed to a long term development like waterfall, scrum will give quicker insight towards completion with a so called ‘release burndown’, showing how many storypoints are left. Additional tasks are added underneath the chart.
Going wide, not deep
Instead of a ‘island’ culture where one team passes work to the other, scrum teams are multidisciplinary and have full access, responsibility and knowledge of the architecture. Only then they are able to understand the why, how and what of the most important item.
Besides that, there can be only one thing important at the same time. People are terrible at multitasking, for a long time people assumed that if you started more, you’ll finish more. It’s the other way around, the more you finish, the more you’ll finish!
During the training, we made a storymap together. It’s an overview of tasks and time. Our task was to prioritize features. In the Image below, we were building the “bare necessity” row.
At first, we added all basic functions .The coach then challenged us and soon we realized that the bare minimum could be stripped a lot more. This was an eyeopener, as I’ve felt into this trap often in the past, thinking “I’ve started working on this anyway, might as well extend a little bit on this part as well.” NO! Work wide, not deep. Only then you can deliver fast. What is the actual minimal working skeleton? We also sheepishly added cards at every column, another team skipped even skipped columns for their first release. Why not?
Steady teams and performance
I joined the ScrumMaster training with some experience under my belt and a lot of questions regarding scaling and performance. Personally, I had to deal with proving increased output of the team this year and I was seduced to start micromanaging expanding time logging of the team. (Micro) managing isn’t going to get the best out of a team. Jeff Sutherland stressed that simply making work of a team transparent to outsiders is enough to get the team motivated and self steering. When all seems lost, decrease the tickets in one sprint and focus on applying the practices correctly. To increase performance is to keep addressing the next biggest improvement in the team. Dysfunction team members, dependencies on other teams etc. What scrum does is making the process quantifiable so you can break dreadful processes instead of trying to satisfy them more rigorously. Also don’t let the team get disturbed too often, “The door from the business to the IT team is closed, whilst the door to the business from IT is always open”.
A common mistake is of management to assume that adding member to the team will speed up the sprint. It’s usually the other way around. Scaling should always be done slowly. While growing, together with the ScrumMaster (SM), a decision can be made to divide the scrum team in two. Do not simply duplicate the disciplines with new hires in an all- new team. Instead, split the existing team. Make sure the independent teams are still able to complete tickets autonomously. At first, it’s still ok to do backlog refinements together. Later, you can allocate an own backlog and own PO when necessary.
Scrum of scrums
With different scrum teams in place, a scrum of scrum meeting may be implemented, addressing coordination across teams in a simular fashion as the conventional standup. Due to the content nature, it’s not uncommon to send the PO instead of the SM. Alternatively to the group just standing in one room, walk past all the teams and their scrum boards.
With a split team, the chief product owner can keep a scrum-team-per-lane overview with a so called “Epic board”, to helps to see inefficiencies and to plan future sprints together. When there are multiple teams, it’s advisable to plan demo’s after each other and together. Before the training, I read that Spotify implemented so called component teams, in which teams are allocated to various GUI components; one for the music player, another for the login window and so on. To facilitate this, technology needs to change the architecture. Component thinking could lead to double work between the teams but this is ok and a sertain isolated approach on similar things should be encouraged towards the team.
From the Q&A session:
Tips for increasing efficiency?
Let the team do a retrospective round on paper so everybody can give their opinion.
During planning poker, a discussion might occur. Sometimes it might help to end an argument with another round of planning poker instead of a guess from a few people.
‘Fist of five’ for commitment. Count down and raise a range from 1 to 5 fingers when you support the commitment.
Is a ‘research’ ticket a valid approach?
No. A research ticket is not part of work and should not be part of the sprint. A ticket should be completable within one running sprint.
What if you have dependence of a non scrum team?
When you know this in advance, the backlog item simply wasn’t ready and should be marked accordingly and as impediment. This has to be made clear to PO as quickly as possible. It shouldn’t belong at the top of the backlog, as it doesn’t have priority from the business. In that way, the SM is responsible for solving this situation.
Do you count the points of an unfinished ticket?
When a ticket isn’t finished in a certain sprint, do not count points for that ticket in that sprint.
Does the UX’er work in a ‘sprint zero’?
Sprint 0 does not exist. Sprint zero gives the idea that there is a phase where one doesn’t work. This is not the case. The PO and the UX’er have a secret side to the conventional scrum flow. Whilst the team is following the sprint, they already workout the tickets for the coming sprints. In that way they have a ‘secret’ sprint. A UX’er needs to find balance to work within the team, but also work ahead in making the UX foundations for templates before the sprint starts. If the UX’er does everything ahead of the sprint, the team cannot work together for optimal collaboration.
Should I create a second sprint to prioritize non-business things like IT?
get business priority for IT project. Remember to sell the problem, not the solution. Make sure that the BLI isn’t called ‘Varnish v4 upgrade’ but “Get our website to load within 200ms and increase conversion.” be clear about the results.
Tickets & backlog:
A nice way to avoid assumptions on the backlog is to create (abstract) user stories. Avoid assumptions by always asking why. It shouldn’t be possible that multiple items on the backlog are evenly important.
I found that some organizations are completely scrum. At ING bank, they do standups at every level of the organization starting bottom up. When there is an impediment at bottom, it should be answerable within 2 hours when top management has a standup._