| Home » News » News & Events » From Waterfall to Agile Software Development: 4 Critical Steps for a Smooth Transition | |
Waterfall and agile are two unique development models used in interactive and software production. It's likely the debate over which is better will continue indefinitely, but in reality, both approaches boast significant but different benefits. It's generally accepted that agile, specifically, lends itself well to software development and large-scale website projects. Although a novice Project Manager may feel more comfortable working with a waterfall approach because each step is predictable, letting go of the familiar may well be worth it to make the move to an agile model. The collaboration and flexibility that agile brings can result in a better end product for your client, and a more engaged, harmonious internal team.
At a high level, the waterfall approach infers structured and linear project cycles. Detailed project specifications and a statement of work are produced early on, and the waterfall model mandates that this plan is adhered to without deviation. I often refer to this approach as 'passing the baton', since individual resources tend to work on their piece of the end deliverable in isolation, and then they pass it along to the next person in the sequential production cycle. Using this approach, feedback and revisions are slated as the final phases of production, once the entire product has been completed. This means altering elements can be costly and cumbersome, because even a small change at the end of a project may have implications to many parts of a finished product.
Agile is very different in that teams develop smaller, low-fidelity portions of the end product quickly, re-evaluate and revise them (often in collaboration with the client) until a level of satisfaction is achieved. These smaller pieces are then assembled near the end of the project lifecycle, once they are approved individually. As a result of this iterative pattern, agile allows for organic changes and improvements along the way, even to project specifications. Internal disciplines are expected to overlap, so that the contribution of individual resources becomes stronger when tempered with the expertise of other team members. In fact, agile dictates that communication among the team must occur daily, so that everyone is aware of individual progress. Meetings are short, and the emphasis is moved away from documentation, to rapid completion of incremental tasks (this shortened work cycle is called a 'sprint', for obvious reasons). In turn, the client is able to see something tangible earlier on in the project lifecycle, so that feedback can be provided and considered very quickly. Working to complete smaller increments of a product also results in a higher frequency of delivery to the client, ensuring they remain engaged for the duration of the project. Progress is measured by the functional elements the team develops.
Agile methodology also requires different financial reconciliation practices. Because teams will go through more iteration, and potentially even change some of the original project specifications, the Project Manager will have to implement more check-points to assess budget. To exercise budgetary control, the Project Manager must assess and dole out project hours to team members in smaller chunks – hours should be assigned to each team member weekly. Although the agile project workflow process may not seem as structured as with the waterfall approach, the consummate goal of on-time, on-budget still applies.
If you're currently practicing a waterfall approach and would like to make the move to an agile model, it can be done. Here are some steps you can take to smooth out the transition and engender some faith among your internal team:
Preparing for change – share the plan
One of the best tools a Project Manager has at her disposal is communication – it's free, it's effective, and it's a simple way to engage your team. When you communicate your plan to move to an agile model, explain why you'd like to make the change. Share some of the high-level benefits, but also make sure to speak with team members individually, to address how the change may improve things for them. The goal is to achieve buy-in from your colleagues – once people believe in the change, they will begin to share some of the responsibility of implementation with you. And if no one wants to join your campaign for change, don't be scared to lead the way. Simply demonstrating your own commitment to this new approach will build a sense of credibility and legitimacy around your point of view.
Collaborating with the team – the spirit of agile methodology
One of the core principals of agile methodology is collaboration, so it makes sense that the implementation of this approach would exude its virtues. You only stand to gain by allowing others to contribute to this shift. Team members will bring their own experiences to the table and help ensure the first implementation of the framework will facilitate and not hinder their own project responsibilities. There will always be those who are less optimistic, who question each detail and point out the flaws – don't get frustrated or discard their comments, since responding thoughtfully is more opportunity to engage in constructive conversation about the agile approach.
Expect some bumps in the road – change is never easy
Making the transition from waterfall to agile means leaving behind many of the comforts you and your team have gotten used to. Agile stands for iterating and improving, discussing and redefining – many things that pose challenges within a traditional waterfall development cycle. For these reasons, your biggest bump in the road may be sheer resistance and fear of the unknown – some of which may even be your own. Just like with a client project, more extensive planning and conversation will make implementation much smoother. Let the team know you may not get it right the first time, so what's important is to continue the dialogue and refinement of the methodology within your organization. A good tactic would be to set-up a meeting room or some office area dedicated to documentation and planning for the agile transition. Post some white papers on the wall, perhaps some diagrams of the new process – whatever will help get the team thinking, breathing and offering solutions for the transition.
Implement, assess and refine – as within the agile cycle itself
Once you have a chance to pilot your first project using the agile approach, be sure to hold a post-mortem, or post-launch review, to openly discuss where the process could be improved. It's important to include everyone who participated in the project so that every viewpoint is considered. Because every organization is different, you may only apply certain practices of agile methodology that best align with current business procedures. Use your designated agile office space from my recommendation above to post iterations to the process, like you would for an actual client project. Your ability to respond to change is a pillar of agile methodology, so make sure you practice what you preach. In addition to holding a post-mortem, use the shorter production cycles and daily meetings to share learnings and fine-tune the process. Agile lends itself very well to iterative process improvement.
A shift to agile development methodology can change the way an entire organization operates through the individuals it affects. The principals of the approach foster holistic thinking, heightened engagement, and communication and problem solving skills. This style of collaboration will also result in a greater understanding of practice areas among the larger team – this will create long-term synergies that encourage individuals to consider varying points of view, even when they work in isolation. As online and software initiatives take on more sophistication in usability, interface design and technical functionality, there will be a stronger mandate for this collaborative and flexible style of production.
This article was originally posted by Executive Brief and is the property of ExecutiveBrief