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”, (1) 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:
- 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.
- 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.
- 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?
- 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?
- 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.
- 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?
- 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.
If you agree with any of the above you may find the following pages useful:
- “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.
I agree. I’m not anti-Scrum because I have enjoyed great success with Scrum, but always adapted it and always blended with techniques from other methodologies. Scrum alone is not enough.
Hi Kelly – thanks for your comment and I agree totally. I am not against Scrum in principle either. Quite the reverse. Adaptations of Scrum can work really well. My issue is with a lot of what is in the Scrum guide itself.
Put simply, when did dogmatic adherence to any belief system ever make sense? It certainly does not chime with my interpretation of the principles of Agile PM!
‘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’ – this is blatantly false; the business/users prioritize and groom the product backlog of work, facilitated by the Product Owner. The development team simply choose a quantity of items from the top of that product backlog.
All SCRUM projects I’ve been apart of have either failed and/or have failed to meet the expectations and aspirations of the stakeholders. This is despite witnessing different ways of implementing the SCRUM Framework by SCRUM teams in order to be as practical as possible and to adjust it to the demands of the project, and to fit with the strengths of the team; it just doesn’t work, i.e., provide any value and impact to either the development team or to the customer and stakeholders/SMEs.
SCRUM is the most crude and lazy way of developing software. If you don’t care about producing reliable and sustainable software systems do SCRUM. Delivering the right software on time and on budget, but, which is also reliable and sustainable is “hard” and SCRUM makes it even harder, because, it doesn’t champion or encourage developing it in the most rigorous and robust way with the right attitude and discipline which is required for software development and experience has taught us this the hard way.
SCRUM just doesn’t give us anything, other than a cowboy and maverick way of delivery the worst possible piece of software imaginable and ends-up leaving everyone involved incredibly embarrassed. SCRUM is inherently anti-Systems and forces SCRUM teams to take an anti-Systems approach when we know from experience that to design and engineer complex systems requires having a Systems mindset or expect to fail or deliver something which the customer/stakeholders haven’t quite asked for which is typical with SCRUM-based projects.
Fortunately, I’ve never had this problem, because, I’ve always take a Lean Systems Engineering (which is the most Agile of all Agile methodologies; Agility on steroids, if you like) approach to leading and managing projects and teams of engineers in order to design, engineer and deliver complex systems/projects, i.e., I take the principles and practices of Systems Engineering and Project Management in a combinatorial, but pragmatic way. This is my approach or the approach I use for leading and managing complex systems, including systems of systems and for leading and managing teams of engineers. So, I basically combine Project Management principles and concepts in a pragmatic way with Systems Engineering which always allows me (with my teams) to deliver reliable and sustainable systems on time and on budget, but in a very short time-scale and far shorter than SCRUM-based projects which you are unlikely to do with SCRUM. With SCRUM, it’s just continuous re-work after re-work (this is actually SCRUM in practice) in bi-weekly sprints which falsely gives people the impression that progress is being made when in reality, you’re covering the cracks, moving side-ways or even backwards which leads to an increase in the timeline and finally leading to fragile software development and delivery.
In conclusion, SCRUM is NOT Agile, but, Fragile and the sooner we learn and understand this, the better.