Myths about Agile Software Development

Myths about Agile Software Development

Agile software development is a popular topic of discussion for many businesses. Agile methodology can be defined as a software development methodology, which helps the software developers in their process. Though it is a software development methodology, but it is used not only by the software developers but by project managers, team leaders, development managers, product managers, technical writers, QA engineers and managers engaged in delivering software to their organizations. With Agile methods, a company can get the true feedback from customer end for the better improvement of the project. As such, there tends to be a lot of hype surrounding it and thus, misconceptions abound. Here are some common myths about Agile software development:

Agile development’s primary goal is speed, to churn out applications quickly – Speed comes secondary to quality. To continuously deliver software that provides value at regular intervals, good quality assurance practices must be part of the process.While a transformation to agile can deliver huge benefits, the reality is that the majority of transformations go through a learning curve. While people and organisations are learning, the delivery capability can actually go downwards before it makes the step-change upwards and begins to achieve the improved delivery capability

• Agile doesn’t work for fixed deadline projects – Quite the contrary, it works best in fixed deadline projects. As long as there is an overall understanding of what “Agile” is.   Ensure that all decisions and processes adhere to or support the Agile Manifesto and at least one of the 12 Agile Principles. From a Scrum perspective, you can have a fixed duration (target date, time-boxed sprints), fixed quality (meet DoD), and fixed cost (# of Scrum Team(s) members, operational expenses, etc.).
• Agile requires that stakeholders and developers work in a single location – Whereas, Agile emphasizes heavy stakeholder involvement throughout a development effort. As a result, many assume that team members must all work in the same location for Agile to be successful. With modern technology, this is no longer the case. Teleconferencing systems can facilitate daily meetings among far-flung workers. Likewise, screen-sharing tools often prove effective for impromptu meetings between two colleagues. Bottom line: It’s real-time communication and collaboration that matter, not where or how they occur.
• Agile means no planning – Every project needs a plan for success. In Agile, the long-term plan is divided into different stages that are reviewed regularly. Some upfront planning is required for Agile development projects and should include details such as development principles, an estimate of the work and tasks involved, priorities, and overall budget to act as a guide for decisions during development. The key here is that it is a “guide” and open to change rather than a rigid plan. Planning continues throughout development and is the work of everyone involved.
• Agile needs no architect or project management – Agile projects need a manager who doesn’t just tell you what to do because Agile methodologies are self-managing. However, that manager will keep track of your work to give the feedback to upper management. Agile is commonly combined with Scrum to provide the needed structure and control points in the development process. Software is complex, so you need ideas from different people in order for the project to run smoothly. The manager will help you with this.
• Agile requires a lot of rework – Rework comes in two forms on an Agile project. You’ve got the rework of requirements – customers discovering what they really want. And you’ve got the rework of the software – development teams discover better ways to design the software. Both need to be balanced and tempered. Just as business can’t indefinitely keep changing their mind, development teams can’t forever keep redesigning the software.
• In Agile, individual developers get to do what they want – No, developers do not get to do what they like. If this is true for you then you are doing it wrong. Agile needs well-disciplined teams. What gets done should be lead from a specific role, usually designated the customer or product owner. If developers are doing what they like then there is a good chance something is wrong with that role, the person playing it, or the authority vested in it. Agile requires the development team work together and be disciplined. What gets done and when is lead from a designated role and agreed upon by the team. It seems that the business-side sometimes feel as if developers get to do what they like because they fail to grasp the nature of agile, which is a collaborative process they involve discussion and negotiation between those who are building the system and those who requested the system.
• Agile requires no Documentation or documentation is bad! – Agile works on comprehensive documentation as per its methodology. But if you required a document that is useful for you and another team member, then there will be no excuse for not producing them for the benefit of multiple people. So yes, you can produce them, because it will help you in the iteration. When there are distributed development teams or a high rate or turnover in teams, key knowledge needs to be documented to supplement face to face communication. Documenting key decisions and rationale also helps teams from repeating mistakes. The key to documentation is that it needs to be created when truly needed and contain details that will be used going forward.
• Agile Only Works for Developers and Software -It is true that the Agile Manifesto describes agile in the context of software delivery, but agile can be applied successfully in business environments that are not exclusively software-related. In essence, agile is suited to any dynamic business environment that experiences variability, such as marketing or business change.
• Scrum and Kanban are sworn enemies – Some individuals get a lot of eyeballs by saying that Scrum and Kanban are sworn enemies. Actually speaking many teams are combining ideas from the iterative methods(Scrum and XP) with ideas from Kanban.
• Agile only works with small projects – The Reality is the Agile team model—small, cross-functional groups that collaborate throughout the development process—proves equally effective on small, point solution projects and larger multifaceted efforts to develop complex systems. The tendency of Agile teams to “divide and conquer” can be particularly beneficial on large projects: Organizing solution teams by system functionality and/or architectural components can help minimize redundancy during development. For example, a scrum of scrums meeting—in which scrum teams discuss their work, specifically areas of overlap and integration—is an important technique in scaling scrum to larger project teams.
• Realizing the benefits of Agile only takes a couple months – New to Agile development teams often take years, not months, to fully implement Agile in an organization.
• Claiming to be Agile When You’re Clearly Not – Simply collaborating or paying attention to quality does not mean that you’re doing Agile. If you are not able to adhere to all the principles of Agile, then you are not doing Agile.
• Implementation of Agile is not easy – It is usually not easy to change a complex systems delivery lifecycle to a simple one. Organizations normally find it easier to make things more complex than to simplify them. Sadly, what happens in some organizations is that they try to implement an agile operating model or a single agile framework “by the book” and without understanding the transformational complexity. Therefore, they either fail to implement agile, or they do achieve some success but at significantly higher cost and pain than they would have done if they had managed the transformation more effectively.  Such organizations inevitably fail to achieve the true benefits of agile. You can theoretically learn to fly a plane by reading a book, but don’t expect one to sit next to you on your first take-off!

Conclusion: As you can see, these common myths can cause help for anyone trying to implement agile in their company. But if you recognize this by keeping the above information in mind, your chances of getting better results with agile will significantly improve.

Do let us know your comments if you did you knock into any of the myths above?

http://www.anarsolutions.com/myths-agile-software-development/utm-source=Blogger.com