I am a big fan of agile development and used XP on a very successful project a few years ago. I loved everything about it, the iterative development approach, writing code around a test, pair programming, having a customer on site to run things by. It was a highly productive work environment and I never felt like I was under pressure.

However the last few places I have worked use/used Scrum. I know it's the poster child for agile development these days but I'm not 100% convinced it is agile. Below are the two main reasons why it just doesn't feel agile to me.

Project Managers Love It

Project managers, who by their very nature are obsessed with timelines, all seem to love Scrum. In my experience they seem to use the Sprint Backlog as a means to track time requirements and keep a record of how much time was spent on a given task. Instead of using a whiteboard they all use an excel sheet, which each developer is required to fill out, religiously.

In my opinion this is way too much documentation/time tracking for an agile process. Why would I waste time estimating how long a task is going to take me when I can just get on with the task itself. Or similarly why would I waste time documenting how long a task took when I can move onto the next task at hand.

Standup Meetings

The standup meetings in the previous place I worked were a nightmare. Everyday we had to explain what we had done yesterday and what what we were going to do that day. If we went over on our time "estimate" for a task the project manager would kick up a stink, and reference the Sprint Backlog as a means of showing of incompetent you are for not adhering to the timeline.

Now I understand the need for communication but surely the tone of daily meetings should be lighthearted and focus on knowledge sharing. I don't think it should turn into a where's your homework style charade. Also surely the hole point of agile is that timelines change, they shouldn't be set in stone.


The idea of agile is to make the software better by making the developers life easier. Therefore in my opinion any agile process used by a team should be developer led. I don't think having a project manager use a process they have labeled "agile" to track a project has anything to do with agile development.

Thoughts anyone?

  • 7
    In scrum, teams should be self-managed. The goal of project manager is to eventually eliminate their role so that the team will organize and attend daily meetings by themselves. The role of project manager should ideally be eliminated to attending retrospective and planning meetings and handle all the organizational work.
    – superM
    Commented Jan 20, 2014 at 14:51
  • 8
    Yes. Even one of the "fathers" of agile doesn't agree that Scrum is really agile : youtube.com/watch?v=hG4LH6P8Syk
    – Euphoric
    Commented Jan 20, 2014 at 14:57
  • 19
    So what you're saying is that you're not doing Scrum, and you're aware of that, but then you're surprised that Notscrum is also Notagile?
    – pdr
    Commented Jan 20, 2014 at 15:07
  • 2
    I've never spent more time in meetings talking about process than every single "agile" team I've been on. But I still like it much better than the alternative.
    – sea-rob
    Commented Mar 8, 2014 at 0:44
  • 17
    In my experience, Scrum is essentially an attempt to make Waterfall look agile by dividing it into smaller units. In fact, sprints should more realistically be called "cascades". Commented Oct 30, 2014 at 15:08

6 Answers 6


There are certain elements in Scrum which are more prone to perversion, but to be frank, what you are describing is the result of trying to get a organisation to adopt Scrum without educating all the stakeholding parties as to what it's all about, how it works and why it works. You need buy-in across the entire company to get results.

Any agile transformation is going to expose everything bad that's going on in your organisation, including, but not limited to, micromanagers, powerhungry people with their own agendas, insufficiently trained developers, communication silos, etc. If there's no collective will to address these issues and you just "do standups" and just "work in sprints", the Scrum implementation is going to fall flat on its face.

I can not stress this enough: if you want to do Scrum, you need competent coaches who can show you the path. It's not enough to read Essential Scrum and then just see where it gets you...

  • 23
    In what way are daily standups different from micromanagement?
    – Giorgio
    Commented Jan 20, 2014 at 16:51
  • 12
    The standups are for the team to organise their time so that they are not getting in each other's way. It's absolutely inappropriate to talk about estimates, time elapsed on past tasks etc. - indeed a project manager (as opposed to the scrum master) should arguably not be attending at all. Commented Jan 20, 2014 at 17:30
  • 12
    @Georgio: depends on what you mean by micromanagement. The goal of a daily standup in SCRUM is to keep everyone informed on what everyone else is doing, not to provide an opportunity for a project manager to chastise people for not meeting estimates. In fact, there is no project manager in SCRUM, tracking and adjusting estimates is the job of the team, and if they are not met the question to ask is "what caused it and how can we avoid or allow for it in the future?", not "whose fault is it and how bad can we make him feel?" Commented Jan 20, 2014 at 17:32
  • 3
    @ErikReppen as it is with just about anything, you have a small group of people who come up with a worthwile improvement and then you get a much bigger group that wants to monetize it and generally perverts it completely :-p I believe in Scrum, but I completely distance myself from the Scrum Alliance and its certification business. Commented Mar 11, 2014 at 7:10
  • 9
    @jessehouwing: Yes, but imposing meetings on a mature team is like going up to someone who can perfectly walk and telling them: look, you have a problem, you cannot walk, I will teach you to walk properly. These people will look at you and ask themselves: Hey, what does this guy want from me? Of course I can walk. So, imposing daily meetings on a mature, self-organizing team only disturbs their work flow: it is just waste. Such a decision can be either be explained by incompetent management or by the will to observe / control how the team works.
    – Giorgio
    Commented Jul 4, 2014 at 5:30

Yes. Even one of the "fathers" of agile doesn't agree that Scrum is really agile : youtube.com/watch?v=hG4LH6P8SykEuphoric

I think this link from one of the comments above really says it all. It's worth a watch, Uncle Bob gives a brief history on Scrum and basically says Scrum is not an Agile development process because Scrum has evolved over time to become a management process. The reasons behind this appear to be because it was project managers, and not developers, who were taking the Scrum courses.

  • 2
    This (what you have written, not what uncle bob said) is a non sequitur. Just because something is a management process does not make it inherently non-Agile. Commented Mar 10, 2014 at 15:16
  • 12
    You can have brown cats and browns dogs, but a brown cat can never be a brown dog. It's not because it's not brown, it's because it's not a dog. Similarly an Agile management process cannot be an Agile software development process, not because it's not agile but because it's not a software development process, which is what we're talking about.
    – user115440
    Commented Mar 10, 2014 at 15:56
  • 1
    Then you might want to update your question, titled, "Does anyone else feel Scrum isn't agile?" Commented Mar 10, 2014 at 16:06
  • Well, managers like agile even misuse it. So they can blame developers. So using agile whatever fake or not it is political correctness issue.
    – Love
    Commented Feb 6, 2017 at 20:37

What you're describing is what we, Professional Scrum Trainers, see a lot in organisations that have "implemented scrum". Often they "Do XP in the development team" too, meaning that there are a few Unit tests running on a build server somewhere. This isn't scrum.

Yes, Project Managers can use a Product backlog, especially one that has been digitized, to abuse the hell out of the metrics such systems gather. But the Development Team and the Scrum Master should not let him. What is a Project Manager doing there anyway? Shouldn't that be a Product Owner?!

Just as XP can be done badly, and some more rigorous processes can feel very fluid (with continuous integration, deployment, but still very plan driven), Scrum is just a framework. It takes good people who understand the values and the process to execute it well. It takes Continuous learning an improvement to get there.


You probably expected that one, but just because some (many ?) people misuse Scrum in an un-agile way doesn't mean Scrum isn't Agile.

Project Manager : there's no such role in a Scrum team. The Scrum Master is not responsible for budget or meeting deadlines. He's responsible for helping the team out and removing any impediments standing on their way to the goal they committed to. From what you describe, it seems your PM hijacked Scrum to take for himself prerogatives that normally go to the team and Product Owner, perpetuating previous command-and-control habits.

Time tracking : Scrum recommends to track remaining time and sum it up to determine sprint status, not point at time spent by individual team members. This might seem a detail but makes all the difference between a blame-oriented culture and a goal-oriented approach.

From the Scrum Guide :

Monitoring Sprint Progress

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

  • It is unavoidable to become a blame-oriented culture even Scrum is 100% political correct in theory.
    – Love
    Commented Feb 6, 2017 at 20:34

scrum is a project management methodology

agile is a software development methodology(-ish)

scrum+agile works very well

scrum without agile...not so much

  • 3
    It's interesting that Scrum used to be a software development methodology but over time has evolved into a project management methodology.
    – user115440
    Commented Mar 7, 2014 at 12:26
  • 2
    I think that's kind of inevitable. The devs just don't have as much a sense of ownership in process (don't want it). In a sprint review recently, I called into question the purpose of the team: write software, or make the burndown chart look good. I made my point, but then all the PMs in the room had to go to great lengths to emphasize the importance of blah blah blah. lol!
    – sea-rob
    Commented Mar 8, 2014 at 0:48
  • 2
    @T-Pane: Even more interesting that Scrum was originally proposed as a new-product development methodology - hbr.org/1986/01/the-new-new-product-development-game/ar/1 Commented Mar 9, 2014 at 19:07
  • 1
    I know it is old but this answer is completely false. Scrum is a framework which patterns be fit into. Agile is a set of values and principles. Commented Jul 4, 2018 at 20:54
  • Imma just leave this right here techbeacon.com/app-dev-testing/why-scrum-sucks Commented Aug 26, 2019 at 22:01

I'm going to state some obvious facts but bear with me.

Takeuchi Nonaka's article in HBR talks about a New Product Development Process, does not talk about Agile Software Development, does not talk about Scrum as it is defined by Ken & Jeff:

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is: Lightweight, Simple to understand, Difficult to master.

Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

The Agile Manifesto talks about Agile Software Development – it's a manifesto – not a framework, not a process.

If you measure up Scrum against the Values and Principles of the Agile Manifesto you will see that it fits.

The Product Owner owns the Product Backlog. The cross-functional Development team owns the Sprint & Sprint backlog. There is no Project Manager - as answered previously – this is a misuse of Scrum and its (Agile) intent.

Transparency, Inspect and Adapt are the pillars of Scrum, which transform into action about learning and improving to get to "Done".

It will make the cross-functional development teams' life easier but not without commitment, trust, learning and improvement.

So my answer:

A project manager is not a Product owner – a product owner know their product and the business / customers' needs and priorities. There is no one project managing the scrum "process".

To me the things pointed out as negative and what seemed to be positive with Extreme Programming (XP) are two different things. XP to me is more about Software Development Practices although somewhat overlapping with Scrum. The five values of XP are communication, simplicity, feedback, courage, and respect – so they will obviously work with Scrum. Scrum does not prescribe software development practices.

Scrum done right is agile - and Development team led - , in its increment – Sprints.

The daily stand-up (the daily scrum) is for the team to plan the next 24 hours and in that we all share what we've learnt over the past 24 hours. If this is to take no more than 15 minutes then obviously we, the team, need to become great at this communication as well – and this does not prohibit us to bring up issues with those concerned in between – this is how we learn and improve.

Estimation and documenting is part of the learning process as well – what happened that changed the timeline, what did we do that was great, that improved the timeline – how can we keep on doing it or elevate it in the next sprint, could we have done anything about the things that had negative impact on the timeline – what and how, if not did we escalate it – what, how – to keep learning and improving. Working software over comprehensive documentation – while there is value in the items on the right, we value the items on the left more.

So if you have an Agile mindset and so does your team, then its up to you to set the record straight. If the organisation do not want to be Agile and transform into an Agile culture then its best to move on. There are better organisations out there on the journey to an Agile culture that needs and value your competence and your Agile mindset.