Can Scrum and Project Management live together? [closed]

Question

Can Scrum and Project Management live together?

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

Answer 1

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 2

Yes, Scrum and the PMO can live together. They're concerned with different things though, so the edges where the two meet are going to have to give a little. There will be some conflict at the intersection. Traditional PMBOK approaches are a poor fit to product development domains like software development, but there's quite a bit of smart statistical controls in the PMBOK, and skilled project managers who can be taught to manage flow rather than schedule are precious.

Neither Scrum nor Lean nor the Toyota organization suggest that either hierarchy or directed authority are off-limits. The definition of "Self-Organization" has been significantly stretched by software developers over the years until it has become largely indistinguishable from "Self-Determination", which was never the intention.

Toyota, for example, is a very hierarchical organization that depends very much on command and control. The difference is that it's a Learning Organization and managers at Toyota are required to have mastery of the work done in their purview, and have a duty to teach that work to workers. Team members at Toyota who envision possible improvements to their work and to the process are coached by their managers through the scientific process to prove their ideas. It helps that the process isn't shaped to fit the organization, but that the organization shifts to fit a process that is continually improved.

There is always an element of command and control in any organization. Even Scrum teams are subject to it. Even if a work team itself is perfectly flat, a Product Owner can still call the ball. Software teams have seniors and juniors, and their opinions are not perfectly equal. On Lean teams, managers are expected to be masters of the work, or have, as Toyota calls it, "towering technical competence". If management isn't skilled or is too far from the work, then they'll likely make bad decisions about the work. This is the real problem, and Self-Directed Work Teams (SDWT) are a predictable result of workers seeking to insulate themselves from poor management. SDWT is not the best answer, but it might be the limit of what an organization might achieve.

And finally, Scrum is not a project management methodology - at least not from the perspective of the rigor of the PMBOK or of Lean. But then, the application of the PMBOK to software development without significant modification to account for the nature of product development is often a fool's errand, so efforts to displace the PMBOK on software teams is understandable.

At best, Scrum is a timebox planning methodology. That's still valuable if it's the thing you need, but there's nothing inherent in software work management that suggests you need timeboxes like sprints and iterations. In fact, the upwelling of interest in iteration-less approaches like Kanban and Flow-Based management are a testament to this.

In the end, there a heck of a lot of orthodoxy built up around Scrum now that wasn't introduced by Scrum's founders and leaders, and often isn't supported by them. The same can be said about how PMOs operate. Focus on the principles of flow and learning cultures and you might be able to avoid the blind alleys and myths that gather around methodologies once they've been in the mainstream for five years or so.