Embracing change is always discussed as a positive attribute. However, it's easier said than done. In my experience people tend to resist change. This is amplified when discussing changing technology or existing technology stacks since it will impact many people or groups of people and not simply 1 person. I don't fault people for being hesitant to change. Change takes time and effort which always cost money. Change is even resisted if it's an improvement over an ailing legacy system.
Replacing your website sounds like a good idea until you consider: migration time and testing, development effort to build or rebuild functionality, money for servers, software or licenses, effort to document new systems and the time to retrain staff. Every change has an opportunity cost. One place where it's worth the investment of time and effort is moving from traditional 'waterfall' management practices to agile management methodologies.
Change is the law of life and those who look only to the past or present are certain to miss the future.
– John F. Kennedy
Agile vs Waterfall
Before we get into why agile is an improvement over waterfall management practices let's first briefly describe each.
Wikipedia article on waterfall states
Waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks ... It tends to be among the less iterative and flexible approaches, as progress flows in largely one direction ("downwards" like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance
Wikipedia post on agile describes it as follows
Agile is a set of practices intended to improve the effectiveness of professionals, teams, and organizations. It involves discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to changes in requirements, resource availability, and understanding of the problems to be solved.
In essence, agile and waterfall are different methodologies of management practices used to complete projects. Waterfall method is focused on completion of tasks in a linear sequence of events. While, the Agile method is iterative by nature and focuses on short incremental cycles and collaboration.
The greatest danger in times of turbulence is not the turbulence – it is to act with yesterday's logic.
– Peter Drucker
Why use agile over waterfall management practices?
The waterfall method provides a sense of comfort and has a familiarity associated with it. It's comfortable and familiar because there is a clear start and a definite finish. Agile, on the other hand, is inherently uncertain. It's this uncertain nature that provides the flexibility needed for businesses to be successful and thrive. The flexibility provided by the agile method invites higher quality products, reduction in project risk, better delivery predictability, continuous improvement, higher morale and team output.
Agile shines because of it's cycle based approach. This iterative attitude fundamentally allows for everything to improve incrementally. With agile, you complete many small "projects" in phases with a tight feedback loop. Using the feedback loop, corrections can easily be made, improvements applied, mistakes mitigated all while the team learns how to work together more effectively. If done properly you can transform a small group, a larger team and even a whole business.
Waterfall projects can't adapt like agile ones since their goal is singularly focused. It's this rigidity that is ultimately the biggest limitation of the waterfall method. Due to the fact that everything is fixed, pivots are highly unlikely with these types of projects. Since change is not handled gracefully projects fail to delivery effectively on business needs which of course tend to always change or shift.
If you want to make enemies, try to change something.
– Woodrow Wilson
Introducing a team to agile methodology
Most teams default to the waterfall method because it's a fairly simple flow to understand. Projects come in and have fixed delivery, easy enough. As I mentioned previously, getting people to change is not easy. So you can imagine the difficulty of getting an entire team to change their delivery process. There must be mutual respect, faith and a compelling reason for a team to change.
In order to get team buy in, you have to understand their challenges and offer an improvement over their current system. When you effectively join a development team one of the things you understand is the importance of listening. You need to completely understand the challenges facing the team and their current pain points.There are many different ways to solicit this feedback. The key is to find commonality with the major problems impacting the team. Once you've done your work to isolate key team problems see how agile methods can be applied to fix those problems. Start with the largest problem and come up with potential solutions.
Start by suggesting a change to agile and get team agreement. It's important that you stay flexible in your approach and focus on how agile will improve the team. If you fail to focus on the benefits to the team they will see thru your motives and you'll lose their support. You must also acknowledge that all teams are not the same and they should not transition in the same way. Let the team define the way forward that they see fit and feel comfortable with. Mention your willingness to step back and allow the team to define the transition rules. If necessary be clear about changing to accommodating or even reverting if things don't work out as expected when moving to agile processes.
If you don't like something, change it. If you can’t change it, change your attitude.
– Maya Angelou
Start your agile transition with key team members
Once you have team support and have introduced the agile concepts it's time to apply it. Try it out with key developers and stakeholders (i.e. product owners, project managers, analysts). Communicate with everyone actively involved with your team that you'll be testing out agile methodologies. This serves to provoke interest (people are curious) for some and show your commitment to the team to have key team members test out a system before it's introduced to the rest of the department
Take care to introduce the change slowly. Start by transition part of their day to agile events. Encourage discussions and talk about the value that is provided by the change based on the existing pain points. For example, one of my groups quite often faced problems prioritizing work which caused support tickets to backup. Moving to agile allowed us to prioritize impact which helped reduced unnecessary or less important work and create a more efficient process. Take individual and team feedback at each phase to tailor it for the benefit of the group.
If you always do what you've always done, you'll always get what you've always got.
– Anonymous
Incorporate the rest of the team to use agile
Since you are changing many things by moving to agile it's best to minimize change else where during this transition. For example, try to use the existing agile meeting times when inviting others. Be flexible with existing project deliveries and slowly change to incorporate more and more agile processes. Invite the newer agile team member to discuss with the first adopters. This way, if done properly your first adopters will become advocates for your system and help expedite the transition time and process for the others.
Again, make sure you are tying back how agile will improve working conditions and major challenges facing the team. Make sure team member feel safe and comfortable to share their thoughts and concerns. Take their feedback and be willing to adapt workflows based on their needs. Emphasize that they are the owners of the agile process and that their voices are heard and recognized. Make it clear you are willing to aid and even inconvenience yourself for the success of this transition.
Make the agile switch permanent
Once you incorporate your entire team into the agile process your work has not ended if anything it's just begun. Your team will need your leadership and support to grow and internalize the agile process into their daily work lives. Agile provides your team the constructs and foundation to become success just like you would if you were using it to complete a project. Take team feedback and make adjustments. Use the feedback to iterate and course correct.
Having worked for multiple large corporate organizations and having had the experience of being part of many large scale transformations projects I can truly say people are willing to change if you explain the benefits, make them part of the change process and support them during the transition.