There are a lot of myths floating around about agile development. Here’s what companies can really expect.
Myth: Agile is about making IT better.
Reality: While agile is a better way to run IT projects, the real benefits arise from a new and improved partnership between business and IT. Instead of negotiations and change control, a truly joint team is developed, and both groups share the same incentive to build the best product and deliver the maximum value given the available resources.
Myth: You need scrum masters and agile coaches.
Reality: Scrum masters and agile coaches are key ingredients to any agile program, but they’re not the be-all and end-all. They usually don’t discuss strategic and organizational implications with senior business executives. For instance, they don’t work with finance to address changes to funding, and they don’t identify ways to meet the specific requirements of legal, risk, and compliance.
Myth: Agile doesn’t apply to back-end systems.
Reality: Agile is often used for front-end development; frequent demos are a great way to engage users and incorporate their feedback. But benefits such as empowered product ownership, shared understanding, and transparency are arguably even more important for large, complex back-end projects. Why? Because the iterative process can limit the risk that potential issues will arise late in the game and cause expensive rework.
Myth: Agile requires state-of-the-art technology to get started.
Reality: Technology is not a precondition to agile. While high-end technology can help, empowered product ownership, dedicated cross-functional teams, and an iterative way of working can be implemented in virtually any company. Technology would come into play with geographically dispersed teams that require shared screens and video conference tools to function.
Myth: We can’t be agile because of legal, regulatory, and compliance constraints.
Reality: While this is false, companies do need to engage these departments early on in the journey, and they all must work together to define how their needs can be met by the agile model. Ultimately, members of the legal and compliance departments favor the agile model. They’re engaged earlier and can review prototypes and documentation, and they can interact with defined points of ownership.