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

PRINCE2's Project Organisation

PRINCE2's organisation theme defines the Project Team or organisation. It establishes the project's structure of accountability and responsibilities. As PRINCE2 is based on a customer/supplier environment, it assumes that there will be a customer who will specify the desired result and probably pay for the project, and a supplier who will provide the resources and skills to deliver that result. A successful project management team should have business, user and supplier stakeholder representation. Business The products of the project should meet a business need which will justify the investment in the project. Should also provide value for money. The Executive looks after business interests User The user viewpoint should represent those individuals or groups for whom some or all of the following will apply: They will use the outputs of the project to realize the benefits after the project is complete They will operate, maintain or support the project’s outputs The outputs of t

Scrum Timebox

Scrum relies heavily on the concept of Timebox. Timebox is setting a fixed time limit to any activity and letting other characteristics such as Scope vary. A time box could be ·           A Meeting ·           A Sprint ·           A Test activity ·           Development Activity ·           Or Practically anything such as you chatting with your friend on social networking site. The fact about timebox is that the time is limited. You can adjust other parameters such as ·           How much you can get done ·           Which item you must prioritize ·           However, deadlines cannot be moved. In Scrum, all the project iterations, meetings must be timeboxed and time limits be respected. This is very important and non-negotiable aspect of Scrum. Lets look at how a timebox actually works. ·           Timebox can be of any duration  - hours, months, years ·           It is essentially a control mechanism to ensure how much time you wish to devote

The Service Value System - Continual improvement | ITIL V4 Certification

Continual Improvement Continual improvement takes place in all areas of the organization and at all levels, from strategic to operational. When provisioning a service we should always keep continual improvement in mind, and should always be looking for opportunities to improve. To support continual improvement at all levels, the ITIL® SVS includes: ITIL® Continual Improvement Model provides organizations with a structured approach to implementing improvements Improve Service Value Chain Activity Continual Improvement Practice Continual Improvement Model Continual Improvement Model can be used as a high-level guide to support improvement initiatives.  The model supports an iterative approach to improvement, dividing work into manageable pieces with separate goals that can be achieved incrementally. The scope and details of each step of the model will vary significantly based on the subject and the type of improvement The steps of this model do not need to be carried out in a linear fash