Scrum Sucks! Part 7 – The Schedule


Everything happening at once

This is a poorly stated concept and a phrase that must die if we are to move forward with Scrum as a viable development technique. There is in fact an order to things. We can’t put the cake in the oven before we mix the ingredients, and certainly not before we have preheated.
Every structured process that I am aware of requires that certain events occur before others, Scrum is no different.

We are going to discuss what I believe to be a reasonable order with minimal downtime for all parties involved. We will also discuss what I think you should be doing with your downtime during the course of a sprint. Don’t get me wrong, this is not waterfall, many things can be going on at the same time. They just don’t start at the same time. Next time you have an opportunity, look at a running race track. All of the racers start at different locations. The inside track must start the furthest back while the outside tract seems to start way ahead. This is because the track is curved and the curve on the inside track is much shorter than the curve on the outside track. The starting points have been adjusted to keep things fair.

Track Lane 1, The Inside Track

Similar to the inside track for racing, Requirements must start further back. Most teams acknowledge this fact. No one seems to argue about it either, so I’m not going to spend a lot of time talking about it. The only caveat that I have is that the backlog must be forever prioritized. We don’t have to worry too much about the accurate priority of backlog items for 3 sprints from now, they are still being worked on and are far away from now. But items intended for this sprint and the next sprint must be prioritized at all times.

Track Lane 2, We must agree before we can start

Deciding what stories the team can finish is the next thing that needs to happen. If this is your first sprint, this process is a shot in the dark. If, however, you are a seasoned team, then this process should go fairly smoothly and be more or less accurate. I believe that is is better to load a sprint slightly under capacity. I know this goes against so many peoples nature. I’m sure some of you are horrified that I would suggest actually planning to work at less than 100% efficiency. Let me explain, developers are a strange bunch, we typically don’t write 3 or four drafts of our code before saying it is done. If the tests pass, the code is done. Not everyone even bothers to test their code, so, if it is written it is done. We need the extra time and encouragement to go back and look at the code that we have written. Only then will we realize that it looks terrible. If we have enough time we might even refactor it a little and try to make it better. Being under the gun of a deadline makes us rush. It makes us sloppy and careless. It is much better to schedule slightly under capacity and ensure the highest quality of code we can get out of the team. I believe that poor code quality is more costly than any delay caused by the team not working to full capacity. Also, cleaner code is easier to work with, easier to refactor, and easier to debug should something go wrong.

Okay, sorry about that little tirade. This stage must be complete before any other sprint stage can happen. Sure, you could have the next stage happen before this one. I think the problem with that though is that the designer might design for a story that never gets accepted.
It is possible, that the designer would design for a story only to find out that the stories are being worked on in a different order. That order change could affect how the designer would have done things. I want to make it explicitly clear, I’m not a designer. I do know how the creative process works though, and seeing the finished product of one piece of an application could certainly make you rethink how you design the next piece. What I’m trying to get at here is that we don’t want to waste effort so this phase needs to happen and the sprint needs to be locked in before we continue to any other phases.

Track Lane 3, Just a drawing

UX needs to be broken into two distinct parts, there may be more parts than this but at least these two. Before development can begin, a sketch based mock must be created. This mock is only representative of layout and some design elements. The only design elements that should be included here are basic. Using a textbox or a dropdown, relative sizing of text, and general grid type layout. This is all the developers need to start work and so it is all we should give them. These sketches take moments to create and can provide a quick launch to the sprint.

While they need to be done quickly, so the developers can start, there is no reason that the design decisions made must be final. Honestly, whatever design decisions the UX person(s) should want to make can be aloud at any point in the sprint. Right up to the sprint danger line.
Every sprint has a line of change that must not be crossed. It is that line where if you make any more changes you are putting the sprint in danger. If your team is using source control, and you better be, then the developers can work on changes right up to the sprint demo. These changes may not make this sprint, but if they are valuable changes they could always make it into the next sprint.

End of the line

Well, I’ve hit my words per post limit again. Look for the next article where we will continue this discussion and I will cover the rest of the track lanes for a sprint. As always, I hope you have gotten something out of this post and I welcome any and all comments. Thank you for reading.


Please Consider Sharing This Post:

FacebooktwitterredditlinkedinFacebooktwitterredditlinkedin