Scrum Does Not Matter

Image source:

This article is written by Vibhu Srinivasan

Abstract: What has changed since Scrum, XP, Kanban etc started. What has remained the same? Does Practice Matter for Software Teams More Than Framework

Anything comes only with practice. In the area where I work, I watch one of my colleagues who plays the violin every day at lunch. He makes it a habit to get out noonish and plays for 20 minutes or so. If it’s sunny, I see him sitting in the parking lot behind the car, if it rains (which is more likely where I live), I see him sitting inside the car and practicing. It really does not matter if there is any meeting etc, this is his time to practice.

Practice matters when you train for a marathon. I did not realize how important habit is until I joined a running club a few years back.

I heard Santosh ( our running coach ) say that I was required to follow a strict calendar (A framework). The calendar had Mon to Sunday planned out. Sat and Sunday being the longer runs You practices as a team on Wed, Sat, Sun. Mon, Tue, Fri was on our own. Wed was the day off. Very quickly I realized that if I don’t go and be part of that team, I was not getting any faster. One of the practices I remember the first time we ran a 5 K as a team was we would line our groups of 5, and every five minutes or so, the first person had to come back and now the second person became the leading person. This quickly taught us that there was real meaning to teamwork. However, not everything was teamwork. On the days I was on my own, I still followed instructions given and learned how to improve.

The reason I bring up these stories is that I meet teams like the ones I met today that are trying to figure out for the kind of work they do, what framework they want to use. Scrum, Kanban or ScrumBan or some flavor of these.

Well here is the secret, it really does not matter what you pick. If your focus is on getting the framework correct nothing is going to work.

In another case, the customer was not happy that the team is wanting to do Scrum. In some cases, I have seen managers hire coaches to study teams to help them prioritize or estimate better.

So, Are there practices for software teams that are more important that the framework itself? I hear Woody Zull, in the first part of his mob programming workshop teaches people to switch chairs really fast for 15 minutes. Which this may sound silly at the front, he has a point that habits form once you do this a few times.

Here are some practices which can enable teams being more successful. How to make teams play the music of software development better. Feel free to share your thoughts or practices you seem as important in the comments. I would really appreciate that.

Here is the usual disclaimer. I would not hesitate to do these in teams I am in, I have tried many of them in the past. However just like anything else in life, just kicking a drum, does not make music.

  1. Work as a Real Team. What to you mean a real team. Well just putting five bodies together does not make a team. Be a real team. Create a culture anyone can pull any task. Sounds scary upfront but imagine what can happen once you succeed.
  2. Back to School Days: Everyone works the same time at least three times a week. Yes, you come and leave at the same time. What the hell Vibhu, this is not a school. Try it before the adult in you is complaining. All of us have a “No Monster” who wakes up every time we are told to do something we don’t like.
  3. Identical Images for All stations. – When I Say identical, yes I mean it same VM’s for every station. It should look the same feel the same so we can essentially work on any desk. There should be no difference between Developer, Acceptance, Staging or Production Environments. Except the fact that we can’t reach product data everything should be the same.
  4. Remove the concept of Not Done Done, it’s only done. if you don’t get it by just reading this much, you probably are the wrong audience for this article:). There is only one done when it reaches the customer.
  5. Start with Pairing, Mixin Mobbing – Pairing is not just about two people sitting next to each other and working, it’s about getting smaller goals achieved in short increments of time. Pairing and Mobbing need a change in your social behavior. Use a good coach who has done this before if you want to learn this. Yes anyone can pair. Yes developers can pair with managers as well. On the days you work as a team, may be you pair or Mob or this could be a daily affair. However, there may be days where you go solo in which case be ready to face the fact that you are going to check-in a lot more defects
  6. Don’t code until you have CI. CI stands for Continuous Integration. By definition, this makes sense only if you have tests being checked in, every check-in. Build the smallest possible feature in your first few days as a team and check it in, run to production and practice pull.
  7. Doing the Dance: TDD stands for Test Driven Design. When you see a red, dance. If you don’t TDD that is fine as well. Just learn to dance when you do something crazy like write code to pass a test, or write a test when a bug is found etc.
  8. F Before S – Finish Before Starting The Next Time Pick a small feature that you can get done ( yes Done , there should be no done done ) in a few days ( what, we can’t get to finish anything in a few days because we live in the real world and in the Real World nothing finishes in a few days) work on it
  9. Lose what you have not checked EOD. – If you have not checked in stuff end of the day, it’s too late. Next morning start fresh again WTF. Did you say start again Vibhu, This is insane. Yes, if you cannot figure out how to do some work in a days time, then it’s worth shelving that and starting again.
  10. Daily Improvement – Every day at the end of the day talk about what went well that day, thank each other, give each other feedback and talk about one improvement you are doing next day.

Well, there are Many more practices.But all the 10 things listed if practiced daily for a month or so, you will start seeing results. Try them before you start complaining why these ideas are just theoretical and not worth your time.

Discover a wide range of unlearning content in areas such as Product, Design, Engineering, Leadership and Culture