Time for a grown up debate: Methods and Scrum

Time for honesty

I have been writing recently on the alarming trends around PM ‘methods’, including the latest edition of the Scrum Guide, which was updated in 2017.

There are many people and groups developing and publishing methods, guides and standards etc. and we have to hope they are being written for the good of the world of delivering complex projects more successfully. This is a great ambition, but we need to be very honest and careful when we address such challenging topics.

Projects are never a ‘production’ process

People have said to me in the past “why can’t someone just write a book that tells you exactly what you need to do every time you manage a project”. The truth is that no such book can ever work, or will exist. You can write a book on principles of running better projects (Agile is a set of principles and values, not methods). However, there will never be one book covering the exact steps that will always be required to deliver even one type of project (e.g. software), let alone all projects.  For me, the Scrum Guide is way too prescriptive.  And if you agree with this comment, you have to ask why is this, in a very honest, objective and transparent manner.

The Scrum guide: for business or hobbies?

On the subject of being honest, the Scrum guide talks about: “control, planning, estimating and risk” and even “monitoring progress”!!!! What does that sound like? Wash my mouth out if I even mention the “PM” word!

Interestingly, it sounds just like some of the key things you always want to do on projects but dresses them up in “new” terminology. One example is calling estimating “planning poker”, ⁽¹⁾   as if it was something new (it’s based on something developed in the 1940s). That is treating people as if they are really stupid, but sadly, large numbers have swallowed it. Why? Some communities have hated project management for years, mostly as it asks questions that: a) people don’t want to hear and b) even more, don’t want to answer. PM also asks people to make commitments and in business, this is often necessary. The job of any team is to develop a strategy to cover development and meet the broader needs of the business and its stakeholders.

Scrum has at its heart some excellent aims (transparency, collaboration and continual feedback, e.g. daily Scrum etc.). However, some of the key principles (in fact “rules”) within the Scrum Guide are ludicrous. If your project is a hobby, then the Scrum guide is fine. If your project exists within an organisation that operates on a commercial basis with stakeholder needs, elements of the Scrum guide are fantasy. I will go even further and say it panders to the totally introspective view of the world of one particular group (in order to be popular to large numbers within that group, e.g. “Agile doesn’t do dates”).

So let’s be totally honest about some of the Scrum guide:

1. The guide itself is entitled “Rules of the game” and it is full of them. Rules are only there because: a) some people can’t work without them and b) they form a great basis for running certification exams ($$$$$).  That’s why the Scrum Guide is prescriptive.  Being prescriptive forms the basis of exam questions, leading to the vast revenues in Scrum certification.
2. In Scrum, the team is made up of the Scrum Master, Product Owner (PO) and team members. There is a total refusal to accept any other roles. That is so, so wrong and driven by dogma. Large numbers of projects that include software development have many other elements other than the software itself. Who among these roles is going to plan and manage those elements? The PO? Scrum Master? I don’t think so.
3. There are many strategic elements that need to happen at the start of a project that precede the development of a product backlog (or Epics) or equivalent. Who does this and how does this happen?
4. The guide is totally anti the original principles and values of Agile. The original Agile manifesto states “individuals and interactions over process and tools”. Read the Scrum guide; stand back for a moment and compare these two things in your mind. The guide is rules, rules and more rules. Is this true to the founding principles of Agile?
5. Scrum (as in the guide) is a crude production process for developing software.  Sure, better adaptations of Scrum can work well as a product development method – but the guide goes out of its way to refute the needs from a ‘project’ perspective. This is pandering to those involved in the development itself. Scrum is very weak around responsibility, commitment, release and timescale planning.
6. Without a doubt, one of the most contentious items is that Scrum is based on only the development team choosing what (i.e. which items from the Product Backlog, and how much) goes into each Sprint. Astounding! Sounds very convenient (and nice for the team) but is that real-world?
7. The other is the complete avoidance of specific accountability in Scrum. The theory sounds great: “transparency creates accountability”.  The problem is that human behaviour way too often just does not follow theory, to put it mildly.  There are also many misconceptions about this topic too. We need to ask where does this come from.  It’s the dogmatic refusal to use the words “manager” and “management”.  Truly great teams can self-organise.  The reality is that no organisation is blessed with an abundance of truly great teams.  The result of implementing this theory can be really ugly.  Teams without accountability are of little practical use in business.

Vested interest – with some surprising players

Vested interest, by small highly influential groups, specialist organisations (the snake-oil sellers) and even ‘professional’ associations is ruining the real debate on a) what works well in projects and b) how to spread this more widely.

Related pages:

If you agree with any of the above you may find the following pages useful:

1. https://www.pmis-consulting.com/why-many-agile-projects-still-need-project-managers/
2. https://www.pmis-consulting.com/why-the-current-focus-on-methodologies-is-totally-wrong/
3. https://www.pmis-consulting.com/issue-with-certification-training/
4. https://www.pmis-consulting.com/project-management-group/

Notes:

1. “Planning Poker” is derived from an estimating method, developed in the 1940s, called the Delphi technique. It’s a method primarily for avoiding estimates to be influenced by any one person or group when multiple people have input to estimates.