now browsing by tag


Change in an Agile Environment

Project Management and change go hand in hand from the planning phase onwards. Shifts in schedules leaving businesses unable to accommodate the changes, and constant uncertainty leaving change practitioners powerless to develop plans and keep stakeholders engaged. With organisational change management seemingly pushed to the margins. As project managers we cannot work in isolation, there must be an understanding on how projects affect change, so working with change managers is almost mandatory, and hence necessary to understand. Hence, Agile Change Management is a set of principles, not a one size fits all approach. The following are some lessons learnt and observations made that will help prepare to better manage change in an agile environment:

•    Change Impacts are still essential; it’s vital for informing people of the landscape, risks, dangers and opportunities. However, don’t be wedded to it. As soon as you start delivering you are going to need to iterate this. There is a gap between the strategy and what the people can do. Known as the ‘execution gap’. To stay relevant your ‘gap analysis’ will need to be done multiple times to ensure you’re all still on track.
•    Trust is key; Trust and transparency go hand in hand. Open doors to stakeholders and instead of concentrating on, training, coms or stakeholder plans, engage them. Give them regular feedback and updates, giving them visibility of the process. Being transparent will ensure that communication lines are kept open which will ensure that mistakes, progress and failures are all identified and shared.
•    ‘Think like a Military Commander’;
you are a pair of eyes focussed on identifying potential risks, threats and danger. You must communicate these to your troops to let them know what could happen, guiding them onto contingent courses. It’s not ‘reworking’ it’s readjusting to where we are now. As a leader you are constantly asking ‘Is this relevant anymore?’ ensuring not to move too quickly because then there is room for error. In this agile landscape this journey isn’t yours it’s everyone’s.
•    Fail fast; ever heard of the age-old phrase; ‘Try to fail, don’t fail to try?’ Well, this is highly applicable in an agile landscape. It’s ok to fail if you are doing something about it. You need to be constantly reassessing and asking ‘what am I doing wrong?’ and ‘what is no longer relevant?’ If you identify risks then confront them early so that you might ‘fail fast’ you will alter the change road map and lead to a smoother engagement, adoption and embedment.
Whether you are currently delivering change on an Agile project, or in a more conventional Waterfall delivery, embracing these 4 Agile change principles can assist you to becoming more customer focused, adaptable, effective and integrated.

A Brief Introduction to Agile

The following is a brief introduction to agile, looking at agile implementation methodologies, philosophies and agile adoption.

An honest dive into the world of project management shows that for many years, the leading techniques were Sequential Development Methodologies (SDM) such as waterfall. Historically, waterfall and other SDM methods proved to be of unparalleled value for project managers and were considered infallible. The assumption behind choosing a method relied on the idea that scalable services and products should be supported and controlled through structured procedures and techniques. A vastly acclaimed assumption, this idea is perfectly true, which led to sustained success for a long time.

And yet sequential methods are said to be rigid and leave little room for flexibility. At the same time, it can be argued that they leave little room for beginners’ failures. Yet the rigidity argument paved the way to a dynamic control process for software development. The new tool provided the desired flexibility and welcomed change. 

The hallmarks of flexible predictive life cycle methods are that they are adaptive and iterative. The iterative approach encourages project teams to repeat certain steps as their understanding of the project increases. Consequentially, the deliverables should be better than in linear methods. The edge offered by the Agile approach is, as the name suggests, increased control for managing scope uncertainty. The method makes for agile teams capable of handling unpredictability and risk by creating iterations and sustaining incremental work steps.

1. Agile Implementation Methodologies

Agile encourages iteration, documentation, collaboration, and adaptation. We find these core values at the heart of the Agile Manifesto. In fact, the Manifesto does not propose how to implement the methodology but is centred on these four values and 12 principles. Out of these, a few principles exist, such as using a finely sliced work breakdown structure, sustainability, seeking to deliver value, and self-management of fully autonomous teams.

However, the high adoption rate of Agile provides plenty of concrete examples of implementations, namely:

1. Scrum 
2. Extreme Programming (XP)
3. Feature Driven Development (FDD)
4. Dynamic Systems Development Method (DSDM)
5. Crystal Clear
6. Kanban, etc.

2. Agile Philosophy

The first and foremost purpose of Agile is to create agile teams capable of simultaneously developing, designing, and gathering project requirements. The development processes are dominated by agility, hence the name of the method. In fact, anyone can derive the benefits and features of the method on their own if they work off of the assumption that the solution should maximize value and adaptability. By Occam’s Razor, choosing the minimum number of core values and leading principles that are absolutely necessary for business should lead to a situation very similar to the Agile method. Although it has become a cliché, the (in) famous analysis paralysis is indeed a peril finely avoided by Agile. 

More than that, the methodology enables teams to create the right deliverables by ongoing re-planning and reworking small portions. The equilibrium thus achieved between focus and time management aims to put products on the market on time. This is mainly because the problems hindering product launch are managed on the fly, while other portions of the project are handled in a timely manner. Avoiding stereotypes, the Agile Manifesto provides the flexibility necessary to allow teams to use common sense and a continuous search for excellence. At the same time, it deals with real-life problems encountered during projects.

Quickly, here are some of the principles of the Agile philosophy:

Iteration and incremental steps

Incremental steps are taken on the way to creating a deliverable. Each iteration draws closer to the desired results.


Agile achieves sustainability by its responsiveness to changes and adaptability. A caveat, for example, is that financial sustainability needs to be addressed individually for each project. This type of sustainability is not covered by Agile, as the method instead aims for effort sustainability. 

Collaboration and adaptability

Well-defined phases and low interactivity between people and teams place SDM low on the collaboration scale. On the contrary, Agile promotes communication and going back a step when necessary, which is no longer a concern since the steps should be small—recall the work breakdown structure. 

Responsiveness to change

Change has multiple roots, some of them belonging to the final customer and some originating in the project team. Agile provides the framework to address such changes made on the go. 

No hierarchical structures

With well-defined roles and responsibilities within the team, Agile empowers all contributors to act like owners. Everyone has a voice, and everyone is personally accountable for the success of the project.

Continuous improvement

Projects are different, and every single one of them is a journey. Having to continuously learn and adapt, all team members should strive for excellence by re-evaluating and improving the process. It makes sense because the process of Agile implementation is itself subject to iterations and improvement. 

3. Agile Adoption

A concept rather than a process, Agile has to be tailored for implementation in each individual setting. Like any other implementation brought from the exterior of a company, the method needs to be adopted in a suitable way. Although IT projects are typically associated with coding, the scope and applicability of Agile are wider, and they encompass a significant portion of the industry. 

Because it requires a learning period and ramping up to the new challenges of the Agile environment, a company-wide implementation after a switch from SDM can be difficult and sometimes a complete failure with disastrous consequences. Organizational architects are well aware of the resistance to change manifested by most employees. For this reason, implementation should be carefully planned and rolled out in stages, starting with a small pilot team.  

Due to its heuristic nature, Agile takes time to master. Before planning such a move, organizations must ensure that they have the capability and maturity level required. A few questions need to be asked before embarking on a large-scale transition: 

1. Cultural fit

Can the organizational culture support agility?

2. Capability and maturity

Agile is not a cure for all problems but a lengthy journey to perfection that is troubled by many traps waiting for a wrong step from the inexperienced traveller. Are the team members experienced enough to become agile? 

3. Globalization and remote working

Already difficult as an environment for many people, globalization and remote working hinder communication, which is critical for Agile. 

These are merely a few questions out of the many more that need to be asked during the preparation phase for an Agile company-wide rollout. 

An evolutionary step toward counteracting slow and ample methods such as the waterfall, Agile is a response to criticism raised by those arguing that heavy governance and regulation cause delays. Moreover, strict governance leads to inside-the- box ways of thinking and does not promote creativity and employee empowerment. Lightweight methods championed by such critics became known as Agile, an umbrella term describing various approaches. This method gained popularity and spread throughout the entire field of IT. The reason behind this increasing popularity was the claim to remove division inside projects and erase the barrier between the technical side and the business side, as they came to be known from previous methods. Instead, collaboration focused teams’ aim to deliver business value.

Collaboration, communication, and engagement between individuals and between teams are the foundation of Agile. However, this is a generic framework rather than an implementation-ready set of steps. Adapting and implementing Agile is not easy but rather quite the opposite. It requires careful consideration and planning to ensure that the company has the necessary capabilities and maturity. Moreover, resistance to change can occur inside organizations that insufficiently promote the benefits of the method to their coders and project managers. This happens many times because the Agile Manifesto defines principles but leaves the benefits only stated implicitly.