Skip to main content

When Not To Use Agile

Over the years, Agile methodologies have taken the heat when they appear to have failed to deliver expected benefits to an organization.

If our project fails, the tendency is that “we must blame the Agile process and our practices in some way for this”.

Agile is not a magic stick to save a failing project and bring immediate results. It lets you uncover better ways of developing software by doing it and helping others do it.

As with all development methods, the skill and experience of users determine the degree of success and/or abuse of such activity.

So sometimes we obtain the agility by making up our own variation of this methodology. In this case, failure of this project should largely be incumbent upon us for deciding to sacrifice the practices we chose to ignore and the new ones we added.  Some are Agile while just for namesake, and following no methodology, just cherry-picking a couple of practices here and there, and picking the principles they like.

1.  Checkbook commitment doesn’t support organizational change management. CEOs create within the company their own personal family dysfunction.

2.    Culture doesn’t support change.

3.    There are no or ineffective retrospectives. Actions which come out get ignored or written off.

4.    In a race to finish features, the infrastructure gets worse and architecture becomes unstable. Distributed teams make this worse.

5.    Lack of collaboration in planning. Like having the whole team for release planning.

6.    None or too many Product Owners. Both cases look the same. Agile is yet another hat to wear and the person is already too busy. They check out and ask the team to just do Agile. Can’t get past the ‘this sucks’ phase of adoption if the business is not bought in.

7.    Bad Scrum Master which uses a command and control style with the team to look faster, yet in reality slows things down. Low morale actually makes people less productive

8.    No on-site evangelist. If the teams are distributed, need one at every site. Can’t reap the benefits of Agile or offshore without an on-site coach at each location.

9.    No solid team.

10. Tsunami of technical debt if don’t pull tests forward.

11. Traditional performance appraisals. Individual heroics rewarded

12. Revert to traditional. Change is hard.

World of Agile is a brand owned by Effective PMC Pvt Ltd. Founded in 2009 and specializes in providing professional training services on Project Management related certifications. In the last 7 years, trained more than 10K+ professionals from various verticals on certifications by Project Management Institute (PMI)® Such as Project Management Professional (PMP)®, PMI Agile Certified Practitioner (PMI-ACP)® other certifications like SCRUM, PRINCE2, ITIL, MICROSOFT PROJECT and many students have passed PMP® examination after attending our courses.

For More Information, Follow the Links below-

Comments

Popular posts from this blog

What are Important Roles in Scrum-Agile Teams?

The Primary Team roles in scrum are named as • Product Owner  • Scrum Master • Development Team Scrum Master, Product Owner, and Team are considered as people who are committed to the project while customers and executive management are considered as involved but not committed to the project. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.  Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available. All the roles are based on the concept of “S...

Agile Administration in Tooling and Tool Integration

Tools are inherent to our jobs, inherent to how we solve the problems we face each day. Our comfort level with the set of tools that are available to us, and our ability to adapt to new tools as they evolve and shape our thoughts and ideas. The availability of collective knowledge within the palm of your hand combined with the collaboration across organization and company boundaries through open source software is dramatically disrupting the status quo of work. Companies mired in managing infrastructure configuration management by hand with unknown numbers of divergent systems, unable to quickly change and respond to market demands will struggle against their counterparts who have managed to contain their complexity on one axis through infrastructure automation. While it is possible to manage servers by hand, or even artisinally crafted shell scripts, a proper configuration management tool is invaluable especially as your environment and team changes. Even the best software developers ...

Tracking and Communicating Progress in Agile

Information radiators are meant to display information at a public place so that the information can be noticed by as many people as possible without making a conscious effort to do so. The idea of information radiator was invented by Alister Cockburn, who was a big believer in effective and timely communication. Information Radiators should display the current information about the project whatever is critical for the team to learn. It could include Schedule, tasks, issues, progress etc. The Most common forms of Information Radiators are ·         TaskBoards or Kanban Boards ·         Big Visible Charts such as BurnDown Charts ·         Street Lights and Lava Lamps Characteristics of Information Radiators which make the Information Radiators work ·         Simplicity : The information Radi...