Can Scrum and Project Management live together?

Question

Can Scrum and Project Management live together?

Can you take the best of both worlds or will combining these two methods create more chaos?

Would Scrum work better with a project manager doing PMO type work and cross function with the product owners and scrum master? I believe that a dedicated PMO would track compliance, artifacts and quality. This would allow the Scrum team to continue working without worrying about logistics or paperwork. Has anyone tried to incorporate different ideas (scrum, six sigma, pmp, lean?)

Answer 1

I think you are going it from the wrong side.

First you need to know what kind of team you have. Then start from that knowledge and use the appropriate methodology for your team. Rather than trying to use some methodology for your team. Do a methodology for your team. That means see what they are comfortable doing and what they think would benefit all of them.

For example: Usually when a team failed using RUP, it wasn't because they didn't follow the guidelines, but because they tried to follow all of them.

Generally I think it's better if developers don't have to do paperwork and logistics. Either they are bad at it or they would be more productive doing development.

Answer 2

Your question doesn't make sense since scrum is a project management framework but here are some things to consider:

1. Quality is the sole responsibility of the Team; not any PM.
2. Not sure what you mean by "artifacts", but the few scrum has (backlog, burndown) are maintained by the PO and Team under the guidance of the ScrumMaster.
3. There were no "best parts" to waterfall to want to consider continuing to use once you embrace Agile.
4. There is no "paperwork" in scrum; its considered waste.
5. People try to combine things all the time. But most of the time they get the WORST of all worlds; not the best. Most mistakes teams make in implementing scrum is to make excuses for why they can't do it the right way. Then they claim it would be better to combine in something else and just make a mess of the whole thing.

Answer 3

A few things to consider:

• Scrum is about empowering the team as opposed to command and control management style.
• There is no manager in Scrum, there is a ScrumMaster which is a servant leader.
• The ScrumMaster is responsible for the Scrum process, making sure it is used correctly and maximizes its benefits.
• The ScrumMaster has to remove impediments so that the team can do his job in a productive way.
• Scrum implements transparency with a minimal set of practices/roles/ceremonies and there is no real paperwork.
• There is no real PMO type work in Scrum, most of PMO work is (considered as) waste.

So please, keep your PM habits away :)

And during an adoption, I'd recommend to do it as in the book (Shu), don't try to adapt it for now (Ri) (see Alistair Cockburn on Shu Ha Ri). I wouldn't even consider things like Scrumban (a modified version of Scrum using Kaban for continuous flow, no more iterations) at the start.

PS: Agile methods have all been influenced by the Lean movement (most, if not all, Agile manifesto signatories had The Machine That Changed The World in their shelves). Some could say Agile methods are a transposition of lean concepts (for new product development) to software development; others would say Agile and Lean share the same theory (see for example Jeff Sutherland's article The First Scrum: Was it Scrum or Lean?). To me, there are obvious similarities (it would be easy to map the whole Toyota Production System "House" on Agile practices) and I find Lean useful to understand how Agile works and how to implement an Agile process efficiently. So I use Lean as an as an additional toolbox. But to me, Scrum has already everything to make your development process lean, if well implemented. So there is no need to mix it. Just apply it (Shu).

Answer 4

Has anyone tried to incorporate different ideas (scrum, six sigma, pmp, lean?)

Essentially all of the above derive from the Japanese Quality Movement in the early 1980's. It's all about increasing quality by reducing waste, called Muda in Japan

Lean was Toyota's implementation of the Quality Philiosohies and Six Sigma was General Electric's attempt to Americanize Lean based on corporate culture of the day.

Fast forward 20 years and the IT industry have realised that all this 'lean' thinking is a great idea for building better quality software, faster. In what has been labelled Agile.

XP (extreme programming) and SCRUM are just two different implementations of Agile techniques.

Tradiational management and software management is coming up against these new ways of thinking.

You can't have it all. Either your focus is on command and heirachy (DO AS YOUR TOLD, traditional approach) vs Collaboration and working together to reduce wastes and deliver amazing things to customers (LETS DO IT TOGETHER, new model).

If you want to go deeper on this, the best approach is to read back on the original LEAN philosophies and then see how you think they can best be applied to project management. Many of best project management ideas were already considered as part of the original lean movement, read the book 'The Toyota Way' and look into lean that is where you can find your own answers.

Google: the seven types of muda for a start.

Answer 5

Found this useful link today, regarding The software industry has an appaling record for project delivery. Which address your exact question.

Suggest you browse around this site to get more of an idea:

http://behaviour-driven.org/SoftwareIndustryRecordOfFailure

The above the wiki for the very excellent Dan North who proposed the idea of Behaviour Driven Design (Premise: The way we think depends on the language we use and this can be applied to software also).

Answer 6

Well, first of all, Scrum is a project management process, so asking if Scrum and project management can coexist is like asking if water and H2O can coexist.

Second, the PMBOK defines the project manager role as having responsibility for the success of a project. Similarly, in Scrum the Product Owner is responsible for ROI, so the responsibilities of these roles are similar even if their duties are different. Scrum eschews a command-and-control management structure, emphasizing the need for self-managed and self-empowered teams that collectively make commitments and own delivering on those commitments under the principle that the people who do the work make and own the commitment... no responsibility without authority. In Scrum, the Product Owner provides guidance to the team via the product backlog prioritization and by the defined acceptance criteria for each backlog item ("Here's what I need done and here's the functionality that must exist for me to be happy"). The Product Owner also has the final say as to whether something is done or not; if the team doesn't complete a backlog item to the Product Owner's satisfaction for any reason then the Product Owner can reject the work. I'd say that makes the Product Owner a very powerful and important role in Scrum... IMO the most important role in terms of project success.

You might want to read this blogpost on selecting the Product Owner for more information on the Product Owner role.

Answer 7

I think the way I read your post is that the PM does 2 things:

1) Creates artifacts necessary for the business (like compliance)

2) Manage the project

As far as #2 goes, that job becomes encompassed in the PO and SM roles. The PM continuing to do it will add confusion and hurt the process.

As for #1, that is a vital role. If the business needs this, why not add the creation of these artifacts as part of the definition of "done" and add them to the team as a member who performs this specialized task. Alternatively, you could do this outside Scrum with no one even aware that it's happening, then perhaps providing those artifacts to the PO.

Answer 8

Scrum is project management, just not the way project managers do it, but as Scrum does it. In short, Scrum does the compelte opposite of what people think of and are tought about project management. So, from that angle, I would say no.

On the other hand, project managers can be very efficient Product Owners.