More and more organisations (including PMO’s) wish to leave behind their more or rather less glorious project success in literally switching to agile project management process models, and start asking for scrum.
In the teamblog of ‚oose innovative informatik‘, a German consultancy with roots in the software development business and specialized in agil project management training and coaching, I just found a German written article with the self-explanatory title „Why you should neither start with Scrum, nor finish with it.“ Good point that should be forwarded.
However, while I understood the message in a way, I will summarize below, my developer colleague Michael Hönnig had a completely different conception of Jan Gentsch’s contribution.
1. Why you should not start with Scrum:
Gentsch refers to an interview with Ken Schwaber, where Schwaber emphasizes, that Scrum ist only „a simple framework within which the “game” of complex product development is played“ and explains later on: … „Scrum purposefully has many gaps, holes, and bare spots where you are required to use best practices – such as risk management. Scrum then shows you how well that approach works through transparency, so you can continually optimize the approach.“
For me, and probably PM(O) colleagues, this implies, that you certainly master those process models (PRINCE2, waterfall, XP, Rapid Prototyping, etc.) and PM standards (IPMA, PMI) that suit your kind of project(s) best. And also, there are certain „people focused“ and meaningful process steps for project management that should be natural within every client-contractor relationship, like e.g. clearness on the objectives („co-operation“) and requirements engineering, stakeholder analysis and management, risk management, conflict management, project set-up with team building, etc.pp. Each process step or even project phase of itself carried out not despite the agile manifesto, but with respect to it.
2. Why you should not finish with Scrum:
To put it with Ken Schwaber again: „Scrum is a framework. XP engineering practices can be used within a Scrum Sprint to improve quality and productivity. Lean is a way of thinking that optimized complex, repetitive processes.“
Earlier in the interview Schwaber says: „Scrum exposes every inadequacy or dysfunction within an organization’s product and system development practices. The intention of Scrum is to make them transparent so the organization can fix them.“ This should be embedded into the philosophy of „lean“, where Schwaber refers to the value-stream analysis as an example only.
Thus his and Gentsch’s credo can be read as: if you really follow the philosophy of Scrum with its indispensible retrospectives, you cannot persist („finish“) in doing Scrum, but end up with something very special, very mature.
Now I will finish with a last citation, again, from the Schwaber interview asked for his „next goals“: „To create many environments where Scrum helps people look forward to coming to work, where customers love working with software developers, and where the quality and predictability of our efforts significantly increases.“
This also describes my personal drivers to work actively on organizational changes: I love to facilitate environments in which people like to work and co-operate. This naturally implies „agility“.
At any rate, wether you start with Scrum or end with Scrum or switch to Scrum: it will accelerate your team’s communication and present you more transparency – have fun!