Agile Project Management – Introduction to Agile – Agile BIM 8/10

In previous posts of the Agile BIM series, we presented the reasons for low productivity in the construction industry and British ideas for overcoming it. One of the many proposed solutions is the implementation of Building Information Modeling (BIM) methodology, which mainly involves improving communication, collecting, exchanging, and accessing information. In this post, we will introduce Agile BIM, and in the following ones, we will translate Agile principles into the language of BIM.

1. Why BIM? Origins of New Solutions – Agile BIM Part 1/10
2. British Approach to BIM – Standards and Protocols – Agile BIM Part 2/10
3. CDE in British Standards – Agile BIM Part 3/10
4. Why is CDE so important in BIM? – Agile BIM Part 4/10
5. Przykłady platform wymiany danych CDE – zwinny BIM cz. 5/10
6. What is BIM? – Agile BIM Part 6/10
7. BIM vs. Traditionally Managed Construction Projects – Agile BIM 7/10
8. Agile Project Management – Introduction to Agile – Agile BIM 8/10
9. Translating Agile Principles into BIM – Agile BIM Part 9/10
10. How to Make BIM Agile? – Agile BIM 10/10

History of Agile: From Manufacturing to IT – Introduction to Agile BIM

When discussing the development and application of Agile, it is most often associated with IT companies, with its beginning marked by the publication of the “Agile Manifesto” in 2001. In reality, the origins and inspirations should be sought much earlier in the manufacturing industry. In the 1993 article “The New Product Development Game,” several products that were considered groundbreaking by manufacturers, bringing modern functionalities and achieving market success were analyzed: Fuji-Xerox FX-3500 copier from 1978, Canon PC-10 copier from 1982, Honda City car with a 1200cc engine from 1981, NEC PC 8000 personal computer from 1979, Canon AE-1 SLR camera from 1976, Canon Auto Boy compact camera from 1979. Based on research, six characteristic, common elements of the new product development process were identified, which separately had no significance but together constituted a recipe for success.

Work schedule, source: www.businesswire.com

Key Elements of Agile in the Product Development Process – Introduction to Agile

They were identified as:

1. Built-in instability: The team is given an ambitious goal and freedom in project execution. This allows breaking away from patterns and established paths to propose ambitious solutions.
2. Self-organizing teams: Management’s role is limited to guidance, financing, and support. Self-organizing teams soon start operating similarly to startups. They create their own innovative ideas, take risks, and learn from mistakes. For example, Honda relied on a team with an average age of 27 years because the goal was to design a car for young people. The team could break away from accepted standards and patterns to propose a completely new quality. Such teams must consist of representatives from various specializations to bring ideas from different perspectives.
3. Overlapping phases of the production process: It was noticed that a side effect of teams composed of members with different specialties was the overlap of stages in the product creation process. Specializations and roles became blurred, and the entire team felt jointly responsible for the task. The team reduced the number of errors and problems when transitioning from one stage to another.
4. Multifaceted learning: To react quickly to changing conditions, teams should constantly use external information sources and quickly locate and limit the number of working solutions through trial and error methods.
5. Subtle control: Excessive external control kills spontaneity and creativity. A better solution is a combination of team self-control with peer pressure stemming from striving for a common goal.
6. Knowledge transfer within the organization: There is a need to transfer good solutions and ideas within the organization. One idea involved moving several employees with above-average skills between projects.

Additionally, there was a need to unlearn certain things because sometimes knowledge and beliefs can limit development. As the saying goes, “he did it because he didn’t know it couldn’t be done.”

Application of Agile in IT: A New Approach to Project Management

These observations and conclusions provide a good foundation for understanding Agile principles and their potential implementation with BIM.

Agile mechanisms, in their current form, emerged in response to issues in executing IT projects. Software was delivered too late and with many errors, despite significant team effort and working under pressure.

Conclusions for the Future: How Agile and BIM Can Collaborate

What can be concluded from this?

If employees have the appropriate knowledge, work hard, and are engaged, but projects do not achieve the required quality and timeliness, the problem lies in the organization of work and processes.

Similar observations were made much earlier by Edwards Deming, who is considered the creator of Japan’s post-WWII economic success. He believed that 94% of all work errors are due to processes and systems that depend on management, while only 6% are the employee’s fault. Deming was a staunch opponent of control and management by objectives and results. He believed that decisions regarding processes and quality should be made together with employees as they do the work and know the process best.

source: www.asana.com

The Agile Manifesto – Introduction to Agile BIM

I will start the part on agile management methods by discussing the “Agile Manifesto” published in 2001. It is important to note that the items on the right side of the table are also significant, but greater value is assigned to those on the left.

Basic Principles of Agile – Introduction to Agile BIM

The Agile Manifesto is closely tied to 12 principles. They describe an introduction to Agile. I will describe them where necessary, in a form not directly related to the IT industry. The following points are direct quotes from the original Agile principles created for the IT industry. Using these terms should not be read without this context. For example, architecture in point 11 means software architecture, not architecture as building design) [2] [3]:

1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

The goal of the work is not to satisfy the project office, the general contractor, or meet all quality requirements, but to deliver a product that meets the real expectations of the client. This does not mean unreflectively agreeing to everything the client wants, as this will lead to quality deterioration in the long run. It is important to note the conjunction “through,” emphasizing that customer satisfaction is a consequence of delivering a valuable, client-satisfying project/product, and this should be the focus.

Returning to the example of a home renovation from the previous post in the “Agile BIM” series (7/10), assume that the actual goal is the client’s satisfaction, not just meeting the established parameters and quality. To achieve this, the general contractor (husband) divides the work into smaller pieces, e.g., two-day tasks, at the end of which the client (wife) is presented with what has been done. If it turns out that the client’s (wife’s) concept was understood differently, this is a good moment to make changes. If this example relates to our own experiences, as those doing home renovations, it turns out that intuitively without assigning the name “Agile,” we proceed in an agile way.

2. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

We assume that the list of things to do is fluid and new requirements can be added, existing ones modified, unnecessary ones removed. This does not require change management processes (e.g., contract renegotiation). We will always deal with the highest priority requirements. Being ready for changes does not mean working in chaos or immediately reacting to changes by putting out fires. This principle means focusing on readiness and implementing changes even late in product development through proper management techniques. It means not being surprised by changes and agilely adapting to them.

3. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.”

This point primarily concerns obtaining valuable feedback, so it does not mean delivering anything to give the impression of quick progress. Only those parts of the product/project that meet the set completion criteria should be delivered to adjust future actions based on feedback.

Waterfall vs. Agile source:: www.techguide.com.au

4. “Business people and developers must work together daily throughout the project.”

Agile methods work through a short feedback loop. Information is frequent, so usually, we don’t have time for overly formal rules and communication other than direct. The main cause of misunderstandings during project work is the communication gap between project participants, including between business, designers of various branches, the general contractor, and the client. One way to bring these two worlds closer is to combine them daily. In Agile, collaboration means efficient communication, negotiation, and compromises where necessary. However, it should not be understood as blurring responsibilities and shifting tasks between team members. Each role must have a clearly defined set of tasks and responsibilities it is accountable for.

5. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

The main factors blocking project agility are control and lack of trust from management. In Agile teams, we encounter what is known as “micromanagement.” The role of management is limited to supporting the team, providing all the necessary elements for completing the work, and removing obstacles. A good analogy for the role of management is that of a gardener. They do not have direct influence over how quickly the plant grows, how much fruit it produces, or the size and quality of the fruit; they can create the environment, fertilize, water, and remove weeds to support the uninterrupted growth of the plants.

However, providing the right environment should not take the form of “mothering.” This involves removing every possible obstacle, preventing mistakes, and shielding the team from negative feedback, out of fear that it will lead to a lack of independence and failure to learn from mistakes. Instead, it should focus on fostering autonomy, self-organization, and learning from mistakes. For management, letting go of the desire to control everything and find blame for mistakes is an incredibly difficult process. It’s important to understand that making mistakes is part of human nature; since we can’t avoid them, we should use them to gain a competitive advantage.

6. “The most effective and efficient method of conveying information to and within a team is direct conversation.”

Simply put, communication is the process of conveying information from the sender to the receiver. It is effective if the receiver confirms that they have received and understood the message. There are three types of communication methods: body language, tone of voice, and words. All three elements are present during direct conversation or video conferencing. During a phone call, body language disappears, and in written communication, the tone of voice is also absent. Additionally, commonly used email communication is one-way communication—immediate feedback is not received, and responses can often be delayed. Where possible, direct conversations or video conferences should be used, while ensuring that they do not turn into lengthy and tedious meetings.

7. “Working software is the primary measure of progress.”

A common practice in traditionally managed construction projects is defining measurable indicators of project progress, creating various reports, spreadsheets, and presentations that give a false sense of control over the project’s progress. This often leads teams to focus on meeting the required indicators rather than the underlying goals. Working according to Agile, it’s not important how many indicators the team has achieved, but what the result of their work is. For example, it’s not valuable in itself how many errors and collisions were detected in the 3D model. What matters is whether the model is completed within the intended scope and free of them. It’s worth noting the word “primary” in this rule. There are many measures that can be used and it is worth using them, but they should not be the goal in themselves.

8. “Agile processes promote sustainable development, and everyone should be able to maintain a constant pace of work.”

Practice shows that team members working overtime make more mistakes due to exhaustion. Lack of time for rest and stress relief negatively affects the work atmosphere and team creativity. Collaborative work provides opportunities for development and satisfaction, but maintaining balance is essential.

9. “Continuous attention to technical excellence and good design enhances agility.”

A project rushed and not thoughtfully planned will generate many problems in later stages. Initially, there is a temptation to cut corners to show quick progress. As the project advances, all the gaps and superficially patched issues cause problems to accumulate. Focusing on technical excellence does not mean striving for perfection. It means preparing the project/product so that it allows for easy and quick changes in the future.

10. “Simplicity—the art of maximizing the amount of work not done—is essential.”

This means that a designer has achieved an optimal solution when there is no need to add anything new, yet nothing can be removed.

11. “The best architectures, requirements, and designs emerge from self-organizing teams.”

This point is primarily about unleashing the creativity of teams and responding quickly to emerging problems, opportunities, and threats. In traditional hierarchical management models, decisions are made at higher levels in the hierarchy, often passing through the entire chain of approvals. This means decisions are not made by the person who best understands the problem (opportunity) and has the greatest knowledge of how to handle it (utilize), but by someone who has received incomplete, filtered information through various hierarchical levels. Additionally, this leads to the problem of extending the time needed to make decisions. This may result in decisions that are outdated by the time they are made.

A properly motivated team can effectively distribute tasks within itself and creatively approach solving problems or seizing opportunities. Of course, self-organization does not mean allowing anarchy. It means a team with excellent internal discipline. The leader’s role is to nurture the right work environment and refrain from imposing their solutions and excessive control.

12. “At regular intervals, the team reflects on how to become more effective, then adjusts its behavior accordingly.”

A similar principle of drawing lessons for the future appears in many project management approaches. For a completed project, such lessons are already useless. Of course, they can and should be used in future projects. However, who exactly remembers at the end of a project what happened, for example, a year earlier? A much better practice is to draw lessons more frequently during the course of the project. When we are dealing with a task, we do not see the entire context and all related details.

That’s why it’s worthwhile to periodically review the project and opportunities for improving efficiency. It’s crucial that seeking improvement opportunities is not confused with finding fault and pointing fingers. This will cause teams to go silent, trying to survive without “digging” others into trouble. Continuous reflection is one of the most important elements of agility. Honest discussion is a crucial starting point for self-improvement, while silence means losing that opportunity.