Fitting Scrum to project organizations

Isn’t Scrum a project management method?

wood-toyNo it’s not. It’s a product development method (or framework). The good thing is that projects always have a product development part, so Scrum can be embedded in your project. But beware of the  ‘Scrum organizational model’ which is geared mostly to product development companies. If your organization chooses to have projects for all new development, you’ll need to embed Scrum in a project management model.

What is a project?

A project has a start, a middle and a finish. If I tell you this project will take approximately one year, an interesting process starts, most people assume there will be a single release at the end. Even if the project will be done with an Agile process, it will still be ‘steering’ to that single release. All work is planned backward, burndowns are drawn to show you’re going to make (or miss) the deadline. Anyway, most of us know what a project is.

What is product development?

The origins of Scrum point to a different model. The term product backlog says it all, it’s not ‘project’ backlog, but product backlog. The default case for Scrum assumes you’re working on releases of a product, which has a virtually infinite lifespan like MS Windows, Atlassian Jira, Patientkeeper etc.

Scrum is a method for making development part of your entire business. Or better yet, if development is an integral part of your business, use Scrum. You rarely start projects because new features (large of small) are just put on the backlog. Developing software is what you do. This differs from organizations that do projects to not only develop software.

Can we do projects with Scrum?

Using Scrum for projects is surely possible, but you can’t use Scrum for projects without some project management practices like tracking budget, planning resources and loads of extra communication. For instance, if you’re using Prince2 and Scrum, you’re mixing two models, the ongoing development model of Scrum and the special initiative (a.k.a. project) model of Prince2.

A pure Scrum implementation should be embedded in a big vision, when you’re working on a product that vision is clear, product managers are hired for that purpose. On the other hand, in a project the variations are much more extreme, the choices of technology, budget, features etc. are much harder to make. In many cases projects are done by people who aren’t familiar with the context and history of the company. So expect a preparation phase where the team at least gets acquainted with the environment.

The thing to watch out for when implementing Scrum is that you don’t try to force the product development model onto your organization. If you use projects, accept that there is a ramp-up at the start of the project. And you might need a different process for different phases of the project. For instance, when your project is a one-off special campaign launching project, you can’t expect the whole organization to react quickly (just-in-time) to your impediments. It’s a matter of economics: any process changes they make for your project will be obsolete by the time your project finishes, which is not always worth the effort.

So what are you saying?

You can use Scrum in many contexts, it fits product development companies like a glove. Organizations that are project-driven can also benefit from Scrum, but not without some extra project practices. Expect a phased process and accept that in a project some impediments are simply not worth solving. Much of the frustration that goes along with Scrum implementations boils down to forcing the product development model (dogma) on your project organization. It’s like forcing a cube in a triangular hole, you’ll get frustrated and it won’t fit, no matter how hard you try. A project management method can be the adapter that makes Scrum fit.

Advertisements
Fitting Scrum to project organizations

5 thoughts on “Fitting Scrum to project organizations

  1. Gerard Janssen says:

    You make an excellent point here. I think your point of view actually has two angles: a socio-mechanical one and another that is socio-economical. Scrum definitely is the way to go for (product) development that is geared towards continuously delivering value. The key assumption being that the continual return is higher than the investment per time interval. The purpose of using a project model as you describe is to create or simulate the product development conditions: create a social structure with domain experts and such that can steer the vision of the project/product and create the economical structure (business case) that explains the financial rationale behind the investments being done.
    Because of the business case driver, we often push projects to be discrete in time, thus missing out on the opportunity to consider if we should turn projects into products. Delivering early and often can make the investement/return balance more visible. That can be a real benefit of Scrum!

  2. Patrick says:

    It would be interesting not only to find out if Prince2 actually fills the gap in a satisfactory way, but also which parts of Prince2 actually complement Scrum…and strenghten it in the end. The SU and IP phases will be obvious, but what after those? And how about project closure? Prince2 is the obvious choice in NL. But what about PMBOK? Jeroen Venneman already did some investigation on combining management aspects from DSDM with Scrum.

    Applying additional management practices to Scrum may actually mature it more quickly, provided that the resulting effort fits the organization.

  3. Mary says:

    @Gerard Janssen
    Not sure what you mean by socio-mechanical and socio-economical en which part in Machiel’s blog applies to either of these ‘viewpoints’ (or points of view?). You start by saying Machiel makes an excellent point but end your comment “scrum forever!”.

    Can I add to this discussion by posting what I wrote a friend in January of this year (in Dutch)?

    Quote: Wat ik heb meegemaakt in e-mailcontacten met de twee uitvinders van scrum: Jeff is meer van: laten we doen wat werkt en Ken is: alles wat niet precies scrum/agile is, is per definitie ‘züm kotzen’. De laatste is echt recht in de leer…En in de praktijk zijn er even zo vele mensen die ‘recht in de leer’ zijn v.w.b. Prince2, SDM, XP, TWG, PP, Crystal, DSDM enz. enz. zijn. Het is zo exclusief.

    Elke methode, denkwijze en werkwijze heeft zijn voor’s en tegen’s en zijn het meest toepasbaar op een bepaald gebied en in bepaalde organisaties. Scrum is, laten we eerlijk zijn, specifiek bedoeld voor het proces van ontwikkelen en bouwen van software. Maar veel van de mooie dingen van scrum zijn met enige lenigheid van geest ook toepasbaar op andere terreinen. Net zoals lean niet alleen toepasbaar is in de productie maar ook op –andere- logistieke processen en op software…..En dat geldt voor de andere methoden ook.

    Ik zou nu zo graag de verbinding tussen de methoden, denkwijzen en werkwijzen willen vinden. En ‘interdisciplinair’ kijken; dat is een soort geïntegreerde vorm van multidisciplinair.

    Om dit beeldend te maken: multidisciplinair vind ik er als een assenstelsel uitzien (daar staan de dingen naast elkaar / ieder vanuit het eigen paradigma daar krijg je 1+1= 1,5 effect) en interdisciplinair als een vendiagram (met overlappingen, daar krijg je dan het 1+1= 3 effect) Meer inclusief….Maak ik mijzelf nu helder? (en probeer dat maar eens fatsoenlijk te vertalen in ENG!)

    Mensen die welke methode dan ook – vooral de jongens en meisjes die de werkelijkheid geheel reduceren tot een spreadsheet en niet wijzigbare planningen of IT jongens die alleen denken in termen van 1 soort scrumboard en burndown charts en deze vervolgens- heilig verklaren zijn in mijn idee sektarisch. Ik noem de eerste soort wel “spreadsheet fundamentalisten” en de tweede soort “sterk bijziend”

    En er zijn ook mensen, vooral software ontwikkelaars, die denken dat werken in een scrumteam, vrijheid / blijheid is, die zijn heel erg op het verkeerde spoor. Vrijheid impliceert niet vrijblijvendheid maar discipline. Een scrum master moet met welhaast militaire precisie zijn mede teamleden, de omgeving en de voortgang in de gaten houden en heeft daarbij, afhankelijk van de omgeving waar gewerkt moet worden, meer handvatten nodig dan in scrum beschikbaar is. Maar goed, ik kan zo nog wel even doorgaan.

    Waarom weet eigenlijk niemand dat we ook een Nederlandse methode van projectmanagement hebben? Dat zegt dat een project een begin en een eind heeft, kortlopend is, en een unieke aanleiding en resultaat heeft. Alles wat langer dan een jaar loopt behoort tot de normale lijnactiviteiten en alles wat korter is dan een paar weken is gewoon een klus. Er zijn geen voorschriften maar dingen om te overwegen. Verder zal ik er niet over uitweiden want ik wil er geen reclame voor maken. End quote.

    Let’s get off of our own islands en make this world more Agile.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s