Page 2 of 2
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.
For the purposes of this article, descriptions of the two approaches are simplified to highlight key principals and differences. I encourage all readers to conduct their own research into each approach more thoroughly.
About the Author
Gina Lijoi has worked in the online space for the past 10 years, originally focused on Project Management, and more recently, operational and functional efficiencies. Gina has managed hundreds of client initiatives, focusing on verticals including pharmaceutical and healthcare, consumer packaged goods, media and entertainment, and travel. She has acted as a consultant and contributor to multiple international Project Management websites and print publications.
About Executive Brief
ExecutiveBrief, the technology management resource for business leaders, offers articles loaded with proven tips, techniques, and action plans that companies can use to better manage people, processes and tools—the keys to improving their business performance. For more information visit us at: http://www.executivebrief.com.
Only registered users can write comments.
Please login or register.