In order to answer this question, I propose to use the formal model proposed by PMI. This model is called the Agile Suitability Model. Why am I suggesting using it? At my project management trainings, I have already done many practical tasks with groups on the topic of choosing an approach to managing specific projects using this model and became convinced of its simplicity in terms of understanding by the audience.
So, you need to understand whether to use, for example, Scrum, for a project for which you have been assigned to be responsible by the team of performers.
First of all, you need to schedule a meeting to which you should invite the Project Customer, the Project Sponsor (if the project has one), and a couple of people from the team of performers.
It is also worth warning the participants in advance that the meeting will take about 1 hour, you need to print the diagram below and distribute it to each participant:
At the meeting, the moderator explains to the group of participants that he will now ask 9 questions, and the group for each of them must agree and give a rating from the whole group, using a 10-point scale.
During the meeting, the moderator asks the following questions:
Support: Do you think the project sponsor (curator) supports the use of Scrum on this project?
If the sponsor of the project is present at the meeting, then he answers this question. If the answer is Yes, then we put 1 point, if No, we put 10 points, if the answer is something like this: "I am not sure that Scrum will help us", then we put 5. Between 1 and 5, 5 and 10, there are other numbers and the sponsor can choose any of them:
Trust: Do the Customer's representatives believe that the team will be able to transform their vision and needs into a product or service – with their support and constant feedback?
For example, if the team believes that the team will 100% be able to create a product without developing detailed TK, but using oral discussions of the requirements and the formulation of a User Story, then we put 1. If there are doubts, but the probability is estimated from 90% to 10%, then we put a score from 2 to 9, and if the group is sure that the team will not be able to get the result without written work with the requirements, we put 10.
Solutions: Will the team have autonomy in making local decisions about how to complete work on the project?
If the evaluators are sure that the product owner will give the technical decision-making about the implementation of the requirements to the team, we put 1, if in doubt, but the probability is estimated from 90% to 10%, then we put a score from 2 to 9, and if the group is sure that the team will not be able to gain autonomy in making technical decisions, we put 10.
Next, the team answers three questions related to the team:
Team Size: Estimate the size of the main project team on the following scale: 1-9 = 1; 10-20 = 2; 21-30 = 3; 31-45 = 4; 46-60 = 5; 61-80 = 6; 81-110 = 7; 111-150 = 8; 151 – 200 = 9; 201+ = 10.
Everything is unambiguous here, and it is almost impossible to put an incorrect assessment.
Experience: Consider the experience and skills of key roles in a team.
Does the team have one experienced team member for each role?
If the team has an experienced Product Owner who has implemented at least 2 projects in this role, a Scrum master with experience in 2-3 projects in this role, and each team member participated in at least 2 projects that used Scrum, we put 1.
If at least one role does not have an experienced participant, we put 5 or a rating next to each other. And if there is not a single experienced participant, we put 10.
Access: Will the team have daily access to at least one customer/business representative to receive feedback and answer questions?
Does the team assess whether the Product owner will be able to answer the development team's questions on a day-to-day basis? If yes - put 1, if in doubt, put from 2 to 9, and if there is confidence that no - put 10.
And the last set of questions is directly related to the project itself.
Changes: What percentage of claims are likely to change each month?
Participants predict how much of the originally formulated requirements for the project product may change during the implementation of the project. If there is an assumption that more than 50% - we put 1, if about 25% - we put 5. The rest of the estimates are based on the fact that every 5% of changes is a score of plus 1 point. For example, for a projection that 45 percent of the requirements will change, the score would be 2.
Criticality: Consider the losses that may occur due to defects, determine how the failure can end.
This is the most difficult question in the third set. If the group assumes that as a result of an error in the working version of the product, people may die, we put 10. If 1 person can die, we put 6. If the error leads to the loss of a large amount of money, we put 5, and if the error leads only to the fact that you need to spend a dozen hours of developers to fix it - put 1.
Delivery: Can the product be developed and evaluated in parts? Will the customer/business representatives be able to provide timely feedback on increments?
It's as simple as that. If you estimate that the mono product is developed in small pieces, and then these parts are connected as in the Lego constructor, then we put 1, if you can connect, but it is more difficult than in the designer, we put from 2 to 5. If the evaluators believe that it is almost impossible to develop a product with increments (as, for example, shampoo), then a score of 10 is given.
After all the estimates are plotted on the diagram, we get some project profile.
For example:
For this project, I would definitely not recommend using Scrum. For him, it is better to use a hybrid model of the life cycle (LC) of the project, since 5 points out of 9 are in the field of the hybrid model, 3 - in the field of the predictive model of the LC and only one fell into the Agile circle.
Here is such a fairly simple, but useful model for choosing an approach to the life cycle of the project. Well, the choice of a specific methodology after choosing a project life cycle model is a matter for another article.
Good luck in choosing the right models of LC projects!
No comments:
Post a Comment