The software industry has been massively improved by adopting “Agile” design and delivery processes, where “Agile” essentially describes breaking large tasks into smaller tasks and being organised and flexible in how they are delivered to produce a final product.
Interestingly it would seem the building industry is a long way behind here, with very few architecture or engineering firms seemingly applying an agile philosophy to their work.
How about you? Have you tried using Agile in the design of buildings or products? When using SketchUp or as a way to organise the evolution of your model? If so would love to hear more about it!
I happen to know that SketchUp developers use an Agile approach. I think I like the idea of it in principle, but I also like having no design approach at all! I mean, do things because it’s the right thing to do, and not because it matches your company’s preferred design pattern.
Do a Google search for “agile is dead”. There seems to be variations that people are preferring.
I’ve taken a look. I think what you are promoting is a species of intra office project management. I cannot comment usefully on that as it is difficult to see it applying to sole traders like myself. I can see its application in large organisations.
Agile can be applied to almost any aspect of your life, as a single person or as a team. It is true that the article is more focussed on the team aspect but it’s a great way to organise yourself.
What is key is the idea of breaking the things you have to do into meaningful, measurable tasks and prioritising them. Ideally you are only doing one at a time and you finish it before you start the next one. In the NHS they have an expression that I think captures it really well: “only pick up a piece of paper once”.
Agile is only possible when adopting BIM in a proper way, because, simply put, then your product is built several times (virtually) until it passes QA.
A bit more context as a few people have asked “what does this have to do with SketchUp???”
Building a SketchUp model can be organic or organised. I’m particularly interested in how professionals go about organising themselves when building a SU model and also I’m interested in how people manage more than one person being involved with a SU model. These are core issues for SketchUp Pro.
Agile is a process/workflow that can be applied (or not as is the case most generally) to organising a 3D model’s evolution. I think it has a lot of potential to improve model organisation for people and architecture firms.
I know some of our user base are applying it to their design workflows. I suspect that the number of people doing this is very small but don’t really know - hence the forum post.
What does this have to do with SketchUp itself more specifically? Well, a richer understanding of how people are trying to do this with SketchUp will help inform product decisions about SketchUp. There is a ton of stuff we could do in the long term relating to agile if people wanted to us to make SketchUp more agile-friendly. If we knew people were doing this we would then seek to understand this better to see if it opens opportunities to improve what we do.
Thnx for the blogpost!
As with most things, ‘Agile’ could be one of those marketing things:
Nothing new, just a rephrase…
Thoughts:
While the aec industry might be conservative, it is mainly because apparently, it works for them doing things the way it used to be.
Disruptive workflows could change that if they see the benefits.
One of them being able to collaborate in an easy way.
In the Netherlands, people needed to collaborate in mega infrastructures, for it made no sense when one landowner decided not to participate in building or maintaining his part of the dike, or we all would be lost.
(Off course, there would be some questions about the ‘willingness part’)
I favor the Trimble approach, btw, instead of forcing everyone to use one (AD) package.
With construction, there are many benefits (prefab, elements, employability, replaceability) but chances are that the big picture is lost while manufacturing parts or placing doors.
For instance, we have a contractor that builds stable’s.
He will set the outline in SketchUp and send it to the steelcontractor that works with Tekla.
He receives a ifc model of the structure in order to make the panels that he uses to measure and draw the panels that need to fit in the placed steel structure ( they will have to be a bit smaller to place them)
He will send the panel sizes to another manufacturer.
Now, the exchange with ifc formats with SketchUp is cumbersome, because instead of the SketchUp approach, all beams that are essentially the same definition, will import as unique component definitions instead of instances of the same, which results in unmanagable bloated SketchUp files.
He will only need to draw some rectangles, which is perfect for SketchUp.
There are many more examples like these:
Window manufacturer’s that only needs to know what size.
Painters that only need the square footage.
Wall framers etc.
If done wrong, Agile (and SCRUM) can be very counterproductive and have killed companies, just as much as it has helped companies to success.
Agile is a model that describes how to manage a process in a changing environment (customer always sending requests for changes, other e.g. legal conditions change). I think it doesn’t matter whether you make software or plan a building or design a product. It can be applied as long as you can actually respond to changes. It makes you respond earlier to changes rather than later (which would be in both fields more expensive).
But there is one physical difference: Once the basement is cast in concrete, it’s there, and it must be there before the upper levels. The building process inheritently is more waterfall-like towards the end.
No, but in a software company that didn’t use it properly and in another one where it is a success.
One common mistake typical to the SCRUM variant of Agile is to restrict yourself to consider only requirements that are relevant for the next iteration (and YAGNI for anything else), which leads to shortsightedness and an unmaintainable product even before it is finished.
Kanban is a more flexible framework. One should always question how well does work for me, or should I customize it. A strength of Kanban is that you can keep minimal planning/management overhead (unless more detailed planning needed), but keep focus on a single task that you are “doing” now.
It actually came out from an industry usually considered very conservative: Toyota Motor Corporation!
