Trello for construction should be a good fit

Many of my peer colleagues are IT and start-up professionals designing and building software. Their collaboration needs are very high, and require a strong team leader, and game participants. Nowadays, they implement a recent management practice known as Agile software development that challenge the traditional sequential approach that simply no longer lends itself to the cutting-edge techniques of 21st century models. Scrum is such an Agile development tool that uses close co-location or online communication as its center of activity. Trello for construction seemed to me a natural.

The Agile framework was intended for software product design and development; however, when I read (see below) that …

It works well for any complex, innovative scope of work. The possibilities are endless …

I wondered if it couldn’t have applications in organizing complex construction schedules. As I am unaware of any extant study, I thought I’d conduct my own.

Trello for Construction: The Scrum Process

Scrum is facilitated by a Scrum Master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. The Scrum Master is not a traditional team lead or project manager, but acts as a buffer between the team and any distracting influences.

One principle of Scrum is that the owner may change his mind, and alter objectives– “the requirements churn,” and that although the team may not be able to respond to undeveloped ideas, they establish a strategy to respond to emerging requirements. Changes in construction programs are unavoidable, but it is difficult for teams to develop strategies to respond to undeveloped ideas, other than notices of delay or contingencies.

Scrum is an Agile framework for completing complex projects. “It is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change. Scrum originally was formalized for software development projects, but it works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.”

– Read moreabout Scrum, here 

Scrum Framework

• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
•  The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
• Along the way, the Scrum Master keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
•  The sprint ends with a sprint review and retrospective.
•  As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

For a recent scheduling project, I decided to apply an Agile framework approach and pitch a Trello for construction scenario to the project team.

“Trello uses the Kanban paradigm for managing projects, originally popularized by Toyota in the 1980s for supply chain management. Projects are represented by boards, which contain lists (corresponding to task lists). Lists contain cards (corresponding to tasks). Cards are supposed to progress from one list to the next (via drag-and-drop), for instance mirroring the flow of a feature from idea to implementation. Users can be assigned to cards. Users and boards can be grouped into organizations.”

My Trello Board (partial)

Several scrum add-ons are available for Trello, to enhance that working environment. One such is #Slack, an online team communication tool.

In theory, with a strong Scrum Master, the framework would appear to be a potentially useful schedule developmental tool for the construction industry. I believe that its closest relation would be BIM. However, BIM is chiefly useful as a collaborative design system on overdesigned megaprojects, and players with deep pockets. Despite ubiquitous hype, it has not made more than a negligible impact on the building industry in the US. I have written on this topic in other posts.

On the face of it, Agile development would seem to lend itself well to construction scheduling because the framework is similar: the chief scheduler works with subcontractors to develop their timelines, which are then integrated into a master schedule. With this model in mind, I pitched one of my clients to induce subcontractors to join my Trello board, above, that represented the entire effort.

Herewith, the Scrum framework repeated from above, followed by my field observations.

Trello for construction CPM Schedule generation

• A product owner creates a prioritized wish list called a product backlog.

The owner was invited to join Trello, but adapting to the Trello platform was a bit of a learning curve; their backlog came in as an afterthought.

• During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.

My Trello for construction project required close interfacing with all the subs. With the understanding there would be some arm-twisting to get them involved, I created lists with cards for each trade, and developed templates for them to fill in and then post back to the site, thus making it easy for them. And lo and behold, they worked through several iterations in order to generate their sub-schedules that get folded into the master, which became the approved baseline.

• The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).

The master schedule sprints were aggregated over ten and twenty-day cycles. We had weekly meetings, as well as follow-up meetings to facilitate the Trello process.

• Along the way, the Scrum Master keeps the team focused on its goal.

The Backlog

A lot of prodding was needed to keep folks on task. Where response was weak, I called in the big-guns (the GC) for inducement. Unlike the traditional Scrum Master who is part facilitator, I had to do way too much leg-work picking up the slack.

• At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.

For our team, this is the equivalent of an approved baseline schedule for each trade, leading up to an approved master schedule. For our trial-run we were successful in making the deadline.

• The sprint ends with a sprint review and retrospective.

The end of each sprint (sub schedule) was memorialized by a pre-approval process, and the integration of the sub-schedule into the master schedule. After each iteration, I would go back and see where I needed compression, and then notify the subs of the condition. I would then resequence back until I had a balanced schedule, with the subs on-board.

On a good day, we would have discussed how we could have improved the process after each activity, which is close to a traditional sprint retrospective.

• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

Our collective effort, represented in the timeline above, reflects the hierarchy of tasks, which does not bear out this tenet.

Once the baseline was approved, it was time to take stock of the trial:

1. Although many of the trade reps were only moderately tech-savvy, I was able to encourage them to participate in the Trello for construction Scrum, although my expectations were low and hand-holding was prevalent.
2. It was difficult to demonstrate the Trello for construction advantage to the owners, and they ignored invitations to join. This was to be expected, as they seemed to be distracted with other business. Of course, a scheduler typically has little or no access or influence as regards the owner’s interests.
3. Once the Trello team was established and producing, I invited all team-members to join my #Slack (online communication) team, for the next closer step to collaborating; however, it appears this was too ambitious, as no one could see what they had to gain by joining.
4. Despite the shortcomings of my resources, I was able to effectively build the baseline schedule with the ‘online’ collaboration of the team-members. In my mind, this was a victory that substantiated the Trello for constructioneffort.
5. I had hoped that the project Trello board would catch on, and the owner might even like to see it incorporated into the build-out. This last, was pie-in-the-sky, to be sure.

The construction industry is famously conservative, especially when it comes to technology. Typically, technology is not a contractor’s top priority investment. They are reluctant to utilize or learn new technologies, and this seems to be to their detriment. On the other hand, the offerings of project-software designed specifically for the building industry never really seems to have gained a foothold. Trello for constructionand Agile framework has direct benefits that the industry needs to wake up to.

However; I believe in my role as Scrum Master, I was able to manage to work through many of the above expected obstacles, because I anticipated them, and developed workaround strategies. Despite that, I realized that we could not substantially avail ourselves of the Scrum framework because the  building of a construction schedule is nearly always a sequential effort, that lacks the flexibility of Scrum, and because schedulers are not used to close collaboration. The fragmentation of Scrum framework must seem unnatural to construction professionals indeed, yet someday, this may change. Right now, Trello for construction is merely a wish.