The article “The New New Product Development Game” published in the Harvard Business Review by Hirotaka Takeuchi and Ikujiro Nonaka in 1986 was foundational to the development of agile-type methods of project management. In the article, they compared project management to rugby, a sport where everybody has to contribute. Collaboration while playing rugby is especially important in the scrum, where players on both teams huddle closely with their heads down and compete for possession of the ball. If teams do not collaborate their movements and dynamically alter strategy in this pivotal phase of the game, their weakest point will be breached, and they will not gain control of the ball.

Just like in the scrum during rugby, IT project teams need to continuously reflect on situations and adjust accordingly as a group. This type of adjustment leads to more evolved efforts that better meet client needs.

As I discussed in my previous post, T2 Tech’s approach involves completing small iterative sessions. When you use an agile methodology and incorporate iterative sessions into your project, you gain the opportunity to review and reflect between iterations and re-asses the project scope and objectives before the next iteration begins. Using an iterative approach, we don’t have to take change requests as a sign of project failure. We can, instead, see an opportunity to collaborate as a team and implement improvements or adjust accordingly, regarding both process and scope modifications.

Iterative reflection improves your overall result

Normally people hate scope changes, but these changes are inevitable. An agile-based method gives you the tools to manage change and prepare for the unavoidable. Now, we’re just doing it at the right place at the right time. When incorporating lessons learned or project changes from reflection and review, you can discover improvement opportunities or adjust to shifting requirements in the overall project.

An agile stakeholder review and reflection process allows teams to adjust to scope change. This means the end goals and physical work needed may be altered between iterations. As an example, you may have started with the goal of building a new server but then discover you no longer need a server, or you may discover the need for more security measures that will change your infrastructure design. Changes to scope equate to changes in the overall project, and the end-product savings that result from regular and consistent review and reflection between iterations can be significant, in both capital and operational expenses.

Change is inevitable, it may result from emerging business needs or insufficient resources. Balancing between over planning and under planning is difficult, but using an agile-based approach that allows for review and reflection will allow you to adapt to situations that will inevitably arise. Prepare for the unexpected. Review and reflect between agile iterations to accommodate scope and process changes.

Quick tip: Just like a rugby team collaborates and dynamically improves to gain ball control in the scrum, review and reflection between iterations in an agile-based approach allows you to implement changes before completion. These changes may be adjustments to your process or team interactions, or they may be more dramatic changes to your overall scope. Implementing changes between iterations will fortify your team, address inevitable change and result in better solutions for the particular needs of a situation or client.

What’s up next: Reflection allows for agile adaptability, but planning projects out is also important. In my next post, I will discuss how a hybrid methodology, composed of both waterfall and agile elements, is ideal for implementing IT projects.