Tutorial :Can Scrum work in the real world [closed]


The team I am working in has embraced scrum in a big way. I really like the idea of it, but find that we are constantly having to make compromises to fit with our development reality. This is making scrum less effective and causing other overheads.

What I am asking is have people out there managed to work with pure scrum and does it pay of to do so. Or is it inevitable that compromises have to be made.

I ask this as scrum seems to be a little intolerant to deviation and it may make a better methodology if it were to accept that the world can’t always be changed to fit scrum and have work around for places where it doesn’t work.


Scrum is definately tolerant to deviation, but I think the key point here is your statement 'we constantly having to make comprimises to fit..". Well of course, if you change your methodology, you change the way you do things. Its like saying "We are now a LISP shop. But do we actually have to write our code in LISP or can we still use C#?"

Embrace scrum and accept that the way you do things will change. You will definately reap the benefits. Unfortunately scrum needs to be accepted by all the stakeholders, not just the development team, to be truly efficient.


Take a good hard look at the compromises you are making, and if they aren't pushing you away from the core values of Scrum / Agile.

For the longest time people here at my shop have been claiming we're Agile, but what they really mean is that requirements changes can be pushed to development at almost any time. We have all kinds of procedures and instructions to follow, and it's anything but "travel light".
That's not necessarily a big issue if everyone is clear that we aren't really doing Scrum, XP or another truly agile methodology.

It only gets dangerous when some things are introduced without adapting other core things - you end up trying to be agile in a system that will simply punish you for it. You try to fix a 4-week iteration but you get new top-priority requirements every week anyway, and you're not allowed to ignore them. You're asked for a detailed planning and get complaints whenever something slightly deviates from it during a sprint. Your best team members are constantly interrupted to help out other teams with their problems.

That's not agile, and it won't work no matter how hard you try to call it agile.

So maybe the reality of your situation is the same, and your organization just isn't really ready for it yet either.


Our team is now using scrum for several years and although there have been issues at the beginning and a lot of evangelizing was needed until management accepted it and changed their way of working with the teams, it has leveraged our productivity and enhanced our knowledge-transfer across the team-members.

From my understanding scrum is very open to deviation, relying on constant feedback and adaption through the retrospective (for the developers) and short iterations (from project planning side/management). Of course, all parties involved (developers, scrum masters, product owners/management/clients) have to accept that scrum works differently than most of the other non-agile development approaches and that they have to modify some of their current methodologies.

I personally think, that scrum gives me a greater freedom and effectiveness than with the other "static" development-/project-approaches I experienced in the past.


It can, but it's not for everyone. In fact, it's not for most places, because the pre reqs for it aren't met by a rediculous number of shops out there. Also, pretty much everyone does their own version of Scrum.


We have recently started to use Scrum, and we are also adapting it to our needs. I think this would be true will all methodologies, though.

There are things like the daily Scrum meetings which we felt were a bit too frequent: we now have Scrum meetings twice a week.

Our sprints are not as rigid as they are supposed to be: we often add a functionality or two in a sprint halfway before the end.

Finally, and probably most importantly, our scrum master and the product owner are the same person.

Overall, things run smoothly. What I like most is the burn down chart.

Hope this helps.


You might get even better answers if you could illuminate just one or two of the "compromises" you're talking about. I'm not sure whether you're talking about procedural issues, management of the task backlog, how long to make your standup meeting, or what to do about version control.

My experience with "pure scrum" in a big corporate environment has gone really really well. I can't think of anything that was compromised in a negative sense by using the Scrum model.


Yes, what are the compromises? Maybe you don't always program in pairs?

All developers need to make everyone aware of the impact of interuptions. If someone takes 2 seconds to touch wet paint, how much time will it take away from the painter? Not to much if you just painted the spot, but what if all the supplies have been put away?

Let your managers, users, clients team leaders know that you can handle their new emergency, but what do they want to give up/delay? Nobody rides for free.

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Next Post »