💾 Archived View for nader.pm › about-the-scrum-in-construction-webinar captured on 2022-03-01 at 15:10:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Nader K. Rad, 2020-09-04
There was a webinar titled Scrum in Construction from Scrum Inc (the company of Jeff Sutherland, the co-inventor of Scrum).
As an attempt to help save both Agile and predictive methods, I'm going to explain the fundamental mistakes in this webinar. Well, that's one reason, and the other is my life-long mission of making enemies in every community!
The most basic problem in this webinar was mistaking inspiration for implementation: There's a significant difference between being inspired by Scrum to make some positive changes to your project, and implementing Scrum in your projects. What panelists described in this webinar was a summary of their inspirations, but they presented it as if it was an implementation of Scrum itself.
The main question is how one can use Scrum in a construction project, and yet, the panelists didn't answer that. Most of their talk was about how great it is, and how much improvement they'd seen after they started using Scrum (of course, accompanied by diagrams).
Sometimes, they mentioned points about their method, especially in response to the questions from the moderator/audience, and that's when lots of problems showed up. I've extracted everything they said about the ways of working, and those points are described and criticized below, for each panelist separately.
The first presenter, Felipe Engineer, explained (@10:53) how using Scrum increased the performance of their team from one or two projects a year to more than nine projects a year. If you're wondering what type of construction projects they have such that one team can finish more than nine of them per year, there's a simple explanation: He's only talking about a team that is responsible for estimating projects!
There are two possibilities:
Toward the end of the session (@41:25), in reply to a very fundamental question, "What are your increments?", He gave one example: having a proposal draft ready.
There's a difference between a deliverable and an increment. Things that are mentioned here are just deliverables, and not a very specific type of them that in Agile we call increments.
Agile increments need to be, as Scrum puts it, potentially releasable, or as the Agile Manifesto implies, working software (we can say "working product" in this context) and this is so because a working [sub-]product is what we can use to generate feedback, and then use that feedback to find the best way forward. A document is only an early stage of a journey that ends with a working [sub-]product. Something like a document is not an increment in an Agile project, unless the final [sub-]product itself is a document, which is not the case in construction projects.
This brings us back to the first topic: If you have a consultancy company responsible for preparing proposals and estimates, you shouldn't say that you run construction projects. It's like saying that you run pharma projects when what you actually do is develop software that is used in pharma projects. In that case, you're not doing pharma projects, you're doing IT development projects.
Overall, I don't know what Felipe does in his "construction" projects to make him believe that he's using Scrum, but what he says makes me believe that either it's not Scrum, or they're not construction projects.
The second presenter was Serge Beaumont. I spotted the following things in his talk (@19:21), related to his ways of work:
It's correct that all Agile methods pay a lot of attention to, and have effective methods of ensuring cross-functionality and communications, but these things are the result of using a certain method, and not the method itself. These concerns are also not limited to Agile projects.
Later on, during the Q&A (@43:22), Serge replied to one of the questions with "My project was in the design phase when...", and soon continued by explaining how they consider a document an output, and how they have iterations for their documents (who doesn't?!). Similarly to Felipe, we have a serious issue here: If you have a design phase, then you're not Agile. The most basic thing in Agile projects is that development processes (design, build, test, etc.) are run together and repeated. They are not run in separate phases. This is so, because we want to create subsets of the final product, in such a way that they are usable and capable of providing helpful feedback.
To summarize, while Serge was mentioning interesting points, some of them were just general management choices and not Agile ones, and some of them were not even compatible with Agile.
The third presenter, Fabian Schwartz, mainly talked about the results of "using Scrum" (@26:12). However, he mentioned three things about the way of working:
I've seen many people who think that as soon as you have fixed daily meetings, you're Agile. What everyone has to understand is that having daily meetings doesn't make anyone Agile; on the contrary, being Agile pushes you to have daily meetings, because of your need for this type of synchronization.
"Designing toward value" is an interesting concept that one can find a lot about in *value engineering*. This is not, however, an Agile concept. The Agile concept is not about designing for value, but running the whole development processes in a way that maximizes value (primarily by focusing on the most valuable items first). Fabian is effectively mistaking an old-fashioned concept in design, which seems like an Agile concept, with Agile's approach to value. Value engineering is, in fact, a predictive concept based on the upfront design of the whole product, which is incompatible with Agile.
Agile projects are all about exploring with a working product and using it to generate feedback. That's the feedback we use to decide about the future of the project. If the feedback for the intermediate products changes, our final product will change as well. However, what Fabian was happy about was that they can generate feedback using what he called highly sophisticated computer models. That's not the Agile style of feedback! When you spend a lot of time in the beginning of the project and design the product, and then create a model to simulate its behavior and check the output (what he called feedback), that's almost a textbook example of running a project with a predictive method.
In Fabian's case, some general elements of his project that seem like Agile elements are mistaken for being Agile, while many of the things that seem Agile to him are not even compatible with Agile.
The last presenters were William Power and David McCarthy. They are colleagues and presented together. These were things they said related to the ways of working (@33:24):
The first thing I find it important to say is that breaking down a schedule into smaller parts, keeping the upfront schedule high-level, and detailing each stage only before approaching that doesn't make you Agile. Being Agile is about the way you plan and run your project, and whether or not it's based on adaptation rather than prediction. By the way, the method mentioned in the presentation is the default way of planning in PRINCE2, following its "manage by stages" principle.
William mentioned that they try to look ahead proactively to respond to constraints, which is great. But he seems to have failed to see that this is more of a predictive approach than an adaptive one, which is: when you have all the plan-based risk management activities. Those complicated schedules are created to give one the ability to look ahead. Agile projects deal with very unpredictable markets and therefore can't trust their expectations of what may happen in the future (in order to respond to it). So, instead of that, they work in a way that allows them to adapt to those situations, should they happen, instead of predicting them and reacting to them.
Agile projects have a list of items they want to build, and then, from among them, at each point in time, they focus on the most valuable ones. Which are the most valuable ones? That depends on the feedback you've generated from your previous increments of the working product, as well as estimates and forecasts. IT development projects have a great opportunity: With some twists, they can form their features in such a way that they are more or less independent of each other —including the most interesting one, value—, and therefore, they can be built in any sequence. This is crucial, because you may never finish all the items; you may just stop when it's no longer justifiable, or you run out of time or money, and you know that you have the best possible output. BUT, can you do that in a construction project? NO. Work items in construction projects have a network of dependencies, and you can never go through them in any sequence that is not compatible with the dependencies (e.g., value). That's why we have to create those complicated schedules and represent them with Gantt charts: They are a simulation of the dependencies, which can show us, at any time, the possible ways forward that won't cause a serious problem in the long term.
On the other hand, we can always make adjustments to the scope of a construction project, but that's extremely limited compared to a piece of software. You can't simply say "Mmm, I think we've built enough; we don't need to have windows and doors in this building, so, let's just use this as the most valuable subset." This limits one of the biggest advantages of focusing on value (the way it's done in Agile projects).
In short, sequencing work items based on their value simply doesn't work in a construction project. The only thing they can refer to, is small subsets of work, isolated from the rest (e.g., designing one small part of the project).
Everything else that they said can be reduced to communications — and it's great that they pay so much attention to communication, which is a universal management concern. Unfortunately, though, that doesn't make them Agile.
To summarize, some of the descriptions in William and David's talk were the general managerial concerns which do not mean they are Agile, and the one important part of it that is truly Agile does not apply to construction projects and I can't imagine them using it in their projects — unless it's for very small subsets of work, which doesn't qualify them to say that they use it for the whole project.
One might think that the webinar was only a teaser, and not meant to explain how Scrum can be used in construction projects. Maybe so. However, the main issue is this:
Scrum cannot be used in construction projects
There are two main reasons:
Inspiration vs. implementation
Is homeopathy harmful?
They say that, in the worst case, it's just water, and therefore, it's harmless. But it's harmless because people who are struggling with serious illnesses and believe in its effectiveness will pay less or no attention to real medication, whereas some of them would have had the chance to survive using real medication and losing that chance entails real harm.
Real medication is not perfect, and it doesn't work all the time, but it works, at least sometimes. Homeopathy just doesn't work.
Projects are not always for the entertainment of the privileged. There are many projects for helping poor children, for finding cures for diseases, for creating a safe environment for people. Do you want to sacrifice the success and effectiveness of those projects for selfish reasons?