I’m therefore beginning these little perspectives between Scrum and CMMi with project management questions. I’m not going to highlight -once again- the dichotomy between the project manager and the scrummaster, it doesn’t necessarily interest me as it is presented and it isn’t necessarily as true as all that. No, to just say what separates in my practice of Scrum and CMMi the notion of project manager/scrummaster I’m going to rather rely on a passage from the most excellent “Lean Software Management” by Mary and Tom Poppendieck (which I encourage everyone to read) which itself cites the book “What leaders really do” by John Kotter. Synthetically we’re going to separate two profiles: the managers and the leaders.

On the manager side: you plan, you budget, you organize, you staff, you track and you control. On the leader side you indicate the direction, the vision, you bring people together, you motivate the teams. There you have it, everything is said. Yes I know I’m cheerfully breaking down open doors.

1st open door broken down: Nothing prevents a CMMi project manager from indicating the direction the vision, bringing people together, etc.. on the contrary it’s the panacea. The reverse for the scrummaster is also true. Only you must keep in mind that you will first ask a CMMi project manager to organize to track and to control, and that you will first ask a scrummaster to bring together and support the team.

2nd open door broken down: Some people will never be compatible with one of these two missions, it’s not in their nature, it doesn’t interest them. I emphasize especially the notions of bringing together of motivation, of leadership, and here I pull out a joker a bit cliché: all of this is also very much a matter of empathy and psychology.

Some paradoxes too:

Management desires leaders, it gives cohesion to its teams, it generates dynamics, and they are generally strong differentiators in calls for tender. Because the leader possesses a strong (often technical) competence. It’s often on this that he establishes his leadership. Yes in my eyes a ScrumMaster must have a substantial technical competence, which is absolutely not a pre-requisite for the Project Manager (CMMi). On the contrary often I see quite a few people desire the position of Project Manager to extract themselves from technical contingencies: they no longer wish to develop. They want to gain “height” (do the specifications, track, control, etc.). It’s the verticality of CMMi roles. Verticality expressed also by the hierarchization: the Project Manager is overseen by the Project Director. Conversely I perceive the Scrum model as horizontal. The Scrummaster, the Product Owner, the Team, everyone is on the same level. I return to my point: management desires leaders for all the reasons mentioned above. But it annoys them quite a bit. For them it’s simpler not to value certain people, it’s simpler to interchange people, to consolidate and to forecast if there is no disparity in the profiles. It’s a fairly strong reproach that I make to the implementation of CMMi as I experienced it: a strong hypocrisy to continue to present people as equal, or at least “well enough armed” (thanks to the processes implemented to respond to the CMMi model), to be able to be placed, moved, interchangeable. I’m exaggerating a bit, but it was the dominant idea in my experience. In fact, everyone knew exactly that it’s the opposite that was true. Management wants leaders but prefers to manage “managers”. In fact here I’m extending the notion of leader to that of key person. It’s different, but in the relationships that I perceived between management and team, with scrum or cmmi, the answer was the same. It disturbs CMMi to have key people because precisely the model refuses too strong personalization and is based on strong practices. Yet everyone knows that a project is built on key people. Last remark on this subject, a key person one day is not necessarily so the next day. I mean by this that it’s not a way to distinguish good and bad, not at all.

The verticality that I mention in the classic CMMI model and of the project manager, has the merit of proposing a clear hierarchy: project manager, project director, even top management, and then the -lower- the developers, transverse, the quality managers, etc. It is clear that for developers it’s not rewarding. But it’s quite restful (less responsibility and involvement). It’s the hierarchy that will absorb the shocks (when it plays the game correctly, and the Project Manager is not a fuse). It has the means to substitute the project manager (or another person) if something gets stuck (for x reason, if only after a certain point wear…). With Scrum it’s more complicated, the system is normally as I say, horizontal. It’s not simple. If a team member doesn’t work out? (“we get him out as soon as possible!” tells us Extreme Programming, “have you talked to him and what does he think” tells us scrum, in both cases nice phrases but not very realistic). No escape, far fewer levers to play with. The mayonnaise takes, …or not, there is no predictability. A Scrum project where the mayonnaise doesn’t take, it’s complex, what to do except acknowledge the failure and: change the teams (!!!), switch to another mode? But at least we will have quickly visibility on this problem.

This role of ScrumMaster that I associate with the leader is all the more complex as this leader must step back so that the team and the product owner take their responsibility.

So,

The CMMi project manager is first there to consolidate all the info, traces, planning, etc. of the project. If something goes wrong he is supposed to anticipate and alert or trigger actions to mitigate present risks or problems that appear. He monitors: the scope, the deliverables, the counters, the teams, etc. He reports to his hierarchy. He often struggles -almost hand to hand :p - with the client to protect the very strict framework of his contract. He makes sure moreover of the reliability of his contract and that his action and resource plan is clearly defined and applicable. “The project will be delivered on time and on schedule with all the functionalities defined in the specifications”, that’s his mojo. At the limit if the developers and the client hate him it simplifies the relationships.

The ScrumMaster is first present to consolidate the team around the value to generate: the user stories, the functionalities to develop, the real need of the client. If something goes wrong he must take care of it or find within the team or on the product owner’s side a solution. He makes sure that it’s first value that we produce. He collaborates with the product owner and the team and supports them when they report to the client (through retrospectives). He must also plan the releases and the sprints to come. When his manager asks him how he consolidates the project data: he answers that he only has to observe the photos of the radiators (post-its on the walls) and gets a tongue-lashing. “Yes we haven’t covered the entire scope but what we have delivered is usable, of very good quality, and brings you a lot of value; for you the quality/price ratio is excellent”, that’s his mojo. If the developers form a close-knit team that he has been able to motivate around the client’s needs he knows that the project will succeed.