Six Things That Make Scrum Great

I wrote a post about how there are many things I don’t like about scrum.  But I do like scrum in general. There are parts that I may not like about it, but nothing is ever going to be perfect. I’ve seen a few different approaches to scrum, and it has evolved since I first started doing it seven years ago.

Scrum is a framework intended to help prioritize tasks and improve teamwork. Through communication, better estimations, and feedback, the process of completing tasks is supposed to move quicker as time goes on. Scrum is used primarily in the software development world, but I’ve had it applied in the accounting and marketing departments. There are also stories of many other projects that are not software based that have had scrum applied.

Scrum is easy to understand

Even if you’re not familiar with the scrum process, or you’re new to it, you can contribute and understand what is going on. With a little bit of training, you can understand the roles and expectations everyone involved. Take a look at a chart, the task board, or attend a stand-up and you can get a good idea of what is going on.

Break downs

By going through the planning of a story, I believe you’re actually starting your work! I’ve always been a big fan of planning. In college, I had to account for nearly every minute of my time a week in advance so I could make sure I knew what I could accomplish. When you task out a story, you’re breaking the story down. You’re making a plan, and the team can say, “You’re on the right track!”
I like seeing things organized in a way that I can categorize them. The smaller the compartment, the easier it is for me to understand and accomplish. It helps prevent me from getting overwhelmed which I have done so often in the past.

Task Boards

Physical task boards are the best! When I’ve seen the task board at its most effectiveness was when each person had their own color post-it and had to get up and physically move the post it to the done column. There is something in your mind that makes you feel good when you physically can move something. However, now I always work on a team where we need a virtual task board. On the surface, it serves the same purpose but I don’t find it as satisfying.

The task board allows anyone walking by to silently take a glance and answer the question of “What is the status?” I hate that question. The task board will tell anyone exactly where developers are at and you don’t need to interrupt.

Stand Ups

I can get caught up in my own world. I can get so focused on a story that I lose sight of what the rest of the team is working on or struggling with. When I am operating at my best, my headphones are on, and I will forget that I’m around others. This means I don’t interact with anyone. I prefer it this way.

Stand ups force me to look at people, gather around the task board and listen to everyone speak. They can ask me a question, or I can help them out if I see something going on. The best part is that it is limited to 15 minutes! Of course something can come up that isn’t stand up appropriate and we would talk right after.

Projections 

I like looking at projections. I like knowing, “On February 28th, we should be done with our project. It becomes a competition for me because I want to then say, “Ok, let’s see if I can finish by the 21st.” It becomes an interesting game for me. This creates an internal challenge.

Projections also allow management to plan around the development team. I have yet to see a better way of setting up projections in software development.  If the product owner wants tax calculators to be done by April 15th, set the priorities, do some averages, draw some lines and you should be done.

You even have projections in just an individual sprint. “Can I earn myself an extra day of training by finishing early? Let’s try.” Projections tell you when there are problems, or when things are going well. As long as your team is honest, and thorough with their estimations, there can be a lot of great things to be done with the projections one can generate from the scrum process.

Faster Turn around

When you can deliver part of the software, you should deliver it. You’re going to get reports of inefficiencies, or bugs in this process sooner. The sooner you get feedback, the easier it is to make adjustments. From a development standpoint, this is ideal. There is nothing more frustrating than finding out that you built features based on a misunderstanding.

Clients are also happier because they get to see their product sooner. They’re spending resources and they finally get to see what they’re spending money and time on. Compare that to waterfall, where there is a big bill and they don’t see anything for a long period of time. Usually waterfall involves a dispute at the end as well.

My favorite parts of scrum involve transparency. The organization is there for everybody to contribute to and observe. There are bunch of great things about scrum. These are just a few of my favorite things that I like to take advantage of.

Scrum is great, but...

I like scrum. The ability to shift direction of the product relatively quickly is valuable. I think there is a lot of merit to the idea of a product that is shipped regularly. Perhaps the biggest advantage of scrum is the early feedback. Nothing is worse than getting something, and realizing it isn’t exactly how you wanted it to be.

In the past few months I’ve spent a lot of time looking and analyzing the scrum process, gone through some formal training, talked to a couple of experts and come up with my own opinions. Some do show the weaknesses in scrum, and some may be just flat out disagreements with the scrum process.

All team members are not equal. 

Scrum is built on the idea that all team members are passionate about the project, and respect each other. A cross functional team is a great idea where we can help each other out when appropriate. But that’s not always the case. The truth is I’m not a BA expert. Can I do it? Sure, but I’m significantly less efficient at those tasks than I am when I’m coding. Not everyone has experience doing QA. At my place of work, I don’t even have the tools installed on my machine for design. So there’s a role/specialization in development that says not all team members are equal, and they shouldn’t be!

Additionally, team members have different levels of dedication. A disgruntled, jaded employee is going to have a different level of dedication than the new guy looking to make an impact. Their goals at the company are different. Some want to ship software, some want to improve their skill, and some want to just collect a paycheck. The idea is to hire motivated employees, but let’s be real – you cannot keep everyone happy, motivated, and having the same goal.

Self-Organizing is great but… 

Scrum is supposed to allow teams to self-organize. However, it treads a dangerous line in a lot of areas. It is our nature that when five people get together to work towards a goal, that someone acts in some sort of leadership role – even if it is an unofficial one. This is the self-organization. But that conflicts with the all team members are equal. By placing leadership on a team member, that’s no longer equality. Additionally, you tend to let people who are more aggressive and outspoken dominate the conversation, potentially not knowing about the project.

For example, I once was working on a complex engine for an application that I worked on. Three developers huddled around the whiteboard and talked about potential issues that could come about. Two of us were working together, and making good progress. The third was not. The third developer was new to the organization and didn’t have knowledge of the business rules. However, because he had the type of personality to dominate the conversation it stopped progress. He should have been asking why instead of dictating. Fresh views are great, but the personality can be a problem.

Third Parties 

I always seem to work on projects that have heavy third party integration. Any time you work with a third party, you inherit their headaches times ten. You cannot do anything about them, you can only prepare for them.

For example, I had once developed a feature on an application based on insurance risks and rates. The rates would come from a third party. Before actual coding had started, the contracts were written and agreed upon. The third party told me that the service I would need to call would be available in three weeks. I had mocked up a service that I could control and develop against. Not the most efficient way of developing, but it works. Once I finished up my side of the development, I really needed to test with the third party, who was now multiple weeks late. Like any waterfall project, when one module is late, it pushes the next module to be late. This delayed the release. Eventually they finished with a completely different contract that we agreed upon. You can try to protect yourself from third parties, but I find that they always find a way to disrupt your schedule.

Bugs have no real plan 

Scrum seems to be ideal for a new project that is starting from scratch. You don’t have to worry about legacy code, being pulled into other projects, or bugs. Let’s face it – every developer who isn’t Larry Gasik has bugs in their code. I have yet to see anyone implement a smooth plan allowing for when things come up. I’ve seen different approaches to handling bugs, and I don’t like any of them. Reduced capacity makes planning look bad and encourages lazy developers. Swapping stories in a sprint destroys morale and timelines.

Shared Resources

Smaller organizations allow people to wear multiple hats. This can be both beneficial and detrimental. In large organizations there are almost always too many hats. This is a major problem. Depending on the project, a scrum team may not need a full time DBA, a UX expert, a front end coder, etc. These types of resources then get shared among the organization. When this happens, you’re adding another hurdle for the development team to complete their job. This goes back to a scrum team relying upon third parties. When these things happen, your projections can change based on that third party. When that third party has their own sprint or schedule, it becomes difficult to interact with them and get things done in a timely fashion.

Scrum is great but…

It is a framework. It is not intended to be followed by the book. Modify it to be what works for your needs. I’ve never had a full time product owner. I feel like I’m going to find a unicorn before I locate a full time product owner. On a project with only three people, I’ve had to be the scrum master and developer, and when that happened, it was more successful than just complaining.

Too often I am seeing scrum being hailed as a silver bullet, and that any time scrum isn’t working for a project, it is because the process isn’t being followed. The scrum framework is built upon ideals when in reality you may not have the set up that scrum thrives in.