SCRUM

It can’t be solely about Dynamics all the time, so how about Scrum, just for a change?

To start with, I’ve been on so many different projects, and a lot of them did claim to be following SCRUM.  But I am just starting to realize, now, how little did I know to believe that they did. Well, not that I did not have my suspicions, but still.

Either way, earlier this week we had a pretty standard lessons learned session after delivering our first release. There was some interesting feedback during the session, but I started to get a feeling that our problems could not really be that unique. Scope creep, estimates, testing, overtime.. Have not you heard of those issues on just about every project? Problem is, we were, presumably, doing SCRUM. So I ended up spending the next few days doing a bit of research on how it’s done, how the testing is done, and, eventually, what SCRUM, actually, is.

And you know what? I think it would be fun to work on a real SCRUM project. Mind you, I have not yet seen a single “real” SCRUM project. Because here is what SCRUM is (and if you used to think everyone in the world knows what scrum is in rugby, I can personally attest to it that you were wrong):

Source: https://en.wikipedia.org/wiki/Scrum_(rugby)

The way I understand it – “it’s all in, let’s get control of that ball”. Or, when it comes to the software development, “let’s get control of the project”.

Ultimately, we need this thing to work, and if that means sacrificing the documentation or changing requirements two days before the release, then so be it. Those are not the real problems even if all of us would probably prefer to avoid such scenarios. The real problem is our inability or lack of desire to recognize that those things happen because they are normal. Yes, there will be scope creep. Yes, the requirements will change. Yes, the documentation will never be detailed enough. Yes, we will never be able to provide 100% test coverage after each iteration. BUT, depending on what we value more on each particular project, we can still choose what to focus on.

Athough.. we would not have a manager to tell us what to do! Seriously. There is no “Project Manager” role on a SCRUM project.  If you think I’m making it up, have a look at the official SCRUM guide:

http://scrumguides.org/download.html

Scrum Master would help the team to overcome the obstacles, Product Owner would help the team to decide what to work on, and the team would self-organize to deliver. As far as project management is concerned.. there would be none.  In the ideal SCRUM, it seems, everyone would, basically, do their best to deliver what’s called a “product increment”, so, assuming it’s the right team with the right skills / people, every team member would be able to do what they do best, and, at the same time, to trust what others are doing.

And, if you think of it, this is where it’s almost never done right. People are hired for the specific roles based on their resumes/position requirements/salary expectations/who knows what else, whereas it would probably be better for the team members to somehow find their roles as they go. Besides, there is always some sort of project management which needs to know how the project is going, when some features are going to be delivered, why are there delays, etc. Well, if the team is doing their best, and if the product owner is working with the team on maintaining proper back log, there is no need for that – if this kind of control is present, it’s just an indication of the missing trust.

So, imagine.. you are on a team where your role is not that rigid at all and where the only real expectation is that you’ll do your best, yet the client trusts that your team can and will deliver as best as it can, so there is no unnecessary pressure or control. Isn’t it fun to be on such a team?