I have never followed Scrum, and I don't think that's bad

Cover photo from: Sébastien Delest at Flickr

I've programmed professionally for +15 years (at an office, with a DEV team, with a salary), since I was 20yr (I'm 35 now), and we have completed hundreds of projects, can't really count them on, in all of those teams we never followed Scrum.

I don't think that the consequence was that: the teams were toxic, that we couldn't accomplish things, that our products sucked, that our customers didn't get what they wanted, or that we were not smart.

I've tried Scrum

In several of the teams that I've been, we have blamed the process, and many times the suggested solution has been, why don't we try Scrum? or a derivative like, we need a Scrum Master that show us how to work.

And we have tried, we started making daily standup meetings, setting up sprints, using post its, etc. and most of the times, this has brought us value, it has made us work better, it has really accomplished, some of, what we wanted.

So, were we Scrum compliant? Nope; we were just thinking, and doing better ways for working together, we used some of the tools that Scrum uses, and they brought us some benefits that we needed.

And that was good, at moments we thought that because we were not fully Scrum, or our team didn't had ALL the Scrum roles needed, we were just not as successful as we needed to be.

Then we thought, maybe the problem is not us, the problem is the software, that we are using to control our tasks, what is holding us from achieving what we wanted. And we invested in better software, we changed what we were using, or we adjusted the configuration in the software.

A lot of people cheers for Scrum

I think that Scrum as a concept, has absorbed the brand/concept of Agile, in which Agile was mainly a manifesto, aiming for engineering excellence by a group of engineers tired of how the management team was working with them. And it feels like every time and engineering team feels like that, they think the solution is being Agile, and they think that the most easy way to accomplish what the manifesto strides for, is do Scrum. No questions asked, I mean that's what everyone says, why not?.

And what they should try, is to implement the Agile manifesto in their own way, be these engineers, that a lot of us admire, and work on be better at their job, I would even say, FORK the manifesto, make it yours.

But constantly, in the teams I've worked on, the people keeps bringing up that the reason for not being successful is the lack of training in Scrum, or a certification missing. Same thing when I interview people, they often ask me, if the methodology that we use is Scrum, as if that's what will make us better from the rest.

Teams should measure value

Instead of thinking how many tasks are closed, or how many bugs were created, they should measure how much value are they bringing to the organization, and yeah, that is hard, that is not something you get a formula for when you obtain your Scrum Alliance certificate.

I literally was taking a Project Management training, in one of the companies that I was working at, and I asked the trainer: What is the best way to make estimations? Answer: Experience. I've carried with that answer all my professional life, and the way I've thought about it is... its fine if you try to use all these techniques to be sure of the estimation that you are setting.

Value, is the ultimate goal, is what should be in your mind every time you are trying to do your work, am I bringing value to the project, to the team or the organization? If they succeed, I will succeed.

Well, if at this moment you still don't know it, consistently measuring value is HARD, there are also a lot of of metrics around it, but you should choose wise and really pick the ones that make sense.

Scrum is hard

Scrum is hard, but that is not why you should avoid it, I mean, I don't want anyone from not trying Scrum because of me, I'm just saying that in my point of view, is hard, and is maybe not what you need. If you fail doing Scrum you are not a failure, maybe is not what you needed, maybe is not for you.

I think we can maybe compare Scrum with something as simple as going to the gym, yeah, is GREAT, its good for your health, it has a lot of the equipment that you will need to accomplish things like: lose weight, be in a better shape, improve your cardiac performance, lower your stress, etc. But going to the gym, is not the only option you have to accomplish any or all of those things together, you can run, you can do yoga, you can even get a surgery in some cases... just saying out loud, is not bad if you try it, but if you fail at it, because of ANY reason, you are not wrong.

I personally love Kanban, the board

In my experience is simple to understand, and easier to adjust when the team changes their mind about working in different way. And to be more specific, I love the Kanban board as a tool, I'm not saying that you should ditch your Agile efforts in Agile and go full speed into the Kanban methodology.

The board helps you to identify easily the status of the tasks, and who is working on what, you can see bottle necks, and act accordingly, it can do WAY more, I just love it.

It also requires discipline, as any other tool-methodology-practice, the proper usage of it, depends on the discipline of the team, and the board by itself just doesn't work without other tools like:

• Daily Standup Meetings
• Tracking Sheets / Score Cards
• Plans
• Design documentation
• etc.

I like it, because when you really want to constantly deliver value, is better to split the work, and think on continuous deployments, which can be automatic or not, better if they are automatic, I'm not saying that you will fail without automatic CI/CD, but they definitely help, and a lot, help a lot.

You can deliver value, without being stranded to a sprint, when you finish you finish... I'm not saying you can't do this with sprints, I'm just saying in my experience it has been simpler like this.

Fork a methodology!

If I could give any advice, I've been trying to give any in all this post, it is, why don't you try something bold, something like, forking the Agile manifesto, and adjust it to your team needs. Decide which ones of the items that it includes make sense, and bring value to your project, team and organization.

After you have done that, you should fork a methodology, pick any, PMI, Agile, Scrum, Kanban, what ever you want, and choose the tools or practices that make sense to your project, team and organization.

The best tool of all... which they just put a name on it, is the retrospective, which is probably the base of the engineering mindset, and the engineering profession, thinking about what went well, what went wrong, and how to do it better.

You like Scrum, that's not bad either

If you have taken courses, if you have gotten a certificate, or if your role is Scrum master, Product owner, or a derivative, that's not bad either. You probably agree with me that the solution to every problem that you face in your daily work is: Scrum methodology.

And you probably are aware, I hope so, that not every practice old or new of Scrum is perfect, or usable in all the context; its important to separate the noise, from the signals, and be humble and honest about what works and what doesn't.

And, as I mentioned before, make a retrospective around it.

Let me know if this makes sense to you, or if your team has tried different things in the comments.