Building the Argument for Agile implementation: Lego Edition

About a month ago, I was part of a team that did an ERP implementation project simulation using Legos. The goal of the project was to show the benefits of using agile methodology over the competing theory of waterfall. While the benefits and costs of each can often be lost in firm biases and complex projects, things get a lot simpler when you break things down to Legos.

The task was to build a Lego city based on the requirements of our “client.” We were to conduct a business analysis phase, followed by three “sprints” (based off of Scrum) to build the city. Besides bringing out my inner child, I also found three key moments in which I discovered the benefits of using the agile methodology and how it is applicable to a real ERP implementation project. I broke down each scenario with what the waterfall approach would have our team do, what we did through the agile approach, and the key takeaways from each.

Being transparent, even when the truth isn’t always nice to hear

Scenario: During our business analysis phase, our client listed a large array of requirements: Three parks, two hospitals, a school, a bridge over the river to connect the city, a mall and so on. It was also given that our client requested the entire city to be built in 45 minutes. While we wanted to add optimal value for our client, in the back of our minds, we knew all of these requirements would be nearly impossible to fulfill given the time limit.

Waterfall: It was a guessing game. We would have to somehow estimate the length of time each requirement would take (perhaps based on prior experience) and formulate a building plan for all of the requirements. If we were realistic with ourselves, we would probably have to inform the client that it would take longer than the given time frame. If we were over-optimistic, we could tell the client all the requirements could be fulfilled with the risk of that not being the case at the end.

Agile: We started off by informing the client that fulfilling all of the requirements under the time frame would be challenging, but we would have a more accurate prediction after our first sprint. As expected, we were extremely under the production velocity needed to fulfill all of the requirements. We showed the client what had been accomplished and then used the sprint as a reference to forecast what could be achieved with the remaining time. We gave the client options as to what requirements were absolutely needed and what could potentially be added on in a future project. With the prioritized and cut requirements, we finished the following sprints with a new sense of scope.

Takeaways: Clearly defined project scope, transparency throughout the process

Answering the Question of “What’s actually being done?”

Scenario: This question can be a tough one to answer. ERP implementations involve many behind the scenes steps that are crucial to the success of the project, but are often unseen by the client. The scenario came up at the beginning of our project following our first sprint execution. It was obvious our client wanted to see our reaction to the question. After explaining our rationale for the sprint and what we wanted to achieve, she quickly asked, “Okay, so what do you have to show for it?”

Waterfall: In the waterfall approach, actual execution is one of the later steps in the process. Feasibility, planning, and designing for all of the requirements often occur before any building is accomplished. After reviewing with the client the entire plan and design of the project, the answer to this question could either be an indirect answer of, “We have a lot of things behind the scenes going on, and we expect to be able to show you shortly,” or a more truthful, “We’ve got nothing.”

Agile: Since we had a specific goal for this sprint time period, we were able to show in detail what was accomplished. We were able to ask for feedback and confirmation that we could continue to the next task at hand.

Takeaways: Results orientated, quicker response to feedback as opposed to showing progress later in the project timeline, peace of mind for the client

Handling the Unexpected change of client Requirements

Scenario: In our second sprint, our objective was to build one of the parks along with a surrounding neighborhood. When we reviewed the completed work following the sprint with our client, she stated, “You know, I really want the park to be bigger now. Also, why are all of roofs on the houses black?” (Valid point.)

Waterfall: Best case scenario, we are informed of the changed requirements early and spend time recalculating our pre-determined forecast and planning. Worst case scenario, the client doesn’t see the end result until it’s too late, making for a less than pleasant reaction on the final delivery.

Agile: Since agile is designed to prepare for and handle changing requirements, this didn’t have too much of an impact on our overall project. We simply edited her requirements and added the changes as objectives in the next sprint. We changed the ugly roof color and added more green to the park. Other than a little extra work in the last sprint, our timeline and finish date didn’t change.

Takeaways: Early results equals early feedback, more flexibility to change, more client engagement

By the end of the completed project, I learned not only that my Lego building skills had dwindled since my childhood days, but I also learned the true value of using the agile methodology when implementing an ERP system. In a real world implementation, things get complicated. Requirements change, schedules fluctuate, but clients still want results. The agile methodology is the best way to prepare and adapt to change, promote transparency with your client, and be the most efficient with the time you have.

Read more about how ArcherPoint uses agile as part of our implementation methodology to help projects run smoothly.