Before jumping into Agile, it is good for organizations to better understand the spirit of Agile and how to use it to make the shift.

More and more companies are making the transition from traditional development methods to Agile. Many times, development organizations are not always clear why and how to make this shift. A common “pro” that I hear from stakeholders and project managers new to Agile is, “We need to move to Agile because we are always changing our minds.”

However, the Agile Manifesto actually values: “Responding to change over following a plan.” It is common for new organizations to misinterpret this as, “we can change our minds without impact to the plan.” Before jumping into Agile, it is good for organizations to better understand the spirit of Agile and how to use it to make the shift.

Agile offers a lightweight and flexible framework that delivers business value much more quickly than traditional development methods. And, its continual iterative process provides an adaptability that ensures that software remains aligned with business needs, which makes it very appealing.

Unlike traditional development methods, Agile is about the conversation of what the business is looking for in a system. It focuses on user experience rather than system experience, and on collaboration and communication at the right levels – not extensive documentation. Having said that, there are some key best practices that can make all the difference in successfully practicing Agile and reaping the many benefits it has to offer.

Get Everyone Aligned

Agile focuses on user experience rather than system experience, and on collaboration and communication at the right levels

The first order of business is to get everyone on board with what Agile is, what it means, and how it works. Agile is as much a philosophy as a methodology, and the way you make it work for your projects and environment will look different for your company than for someone else’s. Right from the start you should establish your approach and ensure you have buy-in from all participants. I have seen this work from both a top-down and bottom-up approach. The key is to prepare Agile training for all levels of the organization prior to the start of the project.

Ensure Participation

Agile absolutely requires participation. But most people involved in a software project have other priorities and responsibilities, which can diminish the participation that’s needed in an Agile environment. It is essential to create a cadence in your meetings that is predictable, measurable, and actionable to keep your users engaged in the conversation. This will require more face-to-face time because nonverbal communication is key. If your teams are distributed, hold regular videoconference for the meetings. Don’t shortcut this − the benefits of seeing someone’s face in a Scrum meeting cannot be overstated. Don’t settle for a conference call if video is a possibility.

Keep your business owners engaged throughout the process − and make sure it’s valuable for them. Business owners do not have to participate in every meeting. Make sure the meetings they’re in are tailored specifically to their concerns and domain knowledge. Most likely, your business owner would not care about the internal data structure being developed, but they would care what type of reports they could get from the system. The bottom line is, if people − from stakeholders to the development team − aren’t engaged or don’t show up, you can do the mechanics of doing Agile, but you’re really not doing Agile.

Collaborate

It is essential to be transparent with all of your work in progress even as your specifications are being created.

Set up a collaboration tool set − a common place for shared docs or wiki page where people can see your work in progress. It is essential to be transparent with all of your work in progress even as your user story and/or specifications are being created. If you don’t have access to an electronic online collaboration tool set, create portable user storyboards out of paper and sticky notes. Always have a place where people can see the work in the progress, and feel comfortable commenting on it. That can be a Wiki or a war room with marker boards and Post-It notes, but there must be a project nexus where all information is available.

Be Transparent

Be as transparent as possible. It’s amazing what feedback and ideas you’ll get from people when they see what you’re doing. You’ll discover things you didn’t even know were an issue all because someone else may have a perspective or information that you don’t. This also allows for the team to make small corrections through the process to keep the project on track, as opposed to a major shift after a completed phase typically done in the traditional waterfall approach. Having a nexus, as described above, is one way to force ourselves to be transparent – all the time.

Be Disciplined

Lastly, don’t fall back into waterfall even when it may seem easier or simpler. Embrace and work through the challenges you may face. Take the time to do an Agile retrospective; not only will it be very helpful, but it is essential to continually improve your process. Agile is a set of values and not a methodology. Remind yourself and your organization of the Agile Manifesto and work in the spirit of it to make the shift.