Frequent changes


51
views
1
7 months ago by
Admin  
As Agile suggest that we shall embrace the change, we try to accommodate. But Is it fair to have the frequent changes all the time, even during sprints? How to embrace these changes?
Community: Agile

2 Answers


3
6 months ago by
1. Customer & his business needs comes first. So, I will try to find which method of agile suites the need of the customer to execute the project.

2. Though agile suggests frequent changes, we can reduce the frequency of change received from client/reduce the impact of accepting a change by

2.1) understanding/gaining domain knowledge of the client

2.2) by applying a flexible design on the project which can accommodate any types of change during any place of development with lesser rework/modification. Only thing is we need to run our thoughts & implement our technical knowledge.

3. Involving client in our sprint plan/retrospective gives him the amount of effort team puts to plan sprint & amount of time that team needs to completes, etc., So, we as agile team follows the discipline when accommodating 

3.1)  a change by taking out another equivalent story from sprint.
3.2)  no swap allows during the completion day of the sprint.
3
6 months ago by

As Agile suggest that we shall embrace the change, we try to accommodate.
Yes , we shall embrace the change, as agile suggest, however agile also says that in order to accommodate this change, we need to do re-plan every time, when the change comes.

But Is it fair to have the frequent changes all the time, even during sprints?
It is not fair to have frequent changes all the  time, even during the sprints.


Frequent changes might be due to various reasons:
1. Client is not sure what he wants
We need to discuss with client and understand the requirements. Also educate client about the way he should provide the requirements, so that he gets best from us. We can check if we can understand his business and act as shadow owner and fill the gap or have product owner involved.

Or see if client can have someone at his end to fil the gap.


2. Client 's business needs requires those changes.

If client’s business needs those changes, then the framework SCRUM might not be right fit for him

Or the length of sprint is not fit for him. Need to involve client in the discussion and figure  out the gap.

Then accordingly either choose

-- Kanban [if changes are always coming],

-- SCRUMBAN [depending on how much of changes are not coming ], so let’s say 80% functionality go as per plan, 20% variation.

    So choose SCRUMBAN and plan only for 80%, 20% keep flexible for changing requirements, production fix etc.

-- or change the length of the scrum,

So let’s say, our analysis shows that we need to show him demo before moving ahead, so start showing him demos more often, and start having shorter sprints. So that with early demos client can make up his mind.


3. Client is just coming up with requirements and not prioritizing

Educate him on Agile and SCRUM. Educate on how prioritization is important to finish the things are the most important for him.

How prioritizing will give them the most business value. Once the sprints starts , changes are not accepted in existing sprint, however can be easily accommodated in future sprints.


4. Client is not aware about SCRUM
Educate him on Agile and SCRUM and how it can help them in getting the most business value

How to embrace these changes?

We embrace the change by planning for the new changes that have come.

So we discuss with the customers and take priority from them. Once the priority is decided, its added in future sprints/ backlog.This does not impact existing ongoing sprint.

However if changes are coming during the sprint, then below approach can be taken

As mentioned in 1 point, we can manage with choosing the right framework for the project.

In SCRUM BAN, we can negotiate on the 20% of the time ,  those user stories that can be taken care in that time, instead of what was temporarily planned.

However it should be of equal or less story points. Not more than what was actually planned for the team.

In SCRUM, if its once in a while  we need to negotiate with client which stories we need to leave it and which to continue on. However it should be of equal or less story points. Not more than what was actually planned for the team.

But here again there is catch. In SCRUM, we decide goal for the sprint. You must take new stories from client, which are still going to go with the goal.

If taking new stories is not helping in achieving goal, which means now Sprint goal is no longer valid. We should cancel the sprint and start the sprint again.

Please login to add an answer/comment or follow this question.

Similar posts:
Search »
  • Short Duration projects
    We often receive project which lasts only few weeks(2-4). Is it suitable to implement agile in it...
  • 100% Agile
    My Team is so called Agile, though at times I feel we are not 100% Agile. How do I know if w...
  • Dual DSM wasting time
    Scenario: As we are working on offshore/onshore model, we are doing 2 DSM: - An internal one in ...