Scrum, and the way of thinking that it attempts to socialize in the world of work, has nothing to do with project management. Anyone who is laboring under the misapprehension that Scrum is some form of “Agile Project Management” is seriously missing the point. There may be such a thing as “Agile Project Management”. I don’t know, and don’t really care. It is of no interest to me. My concern is with changing the way people think and act, not with force-fitting old ways of thinking into a new paradigm that cannot accomodate it. The result we are seeing is a half-baked compromise.
Organizations like PMI, Scrum Alliance, ICAgile and others who are trying to grab a slice of the Agile market are like parasites feeding off the souls of people who really care about change in the world. It is a tragic mess, made worse by those so-called Agilists who justify the behaviour, and even buy into it. Old habits die so very, very hard.
I am not interested in half-measures, or “corporate-approved Agile”. This strikes me as worse than useless. At least the previous command and control culture was honest. This fake-Agile is deeply disingenuous, pandering as it does to those in fear of real change.
I urge anyone who really cares about the future of business, and the health of human beings in the workplace to steer well clear of all these oblique, money-making, compliance-seeking efforts to tone down Agile and make it palatable to those driven to maintain the status quo. Seek something more noble. Please.
click to subscribe
Agile Anarchy 
Let me suggest that Scrum explicitly deals with how to manage:
Time
Cost
Scope
Risk
Communication
Quality
People
… and Integration (how we deal with the rest of the org)
The primary purpose of Scrum may not be Agile Project Management… but intentionally or not… Scrum has a lot to say about it.
@Mike: Project Management is a mindset that needs to be torn down, not rescued. Scrum is about creating products that customers value. It is not about managing projects. Scrum is product-oriented, rather than project-oriented, so there is little point managing something we don’t really care about any longer. And there is little point “managing” anything in a creative, complex environment. The word and the idea are no longer useful. Instead we should be seeking to guide, support, inspire and nurture.
Scrum has nothing to do with the way of working that the PMI has been promoting these past decades. It is the antithesis of that.
I find it tragic that so many in the Agile community are desperately clinging on to old ideas, and trying to map irrelevant roles onto a paradigm they were not designed for. The whole certification circus surrounding this effort just serves to highlight its lack of truth and integrity, i.e. no one will take it seriously without a reward scheme.
And didn’t Ken himself publish a book called ‘Agile Project Management with Scrum?’ Confusing to say the least in light of your post.
Well, I didn’t write that book, and Ken didn’t write this post. We are different people. Where’s the confusion?
Of course you and Ken are not the same… but you were asserting authoritatively on Scrum, and Ken invented Scrum, and as a former CST, I thought you might have some insight as to why the inventor of Scrum would write a book on Agile Project Management with Scrum if Scrum did away with the notion of Project Management.
My assertion is that Scrum did not do away with project management… it did away with project managers. Project management is the business of managing time, cost, scope, quality, risk, communication, people, procurement, and integration with the rest of the organization. Scrum divides this role between the PO, the SM, and the Team… that does not mean the role went away.
I respect that you do not value people called project managers… some of them really suck, but to me it is inarguable that Scrum deals with project management. Personally, I believe that you can be a good Agile Project Manager… but I am not asserting that Agile Project Managers are a part of Scrum.
Just my take… I am cool to agree to disagree 😉
Tobias,
I certainly won’t argue with you about the possible evils of certification organizations. I think there value is highly subjective and based on a lot of factors. You don’t see any value and I fully respect that.
My only concern is you have lumped the term “Project Manager” into this. I don’t need a PMP, Prine2 or any other alphabet soup to be a project manager. Project Management is defined as “is the discipline of planning, organizing, securing and managing resources to bring about the successful completion of specific project goals and objectives.” (Wikipedia) It ranges the gamut from very scientific driven practices to strictly people management techniques for motivating teams.
Project Manager may (or may not be) similar to a Scrum Master role, but it certainly doesn’t deserve to be lumped into issues with certification organizations that attempt to define anything from what constitutes milk chocolate (yeah there are rules) to what constitutes an certified X, Y or Z.
Best,
Joel Bancroft-Connors
As someone decidedly outside of the industry scrum is based in, software development, sorting through all the information billed as “Agile” and “Scrum” in an attempt to educate oneself is quite difficult.
Your post sheds some light on that – and confirms what I’d been seeing that Agile is the buzzword of the day. And yet from what I understand as the very basics – namely what you direct people to in your New Way of Thinking post, Scrum Alliance’s What is Scrum? page; scrum and agile is an expedited production cycle that compiles a list of features/goals that are taken and made functional in chunks then reviewed with the customer and team before moving to the next chunk (done in weeks cycles over months).
Is that not essentially a framework of project management? Maybe I’m giving project management a larger definition than it is functionally used – but when I see content on Agile Project Management on the web it’s more or less a summary of that cycle and discussion of the interaction of the team, organization, and customer.
I guess what I would ask is, where and what really is the the “way of thinking”? Is it the things that go along with the production framework – like the de-emphasis of documentation, focus on smaller teams, and less rigid development process?
I suppose I’m less looking for answers as I’m just trying to highlight how murky it can be sorting to the massive amount of information out there – from reputable sources and less-than.
I think this is once again Tobias’ way of stirring up a conversation to bring out a great point.
I don’t think the main point is if Scrum is a Project Management frame work or not. I think the major point here is about the “corporate approved Agile”. I couldn’t agree with him more that it is evil and dangerous. Corporate approved Agile is just an approved way to micro-manage every day at 9 am. Sustainable pace? Well, that’s a nice to have, is it not? 🙂
Stay clear!
I totally agree with Tobias.
This has to be elaborated, but…
@Mike: that book’s title is misleading, to say the least.
@Joel: Agile is not about “managing resources”.
@David: Scrum is a framework for product development, and it might be a replacement for project management. (the fact that there’s no project manager in Scrum could be a hint.)
Project management was last century’s (Taylor’s) way to deal with a complicated future, Scrum is a way to embrace change in a complex present. There might be situations where they are alternatives, but I see no need to combine the two.
What is the relationship – or is there no relationship between the two? Olaf’s point above is interesting; “Project Management was last century’s way…” but I wonder if this assumes a rigid interpretation that doesn’t allow for it to have evolved. Perhaps it’s known by another name?
The work carried out by a traditional PM is divided up in Scrum between the PO, the SM, the Team and the garbage can.
The elements useful to releasing good products are retained, this probably represents ~30% of the traditional PMs work. The ~70% dedicated to planning, tracking and resource-leveling, report creation, chart maintenance and other command and control related activities are simply not done.
Scrum implicitly removes waste by starting with a minimilist process where teams only do what is essential to create great products. Nothing is added to the process unless it helps towards that goal.
Great info – thanks 🙂
Fully agree. But, what should replace those parasites which provide agile services harming the Agile philosophy?
You, perhaps? 🙂
All meaningful, lasting change begins with oneself.
like it! very cathartic 🙂
I vividly remember when you had a short talk with the PMI CEO and you mentioned to him that in agile one should talk about Project Support instead of Management and the guy said “interesting, very
interesting”.
Yep, I remember that. Scrum Gathering, Orlando, March 2009. Here is a reference to that conversation: http://bit.ly/8CrLji
Tobias,
First of all, I think your efforts and enthusiasm for changing the world of work by the principles underlying Scrum, Agile, etc, are admirable. I quite agree on the goal.
But aren’t you stretching the “Scrum” concept too much? If you go back to Scrum’s first books, isn’t it more like a method for developing products rather than a way of changing the world of work? Maybe a substitute for “project management driven” product development, but not that far. I know Scrum has evolved … but that far?
I think, and this is just my belief, that what’s screwed are the emotions and values required for approaches such as Scrum to ground roots in corporations. Since confidence, trust and good will are often replaced by suspicion, mistrust and politicking, it is no surprise that an “agile mockery designed to grow in a rarified environment” arises to “look like pure Scrum”. But I’m not quite sure that the discussion is about Scrum, rather about conscience in the workplace, emotional health, questioning values …
Finally, do you think Project Management is really that evil at all?
Keep the good post. Great discussions arise from brave positions!
Regards,
Walter
Hi Walter. I enjoyed your balanced and challenging comments. I agree, this is about something more than Scrum, but Scrum used well gives a fantastic grounding for organizational transformation. It is unfortunate that few see that potential and treat it more as a methodology, or process.
I don’t think project management is evil, just that it is an idea whose time has passed. In complex environments it isn’t useful any longer (it probably never was) to believe that a single person can manage everything and everybody. So much of a project manager’s work is simply waste. I asked a colleague today if his company has project managers. He replied, “we used to, but now we do Scrum”. Scrum simplifies everything. This idea that we need “Agile project managers” is pure nonsense espoused by people afraid of losing their life’s meaning, or something.
There is a role for management in the Agile world, but the roles may be better described as guide, leader, visionary, mentor, supporter, servant… and none of them involve managing projects. Product people manage products, and teams manage themselves. What’s left?
As usual, I enjoy thoroughly the content that you put forth!
I’m not even sure what corporate approved agile is. Are we assuming corporate approved agile is… certification-based?
“Corporate approved” means that you have some alphabetical stuff behind your name… right?
Tobias, having read your posts I think I am now getting a better understanding of your understanding of “project management” where you are referring to the old kind, traditional, linear project management. I agree with you that there is no space in Agile for this kind of project management.
Then you write “There is a role for management in the Agile world, but the roles may be better described as guide, leader, visionary, mentor, supporter, servant… and none of them involve managing projects. Product people manage products, and teams manage themselves.” – I couldn’t agree more. This is what I consider the ingredients to effective project management. Note that I am not explicitly talking about the role of a project managER but project manageMENT. This can be done by the team as a whole.
Personally I prefer project and team leadership opposed to management. Management involves reacting, may have the temptation to fall back into old, traditional habits (what you call “evil project management” I guess); leadership breaks this pattern, takes the initiative and leads the way. This need not and should not be limited to an individual. Every project is a team effort; the team is the heart and soul of every project. Hence, self-organizing team leadership is something worthwhile going for. Alas, it does not fall from heaven. It requires structure and guidelines. Scrum suggests such a framework and structure. This is a good start. By itself however this is not sufficient. You have to make sure that the team shares the same vision (which is in sync with what the customer needs and expects), nurtures active and productive collaboration, promotes individual and group performance (thus creating team synergy), cultivates learning and innovation (in other words, be open and willing to learn from mistakes), and, last but not least, ensures results (even in software development this is necessary and sufficient). If a team by itself fulfills and lives by these principles, this is great. In that case it doesn’t require the role of “project manager” anymore for it manages and organizes itself.
> You have to make sure that the team shares the same vision… etc, etc.
Who has to make sure of these things? And why? If you are suggesting that a project manager has to “ensure” a team is performing before the team is left alone to perform, then I suggest you will fail.
Theory X management says “mistrust people until they prove trustworthy”. Theory Y management says “people are trustworthy, so trust them”. Which do you think you are preaching here, and which gets the better results?
Sad reality many of us have experienced is that trust is often abused. This leads to management being more carefull and start with Theory X. Great teams earn that trust very quickly which makes it easy for mgmt to evolve to Theory Y. I used to preach to always start with full believe in the willingness of people to contribute sincerely. I hate to admit that I became more carefull and use a more controlling mgmt style until trust is confirmed between all team members. Context, people! 🙂
I agree, you don’t need project management. You need what you need, based on your team and context. Adding a technique from the PM toolbox is fine, as long as you stick to the right principles. The worst I’ve seen is Scrum being abused to fit the predictable whip-driven PM style.
In response to Tobias who writes
“> You have to make sure that the team shares the same vision… etc, etc.
Who has to make sure of these things? And why? If you are suggesting that a project manager has to “ensure” a team is performing before the team is left alone to perform, then I suggest you will fail.”
No, I am NOT calling for a project manager. “You” in this case refers to the team. If, however, a team does not support a joint vision, how can it still be a results-driven team?! A PERFORMING and FUNCTIONING team has a joint vision, nurtures collaboration, promotes performance, cultivates learning and ensure results.
Regarding your reference to the xy management model – It depends on the situation which model is right. Personally, I prefer theory y. But you are right, those are theories and have to be adapted to meet the needs of the real world.
> No, I am NOT calling for a project manager.
So we agree? No need for a project manager in an organization that embraces Scrum. And thus no project management. Having project management without project managers would be like having a boxing match without boxers.
You are right, there is no need for the role of project manager in an organization that embraces Scrum. Corollary, there is no need for traditional project management. As a matter of fact tradition project management would most likely kill Scrum.
I guess where we still disagree is our understanding of project manageMENT. Effective project management entails those ingredients you mentioned in one of your earlier posts (“… guide, leader, visionary, mentor, supporter, servant …”). In other words, I am a strong believer in team leadership (not by one person but by the team as a whole). Hence, if there were really an individual who officially (for whatever reason) “heads” a team, he better embraces the idea of servant leadership.
I love it. I love this kind of discussion… it’s refreshing.
As an senior (provoc!) project manager, I practice that evil since more than 20 years and I like it.
My point of view is a bit different:
1. if you see the whole staff that a project manager has to handle with (ex. 9 domains, 42 processes) to act as a “real” project manager; evidence is that nobody does.
2. if for your organisation needs (no care on why) must delivery this stuff, you can just do it collectively.
3. According to that, with an agile approach (e.g. Scrum), you can achieve this more effectively.
4. I’m ok with you when you act in a small team and in R&D.
My questions:
– shall we have a project?
– what’s the problem with management?
– did you hear about co-creation? (where the management is a part of a team)?
– who has enough money to spend for your approach and just to be blamed by the “agile” team?
– in a realistic matter, have ever merged team and managers perspectives?
To give you a better idea of what I meant about “project vision” in an earlier comment, I would like to quote Antoine de Saint-Exupery (quote taken from Tobias’ website :-)): “If you want to build a ship, don’t herd people together to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.” – a project vision drives people to action, you don’t tell them in detail what to build and how to do it.
@Thomas: I really doubt any large ships would be constructed and functional using such an approach. Maybe a canoe or two, rowboats, maybe. You think you’re going to get 20,000 sailors to just build an aircraft carrier, and each one has a different idea where the magazine should be located? Scrum espouses little tribal groups of people talking through their issues. It just doesn’t scale very well.
I don’t have a problem with a “hippie commune” environment, per se, but it just is not for everyone. I don’t live in one that is for sure. I also don’t think there is “one true way” to do anything. The nice part is now all the “one true ways” can battle it out for mindshare. We should be open to new ideas, not convinced that ours are the only ones that every one should adhere to.
@ Jordan: yes, I agree with you.
Note though: A project vision is not a “hippie” thing to do. I explain the context of a project vision, project objectives and critical success factors in my book “Leadership Principles for Project Success” (http://amzn.to/h5Vt9D).
I am stating that you need to have a common understanding of and support for a project vision. It sets the overall direction of a project. Project objectives qualify this vision and so do the critical success factors.
The dimension of this project vision and project objectives differ. The idea is the same though. Remember Kennedy’s vision which became a cornerstone of NASA’s success? “By the end of this decade we will send a man to the moon and return him home safely.” – I would not call NASA a hippie commune. 😉
@Thomas, I hear what you are saying but I’m not sure what it has to do with what I said. I said that Scrum espouses a hippie commune environment, of 7-10 people working things out with no project management. The NASA success would not have happened with little groups of 7-10 people and then having scrums of scrums to get all the complex systems to work.
I never said nor implied that NASA was a hippie commune. Far from it — the project had a vision, it was bankrolled by congress, and there was lots of money to throw at hiring the best engineers. Sure there was some nationalism and pride associated with it but there was a huge amount of cash associated with it.
That sounds like capitalism to me, not that they did it because they had deep visions of outer space and worked on the project in a purely selfless or tribal fashion.
@ Jordan: I apologize if I misinterpreted your comments.
Did you know that satellites and aircrafts these days are planned and built following agile approaches? True, it may not be pure Scrum taken from software development. But it is the mindset, the framework and the activities that are in sync with the Agile Manifesto.
Have a look at Steve Denning’s new book “Radical Management” (http://tinyurl.com/3vj4zp6) to find additional examples of companies running huge projects and embrace Scrum and other Agile approaches.
“The ~70% dedicated to planning, tracking and resource-leveling, report creation, chart maintenance and other command and control related activities are simply not done.” what is a burn down chart for then, is that not a command and control related activity?
Depends how it is used. It certainly can be, yes. Personally I have never found much use for these charts. Teams tracking their own progress on taskboards is more effective. It is perfectly possible to run an effective Scrum process without the use of burndown charts, in fact many teams do without. There are often useful metrics a team can keep but the difference is that these arise from need, and have a clear purpose, rather than be imposed because “its just the way we do things here” a category which so much of project management behavior falls into.
I’ve heard about it, but only in regards to small teams. Just because some project does X doesn’t mean that X made sense. Plenty of people doing things to polish and enhance their resumes.
If people have success with Scrum, they should do it. It doesn’t mean everyone has to do it. I don’t understand nor do I respect this notion that there is a “one true way” whether it is XP or Scrum or Waterfall for everyone to script their life to.
I believe each team or organization should do whatever they think makes sense. It’s their time, it’s their money, and it’s their decision. I don’t think that any group should seek to impose their viewpoint on others.
Certainly it sounds like Tobias doesn’t want to have PMI imprinting their viewpoint on corporate america, lest he have to deal with it. And I am not interested in Schwaber or Mayer imprinting their viewpoint on corporate america to the point that I have to deal with it. But, I do believe, that in a respectful and professional fashion, people should advocate their viewpoints and the market can decide which viewpoint they want to subscribe to on any given project.
@ Jordan: this is what I said earlier: Pick the approach which works best for your special needs. Sometimes it is Scrum, sometimes it isn’t. The good, experienced and effective project manager knows how and when to make the call.
@thomasjuli: My suggestion is that it should not be a project manager who makes the call (ideally because there will be no project manager). I also don’t advocate picking Scrum as a methodology, any more than I advocate picking any other methodology. Scrum, employed that way, usually doesn’t work.
What I advocate is exploring new ways of working within the context of complexity science. If we recognize that human systems are complex and by nature self-organized, we can harness that understanding to do great things. While we continue to manage people, and enforce “methodologies” on to them we will keep getting more of the same: frustrated, demotivated employees, and uninspiring products. Workers in an organization, any organization, need to be given the freedom to emerge their own way of working, and offered support, guidance and encouragement, rather than management. Only then will we create workplaces that have meaning to people.
@Tobias: Thanks for clarifying your viewpoint. I guess we will have to agree to disagree on the point of project management. I have really enjoyed this provocative, yet refreshing exchange of ideas. Thank you for bringing up the subject.
Allow me to say a few last words on complexity theory. You raise a very interesting and important point about the nature of human systems, namely that they may be self-organized. We also know that human systems are complex in nature plus – unfortunately – the path to chaos is often a very thin line. This, however, goes beyond the scope of the present discussion thread.
@Thomas: Well we can agree on that as well. Just as long as their is a project manager to make that call 😉 Some advocate that there won’t be such a PM empowered to make such a call. Only a “Scrum Master” and then it’s fait accompli what they would choose eh?
I believe in competent managers and empowered teams. It isn’t impossible to have both. For those that want to do away with project management, given how bad even professional managers can be, how is having a bunch of rank amateur minimanagers going to be any better?
Let’s have good developers who can develop, and good managers who can manage, and train them if necessary. Not just throw all the managers under the bus and call it a win.
@Jordan: your repetitive Scrum-bashing on this blog is getting very tedious. If you actually read the post you’ll see it has nothing to do with Scrum being a good or bad approach to software development. I am so not interested in that debate. This post is about the creation and marketing of fake-Agile which is being used to try to appease people (like you, perhaps) who cannot stomach the idea of true self-organization. Self-organization as a principle exists and thrives far beyond the boundaries of Scrum. If you are going to comment here please keep your comments on track. Thanks.
[post removed as it added nothing to the discussion]
Suggestion to Jordan: write a post on your own blog to express your views. Once again this feels like a hijacking, and there is a limit to my tolerance of accommodating that behavior.
Product orientation vs. project orientation is a significant point, IMO. Methods that emphasize “project management” may cause us to fail to question the necessity for discrete projects. Products can be supported without any discrete projects, and this may in fact be a superior approach.
Dave,
that’s exactly the point.
Old words tend to keep us from asking new questions. Or find new concepts…
-Olaf
Taking a page from Tobias, I chose to capture my lengthy thoughts on this blog on my blog
. In short I realized I can’t argue with Tobias on his acertations on Scrum not being Project Management. That would be like an accountant trying to be an armchair quarterback.
Pingback: Scrum is not Project Management | Agile Anarchy | Articles about the world
I do agree with Tobias’ point that “Scrum implicitly removes waste by starting with a minimilist process where teams only do what is essential to create great products. Nothing is added to the process unless it helps towards that goal.”
I find that with traditional project management, this isn’t always done and there are sometimes processes followed that don’t necessarily contribute to the end goal.
Pingback: Scrum is Definitely Not Project Management « The Practicing IT Project Manager
Scrum is certainly an effective software development method, practiced widely and producing useful software products for many organizations. However, project management is most assuredly not about software development; it is about managing “temporary endeavors undertaken to create a unique product, service or result.” Some of those products happen to be (or include) newly developed software; others might be bridges, or data centers, or implementations of packaged software, or whatever ever else an organization might decide to commit funds to.
To your point, Tobias, Scrum is not project management; it acknowledges no stakeholders other than the product owner, and no products other than software. It does not contemplate procurement, or human resource management; instead, it assumes all resources, people and otherwise, are present and dedicated for the duration, and no other activities matter. Risk management is limited to whatever actions the team can take. Still, Scrum is effective, for organizations that are willing to commit to it, but it is not a substitute for project management, even for software development projects.
Those of us who actually do it for a living approach project management as the study and practice of a mix of skills, techniques, and processes. We select those appropriate for the work at hand, the organizations and people who will do the work, and the stakeholders. PMI publishes extensions to the PMBOK for construction and the public sector; perhaps they will soon publish an extension for software development. But the PMBOK will not be optimized for software development, because it represents only a small fraction of all projects. In the meantime, skilled project managers will manage effectively using appropriate methods and poor project managers will manage ineffectively, just as good software development teams will produce good software, and bad ones will produce defect-laden crap.
Final point: credentials only matter to those recruiting new talent, and those seeking to be recruited. Practice standards, such as Scrum and PMBOK, matter only to those who wish to take a rigorous approach to their work, and share information with other practitioners using a common vocabulary. Those who approach their work like a game of Calvin Ball, just shouting out new rules whenever they feel at a disadvantage, have as much disdain for authority and rigor as the rest of us have for their sloppy work, and dismiss credentials and standards out of hand. Over time, they will be filtered out of the work force by the recruiters, and the rest of us will move on.
Thanks for your thoughts on this Dave. Actually, the way I understand and practice Scrum is not restricted to software development. Far from it. I use the principles of empiricism, self-organization, collaboration, prioritization and transparency to work with all parts of an organization. The framework does, in fact, replace project management (even to the point that it changes the language used, e.g. people are not human resources, but simply people). When we create autonomous teams with clear interfaces to each other and to the organization as a whole there is little need for any kind of outside management. In my experience having a single person coordinate a project is an excuse for everyone else to stay in their silos and not collaborate. We become dependent on the coordinator, even using him/her as a conduit for information. Scrum seeks to remove that dependency and create a more directly collaborative environment.
I think we all tend to re-use the techniques we’ve had success with in our professional lives in other parts of our lives. Yesterday, Elizabeth Harrin admitted to using MS Project to plan her wedding. So, using Scrum concepts in other activities is perfectly reasonable, as long as they fit the problem at hand. Note to psychiatrists: don’t marry economists.
That said, I’ve managed a lot of projects that involve multiple vendors with an odd mix of contractual relationships, multiple operating departments with mutually exclusive interests, a variety of internal and external stakeholders with wide variance in both influence and interest, and a project sponsor with less influence than needed, all distributed across multiple time zones and continents. While Scrum would be a neat fit for the slice of the project that involves creating new code, the rest requires a PMI-style approach to project management. The trick is to apply the correct methods, tools, and leadership styles to each thread of execution, so that the pieces that need a critical-path approach don’t conflict with the less predictable / creative / high risk pieces. And that, I believe, is the proper place for a PMI Agile credential – integrating software development with BPR, outsourcing, compliance, contract management, and so on.
Project manager, like ScrumMaster, is a role. Many of us play multiple roles, and some of us get quite good at switching back and forth. Those folks are the ones you really want on your team, because they become the ambassadors, and the mentors, and the ones that accrue authority, both official and unofficial. Embrace them, even if you don’t share all their values, because the diversity they bring strengthens the team.
> Yesterday, Elizabeth Harrin admitted to using MS Project to plan her wedding.
This makes it sound like an exception, which I’m sure it is. Makes me wonder what techniques most people use to plan a wedding. I imagine it’s a lot more inspect-adapt and iterative in nature, mitigating risk as it arises, and prioritizing on the fly.
Project Management (traditional or so-called Agile) is a particular way of thinking about and addressing problems. Scrum is a very different way, and to my mind a more natural way. I don’t know that project management is never applicable, but I do know that few are willing to cast it aside in favor of a more organic, emergent approach. There is too much at stake, and fear of failure is great. But while we don’t try, we’ll never find out.
Tobias, At the risk of being extremely *ahem* off topic. You want to Scrum-ize the entire organization? Fine. That is your right to claim that you want to do that. What is your roadmap to doing so? What does it look like? The Scrum Guide talks about self organizing “teams” of 7-9 developers. Where is the guide to rearchitect a 500 or 10,000 person company along scrum lines?
I hear a lot of slogans but I’m just not seeing a concrete or even vaguely concrete roadmap on how one would “scrumize” an entire organization. Do you have that to offer or do you just to offer that waterfall “never” works and so we shall all leap into the unknown and each of us shall wander through the mist trying to solve these problems individually ?
Where is the proof that this stuff works? Scrum is 20 years old at this point. Surely there should be some…and what little research I’ve seen is neither unbiased nor reasonably comprehensive. Even placebo’s show a ~5% improvement on symptoms and what research I’ve seen in Scrum land is not statistically different from that.
Nothing personal but if you are saying there is no need for project management then you should be able to demonstrate how that is truly practicable and not an exercise (and risk) for the reader.
Regards,
Jordan
I haven’t actually read the Scrum Guide. I have no roadmap. And I am not trying to prove anything to anyone.
Interesting.
Back to the project management aspect I invite people to take a look at Nanokas original paper, on which Scrum was based. It is an interesting read. It also touches on management issues.
It can be found at: http://www.cs.utexas.edu/users/downing/papers/SCRUM.pdf
Going to try and weigh in here.
Frankly, Jordan, I think you’re so far away from Tobias’s train of thought, it’s difficult to form a rebuttal.
You are talking about roadmaps to change, to rearchitect organizations. Sounds like nothing but “command and control”, the anti-thesis of what Scrum is all about.
If you’re sincerely interested in positive, lasting change, you need to relinquish your control. If you give people a clear goal they care about, they won’t need you to accomplish it, unless they are stopped by rules and procedures you can negate. They’ll find a way to do it themselves, and they’ll be the happier for it, because they’ll feel like they accomplished something worthwhile by themselves. You can’t get that buy-in by imposing rules and procedures.
That’s why there are no roadmaps, that’s why you can’t rearchitect an organization. The idea that there’s one grand unifying theory applicable to all organizations is a fallacy.
You speak about wanting proof that Scrum works; you could just as well turn that question around. We’re talking about an industry that has one of the most woeful success rates of any industry. You think this stems from waterfall being a complete success? Scrum was a reaction to everything people despised about it; it was born from people in the field, wanting to find a better way to work. Waterfall is based on a misguided approach based largely on the notion that people cannot be trusted, are generally dumb and need to be explicitly told how to do their jobs.
I vaguely remember references to 1920s literature already claiming this approach to be severely faulty; I think Drucker first wrote about in the late 50s. Why are we still having this discussing almost a century further on?
Frankly, I find it strange that you can’t seem to find proof in favor of Scrum, when the first Scrum coach I ever met talked about his successful endeavors at Capital One. Not exactly low profile.
I work in government, where command and control is not going away anytime soon. Project managers are seen as those who control the budget and scope, but nobody wants to do waterfall anymore because it’s boring. Agile methodology offers alternatives, and people pick and choose what works in their environment, but it is helping to achieve the primary goal of satisfying the customer in a fiscally responsible way.
Great article simple description especially part “Organizations like PMI, Scrum Alliance, ICAgile and others who are trying to grab a slice of the Agile market are like parasites feeding off the souls of people who really care about change in the world. “
It’s impossible to Scrum-ize the entire organization. A Scrum team manages itself. But how is the team formed? Not by the team itself since it does not exist yet. Somebody/something has to create the team. Thats management. So there will always be management ‘above’ the team. I see a project manager beeing somebody from the ‘outer world’, the management, overlooking the team, hopefully not managing the team. There are tasks in the real-world (e.g. in most companies time tracking is a must, even if Scrum don’t like it) that must be done, and that do not fall into the responsibilities of the Scrum team or the Scrum master. These mandatory tasks (not part of Scrum and not promoting the development of whatever the team is developing) should be overlooked by something that could be called a project manager.
> But how is the team formed? Not by the team itself…
In fact, a Scrum team can form itself and I have seen this happen. The team is seeded by the one or two obvious people needed to begin writing the software and then the team members say what skills they need on the team for completion, and people are added accordingly.
> There are tasks in the real-world
As opposed to which other world?
> in most companies time tracking is a must
Why is it a must? Perhaps because it’s just the way things are. But what is the purpose of time tracking? What value does it add? And how does it propagate the Agile value of trust?
>The team is seeded by the one or two obvious
By who? One or two? From where, a pool of developers, if so who has organinzed the pool?
>> in most companies time tracking is a must
>Why is it a must?
About 72% of software development work (globally) is done outsourced (off-shore, or to subcontractors, professional services etc). A majority of this is billed on a hourly base. It’s difficult to send/accept a hourly based bill if time keeping has not been done. I agree it is a pain, unmotivating, boring and certainly does not increase productivity.
Also some in-house employees also get paid on hourly bases.
@Sam, in any organization the people working there have been selected in some way, usually by a combination of HR recruitment and then peer/hiring manager interviews. That’s a given. Once there though groups of people can self-organize into working units as appropriate (if allowed to). The creation of a new team can take many forms. The least effective form is probably to have some manager pick the team, the most effective to have individuals self-select through dialog with the customer and each other. The talent pool doesn’t need to be “organized” in a conventional sense, it just has to exist, and be ready.
In regards to time tracking, I agree it is a current reality in many organizations. But it shouldn’t be (it is a soul-destroying activity for both the tracker and the trackee). Instead we need to explore better ways of providing value to customers, perhaps starting with the question” are we selling time or are we selling software?” The idea of selling human work hours reminds me a little too much of slave trading. There are better ways to be.
Pingback: Weekly – CW21, CW22 and CW23 | Zsolt Fabók's Page
“seek something more noble please.” immediately followed by a Microsoft window ad. Wow.
Not sure where you are seeing ads (WP doesn’t display them) but perhaps it has occurred to you since writing this that they are in the control of the presenting website, not mine.
The whole discussion denies the fact that projects will largely be a thing of the past, the sooner the better. Predictive management has had its best days, and they are long gone. Predictive management is suitable for predictive environments, of which there aren’t too many around.
This means projectmanager will be a job of the past.
This doesn’t mean management doesn’t have a role in todays organisations. They provide the context within which self-organisation can take place, representing shareholders stakes.
I’ve come late to this, but just a rather off-topic note on using project management to plan weddings. It’s a lot more common than just me. Wedding planners run fixed date projects all the time. I interviewed a florist for my first book about how she prepared for a wedding, and she used many of the same techniques I do at work to manage projects. Laurel Cagan is blogging her wedding: A Very PMP Wedding. And wedding magazines frequently have cut-out-and-keep plans for couples to tailor. I confess that isn’t as project manager-y as putting the tasks in MS Project, but the principles are the same.
Hi Elizabeth. Most Agile/Scrum projects are fixed date too. This is recommended, in fact. Sometimes they are fixed cost too. What gives is scope. Just as it does in wedding planning. It is when we try to fix all three that we fall on our faces, regardless of what magical buzz word we use to manage or guide the project. Most event planning, in fact has people continually making value judgements, reprioritizing, rethinking and resetting expectations. It is likely you and your colleagues are doing just that. Perhaps you are more Agile than you know 😉
Sorry, SCRUM most certainly IS project management.
I don’t know what the acronym SCRUM stands for, or what it is. Scrum, as taught by those who understand what it is (and spelled accordingly), has nothing to do with managing, and little to do with projects. It is about creating a self-organizing, team-centric culture.
It’s amazing that you’re still getting comments on this post even after almost a year of publishing it!
I second your opinion, Scrum is definitely not project management – I think that both PM and Scrum don’t think highly of each other. Scrum thinks that PM is overhead and inefficient, PM thinks that Scrum is kid’s play.
Those PMs are correct. Scrum is certainly play. I see that as a compliment, not a criticism 🙂
Play is the only way! There is no anticipation.
The following link makes a ton of sense to me as I’m just not seeing how Scrum fills in the “bigger picture” gaps. I’m not saying it doesn’t, I’m just not seeing how it. http://www.ambysoft.com/essays/agileLifecycle.html
OMG, “at the end of the sprint, the work is demoed to the stakeholders to see whether everything that was promised was accomplished” Please don’t read the article that was linked to as a reliable source on scrum, as the author clearly does not understand scrum. At all.
I agree. Without even reading, the article looks as if it’s a documentation parody. So many diagrams, getting more and more complicated as you scroll down. I read snippets. It’s the kind of heavy document-and-process driven Agile that I detest. Yeah, very little to do with Scrum, or any form of Agility.
Pingback: Does a Gorilla by any other name still smell? | The Gorilla Coach
For the longest time, I thought that scrum is synonymous with project management. Thanks for putting light on this misconception.
I found this from Google search of basically the article’s title. I think I get what you are saying as I have had similar thoughts recently.
What project management attempts to do is to bring people from across an organisation to work together in a less hierarchical manner. The problem it has in most work cultures is that those at the top like the current hierarchy, thank you very much, and attempt then to impose their hierarchy on project management. The result is that it might not work so well.
There is also the issue of people getting caught up in process, and losing sight of the big picture.
Scrum is quite powerful because it is quite prescriptive (you know, that cult like feel it has) and works very well with the processes typical of software development. It does produce results. It allows creativity, and makes process functional and less onerous. It also does a better job of destroying the hierarchies.
What I imagine could be the future is more organisations working in ways like Scrum, where what will get rewarded is productivity and where people will then tend towards the areas where they can be most productive. Scrum quite explicitly measures productivity, and implicitly rewards it.
It does leave us in a position where the traditional organisational structure is irrelevant. The peter principle starts to die. Managers will be people good at managing rather than people good at doing one job who are promoted into a management role as ‘reward’.
It has always struck me as odd that managers are paid more, when really all they (should) have is different skills. The rock star developer is surely worth as much, or indeed the rock star product manager or rock star scrum master.
Hi Joshua. Thanks for your thoughtful comments on this (now very old!) post. I would love to see this:
> The peter principle starts to die. Managers will be people good at managing rather than people good at doing one job who are promoted into a management role as ‘reward’.
This alone would move us forward in leaps and bounds.
Pingback: Trust Artist Thank You, 2011! - Trust Artist
Scrum, srumban, kanban – are not project management methodologies, they are product delivery methodologies.