Please login or join to subscribe to this thread
Agile approaches fit best where both the complexity, and the anticipated frequency of change are high. If it's not complex, not much collaboration is required. If it's very stable, then the evolutionary nature of incremental and iterative approaches don't necessarily add more value.
Congratulations on having corporate level support for agile. Please note that this is not an easy path for the organization.
Not only must you re-align and re-train people to work differently, but you also need to impress on senior management that project monitoring and reporting is going to be quite different. With Agile projects you often cannot answer questions such as how far along you are or what will be in the product by the end of the project.
On the plus side, you can use velocity to predict when the backlog will be completed.
The selection of agile approach is related to multiple factors namely, organizational culture, nature of the endeavor, and team's domain knowledge. The project constraints also influences how a selected approach is implemented.
Yes I agree with @Ashok, all the factors he referenced are important, you must discover if an agile approach improve the project performance and value otherwise don't make sense.
The problem here is the tendency to fall in the trap. First question[ do your company understand what Agile really is? Agile is no a method/framework/process. Second, what defines if Agile can be used or not? Your current reality. Agile must be used because it is a solution to a problem, not a new fashion or something like that. Agile is a matter to take into account the whole organization from a systemic point of view. If not you will fail.
Let's separate an agile mindset from an adaptive lifecycle. The former is applicable to all projects whereas the latter will fit certain projects better than others.
There are many project profiling models available out there - PMI has provided some dimensions for consideration in their Agile Practice Guide.
Here are just a few of the questions or criteria I'd ask about...
1. Level of complexity and uncertainty
2. Ability to realize value early and regularly
3. Ability to closely collaborate with the customer & key stakeholders
4. How dedicated are the team members and other key roles?
5. Can you construct a "whole" team?
6. Can a PO be found who is empowered, sufficiently knowledgeable and has sufficient capacity?
Depending on the size of the organization, you can use different approaches. I have seen success mostly with flexible frameworks like Deciplined Agile where you should start with introducing core principles and practices, such as introducing short iterations to move through "phases", changing requirements gathering and planning methods to user stories and releases. As the skills of the enterprise increase and practices become more mature, you can add more to the mix.
I would like to highlight two important things if I may:
Sergio: "Agile must be used because it is a solution to a problem, not a new fashion or something like that"
100%. People keep on going Agile nuts because.... they think they have to. If you do not implement Agile then you are a failure. WRONG!
Kiron: "Let's separate an agile mindset from an adaptive lifecycle"
100%. Being agile is a must in any organization and for any PM/BA. Even using a predictive approach you need agility. There is no such thing as an Agile PM! If you do not have the ability to be agile then you are probably a bad or mediocre PM at best. Same of an organization.
Something you might want to have a look at is the Beyond Hybrid Model
(https://beyondhybridagile.com/) that Mike Griffiths demonstrated during the Organizational Agility conference.
All this stuff have been defined "formaly" in 1990 and before. For example, take a closer look to Tom Gilb´s EVO or Allistar Cockburn´s Crystal Clear. In the model Mike presented (while it has a great value) something is missing (sorry if I missundertood): systemic concept. Agile is about to take into account the whole enteprise architecture, not the team size, neither the complexity or things like that PLUS the product/service/result to be created. And that is the same for each approach you use. Is not for agile only.
Please login or join to reply