Your Bastardized Version of SCRUM is Actually Harming Your Project.
The real power of SCRUM lies not just in its organization of daily tasks, but in its extraordinary prediction power. Sprints and standups are just a part of the equation. Stop blaming your butchered method for your late deliveries; stick to the rules and get ready to get your socks knocked off.
I love SCRUM. And for two beautiful years, I think I can say SCRUM loved me back.
A while ago, I was working as a UX designer for a software development company. Medical software, to be more precise. Two young developers had been given the rare opportunity to develop a new product from scratch and they were absolutely acing it. Locked in their think-tank (extra kudos for working ten hours a day in a tiny dark room inside an office that overlooked the ocean), they had read about SCRUM and were applying what they knew about it. The results were already extraordinary, so one day, out of the blue, the company decided to fly a colleague from London to New Zealand with the single goal of training the rest of us in the framework.
Like it happens with many teams around the world, what we were using was a bastardized version of SCRUM. A mismatch of rules we enjoyed and obvious absences for those we didn’t. We had standups, we had a backlog… and we worked in sprints. We also had several project managers, project owners, stakeholders, frequent ad-hoc requests and non-existing planning or review meetings.
Sounds familiar?
So, our guest planned this half-day training that included multitasking and prediction games, and we were ecstatic to be away from our screens (this is not relevant to the story, but we were interviewing people that week… and this poor girl who happened to be there had to join us, a bunch of overhyped IT people, overly confident in each other’s company, frantically trying to optimize processes using golf balls. Unsurprisingly, we didn’t hear from her again).
Long story short, the day was a success and, since the company had invested so much in bringing our trainer to Middle Earth, we were instructed to follow the framework to its last detail. And, boy, the adventure began.
Disclaimer: Beauty is in the eye of the beholder
SCRUM doesn’t work with every project, nor it does with every team. It could, potentially, but for the framework to really shine in its grandiosity the whole team needs to be fully committed to its rules and have a fluid willingness to polish the technique. Also, the whole team needs to be involved, which brings other advantages like more knowledge about your team member’s strengths. Perfecting SCRUM can take months, it can get frustrating, tedious. Questions arise, and that’s why the Retrospective meeting is so important, because it’s the place where this can be discussed. The Retrospective should also be the SCRUM Master’s field, where she or he should act as both framework leader and therapist. However, it is all worth it. I cannot repeat this enough. IT IS ALL WORTH IT.
Almost every single team I have come across since uses a watered-down version of SCRUM (at this point I have to apologize for the number of times you will see the word “SCRUM” written here. I’m really trying to use neutral articles.) As unproductive as it might seem at first to spend 10% of your Sprint in meetings, there is a reason for it.
Models are great. Frameworks are great. SCRUM is the one of the most stable, effective ones I’ve come across, but it’s also the most mis-understood and mis-used. And hated, too. But here’s a list of the most common pitfalls I’ve seen, see how many apply to you if you are currently using SCRUM (most of these would be ok generally, but I mention them only in relationship with it):
- Your planning hardly lasts the defined 8 hours per month (a good pace is 2 weeks sprints for a small team, a time-boxed 4 hour planning each.)
- Your daily stand-up lasts longer than 15 minutes, or it’s not unusual to have longer specification discussions where some or most team members daze off.
- The product owner doesn’t show to some or all the meetings, although he should be present at all times.
- There are frequent requests that need to be included and that are not in the original planning. Most of these requests are not discussed by the team.
- Spikes turn into new sprints, or sprints have to be lengthened.
- Sprints are excessively long, teams are excessively large.
That’s for the bad. Now, the good news. It is possible to use SCRUM effectively and become happier in the process. Here’s a little list of what is (based on my experience) required to execute a successful project.
1. Be ridiculously disciplined, especially at first.
If you want to get to the juicy part of SCRUM, the prediction, you need to play by the rules. And I guarantee you want to get to the prediction, because that’s where SCRUM shines.
To do this, meetings, time-boxed or not, need to be followed to the letter. Shortcuts kill the framework. You can do your own SCRUM,
“We do our own SCRUM,”
but the meetings serve a bigger purpose than managing work. It’s where the team actually becomes a team.
Every single thing in the manual is there for a reason. Stick to it, and you will see the results. Thanks to planning you will actually talk to your colleagues about… things. You will be constantly up to date with the development, and celebrate each delivery at the end of the sprint. Meetings don’t have to be tedious, I mean, of course they will always be meetings, but they are not more than what the team makes of them. The good thing about having topic rules (what you are supposed to bring to planning, or when your questions about how the team is doing can be asked) is that each question, each discussion has an assigned moment. Keeping the conversation focused on what’s at hand is probably the trickiest part of any team effort. A note: Sometimes it’s better to take mental note of the regular issues, and bring them up in the retrospective. It gets easier to talk about problems with the processes when you know that, according to the book, you are supposed to be doing it.
You can create your own version of SCRUM later, but you should master the original first, get to know its strengths and weaknesses. I… have to say, though. During our biggest project, and because we [were] fully [forced to] believed in SCRUM, we never ever had a late delivery. EVER.
2. Be willing to familiarize yourself with every single bit of a project.
When I joined my team, I was almost exclusively a UX designer. The peak of my programming knowledge was editing jQuery demos. Yet, by Sprint 4 or so, I was estimating effort and risk for database integrations. How on earth did that happen?
It all builds up from the Planning meetings. It’s generally recommended that the team doesn’t change much during a project, but what’s important here is that every member is present in the Planning, and every member participates in calculating efforts (assuming the person who maintains the backlog has filled in the required data: Description, acceptance criteria, and definition of done.)
You can do this in different ways, I recommend planning poker because it worked so well for us, and it’s fun. We printed decks with numbers (a modified Fibonacci sequence: 1/2, 1, 2, 3, 5, 8, 12, 20, 40,) and held the cards goofily hidden in our hands. After a task was explained, everyone would show, at the same time, a number that we felt represented effort the best.
For the first few weeks, our numbers differed considerably, which was actually quite positive because it forced us to defend our scores with actual justifications. It was very difficult at first, but as you watch others talk about their topics, you learn not just about the content of what’s being discussed, but the general methodology. You know that there is an acceptance criteria, the structure is usually similar. The most effective mental paths are patterns, you start learning about what other things happen in the product you are designing (or developing, or testing,) and that can only be positive.
A second, third or sixth pair of eyes is always helpful. A lot of hidden complexities are discovered in this way, the thing standing in front of you that you cannot see. As time went by, our scores began to align, and every difference meant a good point.
3. Be open and transparent.
What I mean by this is the following: In SCRUM, transparency is paramount. Nobody will stand over your shoulder making sure you are working on the card you just moved to the “In Progress” column, but because the planning is done in a group, you need to be honest (or very skilled) at defending your chosen effort score, and whatever you do will be written all over your velocity.
We never worked with hours, our Fibonacci was abstract. Effort 1 could mean a couple of hours or half a day, but we knew we could only do a couple of effort 8s in a sprint. The group determines the value in a strange pragmatic way — somehow, it works. This is important: The number is also supposed to reflect the risk, so if you are unsure about how exactly something will be done (even after you’ve discussed it at the Planning,) it means the task has a higher risk and should, therefore, have a higher score. You also have to keep in mind a task is rarely done in calm solitude, so it’s important to account for things like emails, research, coffees or foosball matches. Working with efforts and not hours makes the calculations more flexible. You know exactly what and when you are going to deliver a new version of the product.
SCRUM will make you work more effectively, it won’t make you work more. I always had the feeling I could do my tasks at ease, with enough time to go deeper into a problem but not so much that my mind started wandering or I got bored and lost in reddit. Problem is, SCRUM is quite transparent, so if you are towards the lazy side of things, this might not be great news. It could help you plan your laziness around tasks, though.
4. Be vocal.
Meetings are all about communication. Standups require you to be clear and focused. During Plannings, you will need to explain and defend your position, but standups are just a report and a quick alignment opportunity. Reviews thrive on honesty and focus on improving the product, and so do Retrospectives but they are only about how the team works.
If you do SCRUM right, apart from getting good at your job, you will rock at expressing your ideas, debating and critically analyzing your work. This is the first thing that sold the framework to me. The second comes next:
5. Now, chill and predict.
This is the main reason why I am a SCRUM evangelist: If you do it right, if you survive the creeping hours of meetings (in the beginning especially), the fear of giving scores for things that sound completely alien and the pressure of expressing what’s really in your mind, you will belong to a team that works like a damn clock. You might even have time to get inspired.
Anyone or anything can plan. There are several frameworks that can help you do it, with less or more success. The real power of SCRUM lies in its prediction abilities, and in this word I like a lot: VELOCITY.
It’s not just about working more effectively today, it’s about creating specific goals based on the real quantitative information that comes from using the framework correctly. Deliverables are essential for keeping a client informed and happy, and they feel great for everyone.
Having a realistic average velocity means knowing your team, your project, and your real skills. It means that you will be able to give REAL delivery dates, with products that are well-thought and polished, and that are working. That’s the real spirit of Agile, it’s not about improvinsing your way into software, it’s about working more intelligently. Rigorously.
In SCRUM, everyone works. But here’s the thing: Nobody OVER-works. It’s a common scene to have a pseudo-sprint from a pseudo-framework ending with half the team slacking and the other half being exploited to dust by their own conscience or others‘ lack. This is not what work, or life, should be like.
If you plan well, with your team, if you work with thought and honesty, and embrace that the place where you spend 8+ hours a day should be a place where you don’t feel miserable, SCRUM is a game-changer. Because once you see the results of the framework used properly, I promise you are never going back to whatever monstrosity was thrown into you. And then maybe you will be like me, overriding people’s freedom of framework in the name of the one and only: SCRUM!
What do you think? Is your SCRUM sinful? What’s your insight about the topic?
