First, a short background: I’m a university lecturer, and software development process has been core of my teaching as well as practical duties for the last 10 years or so. Jumped on the agile bandwagon couple of years ago, and this year got a small grant to stay a week with Luminis in order to see Scrum at work—with the aim to transfer (some) of the knowledge into my courses.

This post is a summary of the differences between the “book edition” (Schwaber & Beedle, Kniberg’s “From the trenches”) and “Luminis edition” of the Scrum process.

Obviously, Luminis have been doing Scrum for upteen years and know their job well. Obviously still, no Scrum incarnation is the same by definition—there are the non-prescribed things you must find your way through, and there are the times when local context makes you breaking the rules.

So let me state: all core stuff prescribed by Scrum is there and there’s no point reiterating them in this post. The differences follow.

Local tweaks and optimizations

These are the things which Scrum says “decide on your own what suits you”. So Luminis have:

• Sprint length mostly shorter than 30 days – one project used 5-week sprints, one converged towards 2-week sprints. The driving factors are complete product integration needs (other teams’ development pace) and higher ability to embrace change.
• Sprint backlog maintained in Jira – not as Scrum board post-its or similar – and contains literally anything that has to be done, including daunting (“refactor”, “document”) and management (“prepare for demo”, “scrummaster”) tasks. Enables traceable project and change management, documentation, and off-site customer visibility.
• Some cherry-picked things from Rational Unified Process (RUP) are used, e.g. the need for product vision, use cases with their template, quite detailed architectural documentation along the 4+1 views (but kept as Wiki page to stay agile )
• Explicit “requirements analyst” and “system architect” roles – both are managed by the product owner and available to the team to provide details into backlog items and implementation; analyst often staffed from client’s side, architect as team member. This offloads some burden from the product owner who can concentrate on other things, see below.
• Requirement analysts and system architects run 1-2 sprints ahead of team – so that they can feed the backlog early enough.
• Planning and estimation is simplified – done in pairs and wrapped-up on whiteboard (no task cards and poker), normal hours often used in estimation (not necessarily scenario points), standard “priority” field used for backlog items (not relative importance value).

Notable diversions

Here comes the real interesting stuff. You could call these “violations of Scrum” if you wanted but then listen to the local circumstances which drive the process modifications. Roughly in decreasing priority:

• There is no well-established product log – its stories get listed as sprint goals but not picked up from a backlog list. Also, sprint goals are composed as a list of scenario names (ie not a single sprint goal + a list of scenarios). This is acknowledged as current process weakness, OTOH it does not seem to have negative effect on project’s convergence to their goals.
• Product owner has a more managerial role in addition to the prioritization duty – is responsible for project’s success from client’s point of view and is not “requirements analyst” for the team. His role entails mainly acting as a firewall to take on disturbances and “brilliant new ideas” from client, managing requirements analysts and architects, and perform stakeholder management i.e. negotiate/interface with client management.
• Consequently, product owner need not be responsible for product backlog management – basically explains/discusses goals, priorities, hi-level requirements with scrum master who then maintains the backlog.

Put concisely, the product owner makes sure the project is effective (in business terms), Scrum master makes sure the project is efficient (in sprint velocity terms).

This is perhaps the most interesting point of Luminis’ Scrum edition. Their experience is that Scrum masters – staffed by more junior members – may not be perceived by client’s management as “senior enough”. This would in effect block their ability to firewall the team on a sufficiently high level, influencing client management goals and local politics (and boy do these factors steer the projects—most issues which hamper work aren’t technological but concern human nature and communication).

The product owner’s role is therefore changed. They must know client’s “board members” needs—the timeline and priorities they live in (“outside world”). Staffed most often by a Luminis senior level member, their experience makes it easier to align internal development with client’s processes, and their rank plus the fact they are outside client’s internal politics make it easier to do/say certain things (e.g. negotiate with top-level client management, make “impossible” things happen).

The parting words

I’d like to thank the guys from Luminis for being very helpful, open and friendly—it was a great week