Hi, in this post I want to tell you why I like SCRUM – Tips which may help you

After I started to be interested in agile management processes, SCRUM took nearly all of my attention and I often hear that people do not understand it or do not know how to get along with it. If your company wants to work with SCRUM you should get an idea of it and learn it. If you do so, this seems quite all right here and you can stop reading. But if you have any doubts about it please read further. If you are not into it and asking yourself the question “Why should I get along with this thing? Processes come and go. It will pass. With or without me”: Read this post. I will try to give you tips for your SCRUM experience and tell you why I like SCRUM. No, let me push this: I love it. There you go:

Reason 1: Teamwork

I like teamwork. I really do. You often hear the question: “Are you a team player?” maybe in a job interview and how fast you are telling “Yes!” Without knowing in which team you perhaps will come and without knowing with which people and characters you will work together in the future. But beside of that in general: Your team will always have so many different characters no matter how long you are into this team. They will come and go. You will have many types in your team and to deal with this is strenuous but also interesting and fascinating.

If your team does SCRUM it’s very important they stand together as a team. Which means: Everybody could overtake the work of another one if he will drop out for a specific reason. It’s not like “Everybody can do everyone’s work at 100 percent”! But every team-member has to have the will to do work of his neighbor and save the SCRUM -sprint and reduce the risk of not missing the sprint-goal. The work is of course groomed and defined, so that everybody could do it in more or less time ;).

Teamwork also means being interested in work which you did not care about before SCRUM. Concrete in your everyday SCRUM-work: Do pair programming with perhaps one experienced and one not experienced guy. Do show interests: “Can we do this together?” “Can you give me a briefing about what you did exactly to solve this problem?” This is sharing of knowledge, this shows how much interested you are (or you should be) and in the end this makes a great team working perfectly together. So doing teamwork is one of the greatest things about SCRUM. But if you want to introduce it you have to have absolutely everybody behind you who has to work with it. SCRUMis team-oriented. So the team has to be convinced that this is a good thing. And this mostly is the hardest part.

Reason 2: Transparency

Transparency is one of the three pillars SCRUM is built on. Transparency in its perfection would mean: Everybody knows what you are doing every minute on your 8 or 9-hour-working-day. Well this is not realistic. I mean: No matter how interested the others are it would drive you nuts if anyone would know about every single step you do or, otherwise, you would have to tell everyone about every step you do. But let’s be egoistic (only for a moment). What transparency means for the team is not a treasure. But think about yourself. Be transparent to yourself first: What have you done yesterday? What are you going to do today? And which plans do you have for the next day/days? This is a way to give structure to your work. Of course: Planned user stories can be the framework of this during a sprint. But while being more detailed you have to answer yourself the questions and you will definitely have a plan and a structure about what to do. And with this it is absolutely no problem telling the others. If everyone is doing this (besides getting all info into the team etc.) your transparency will come right along while you are planning your work for yourself. The daily-standup is one place for this: Be transparent there! So with a daily meeting and a transparency you know always where your product is standing. No surprises. No work behind your back. If every team member is following transparency there should be less unforeseen issues during your sprint period.

Reason 3: The improvement

This is what makes SCRUM a process. The never ending will to improve everything you work on. On every retrospective in the end of the sprint you ask yourself the question: “What was wrong” and I personally felt the bad mood which comes with this question. Yeah, it is important to ask this question. For sure it is. But as important as this question is: “What went well this sprint?” And normally this is a question which is much easier to ask (and to answer). So figuring out what went wrong is a goal of the retro, but getting the facts that are doing well is a much easier way to get into this discussion. So: Ask this before you want to explain the bad points. Also here we come to a mentioned point. People who do not care about SCRUM will not have the will to get better. And this has to be there at 100% to get a good improvement. The team is the only part which has to do the work. They know best how to improve things. If they do not want to get better, they only did not understand the advantages of how work could be. Maybe you could collect them at this point.

Reason 4: Problems

SCRUM shows you problems: Let’s see the process as a whole concept for this point. Introducing SCRUM is done fast. You have sprints, you have your Product-Backlog-Items or user stories etc., you work is organized, your team is organizing itself and so on.

But what the process really shows you are problems! It shows you where you have delays, where information are not where they should be etc. Let me clarify this: This is a good thing! You have a process which points you in the right direction. This is not bad, you should see it like “It can’t get easier to improve!”

If you use SCRUM as a whole without changing much of it SCRUM will show you your problems, your pain points. And SCRUM is useless if you have the opinion to change SCRUM to hide or get rid of this pain points. This hurts sometimes! “Why do we have problems there? This worked well for years!” Well: Did it? You are planning your work right now and have an overview, you know where your product is and you have an interested team which does teamwork. And the paint point which came up worked well? For years? Ask yourself: Wasn’t this only a problem everybody learned to get along with? For years?

I think this is one of the best points SCRUM does for you. You are adapting a process and this process comes to you and shows you where your problems are. (For this knowledge you would normally pay a lot of money ;))

So: Do NOT get rid of pain points by working around them, accepting them “as is” and telling everybody that this worked for years. Let SCRUM show you which things to solve. Give the process and yourself time to really figure out what the problem is. Maybe this takes 5, 10 or more sprints! But do not change main points of SCRUM and with this hide your problems. You would do SCRUM in the front and your old process in the back.

Reason 5: Priorities

Work is broken down in product-backlog-items or user stories and tasks. Whatever: You are working on things which have a priority. No matter what exactly this value is (0-100, 0-10, etc.) as a developer you have a picture what is more or less important. What does the customer want to see? Where do we have problems? What should we make better? This is also a kind of transparency which comes along automatically: You see which focus your stakeholders have on the software! Of course this can be discussed. But you can see it because of the priorities the PBIs are tagged with. This also helps you to manage your work.

Well, these are only five reasons I mentioned here. I could go further and further. But I can tell you: try it out! With every pros and cons you see in the beginning. Solve the problems, see the advantages of organizing your work agile, your software agile, to have priorities and so on. I am absolutely sure in the end you will love it and after a time you can give yourself more than only reasons why you love SCRUM as much as I do.

Regards

Fabian