Are sprint incrementals feasible en the project management environment? It's amazing how agile frameworks seem to dominate our pm dialogues as of late. Am I alone here? Saving Changes...
Could you clarify what you mean by incremental sprints? Sprints are a time-boxing approach specific to Scrum and adaptive approaches encourage incremental delivery of value. Depending on the context of a given project, neither, either or both of these might be applicable. For example, building a new web-based software application from scratch lends itself to incremental delivery through sprints whereas building a house wouldn't.
Kiron
...
1 reply by Eugene Jacquescoley DO PhD MPH
Aug 23, 2022 9:15 AM
Eugene Jacquescoley DO PhD MPH
...
Kiron,
I've done work for pharma. I've pared on teams that utilize 15 min sprints for consensus of clinical data. Simultaneously establishing a baseline scope for another drug en a PMO. We also did increments of work en this environment.
Could you clarify what you mean by incremental sprints? Sprints are a time-boxing approach specific to Scrum and adaptive approaches encourage incremental delivery of value. Depending on the context of a given project, neither, either or both of these might be applicable. For example, building a new web-based software application from scratch lends itself to incremental delivery through sprints whereas building a house wouldn't.
Kiron
Kiron,
I've done work for pharma. I've pared on teams that utilize 15 min sprints for consensus of clinical data. Simultaneously establishing a baseline scope for another drug en a PMO. We also did increments of work en this environment. Saving Changes...
Instead of asking if sprints/increments are feasible in project management, it might be more informative to ask if they're feasible in the context of a given organization. A sprint is just a block of time; an increment is actually a block of work that you hope to finish within a block of time. Project management is interested in who will do what, when, and how long it will take, regardless of how the work is structured.
How the work is structured does matter, but it matters in the context of the organization, the team doing the work and their way of working, and what they are trying to accomplish. We turn to frameworks, methodologies, approaches, etc. to provide consistency and structure, to create repeatable processes that provide the comfortable illusion that somebody is in control, knows what they're doing, that we're doing the right thing, and that we'll get the results we're looking for.
It's more important to understand the context of the organization, the team(s) and people doing the work, the work to be done, and details about the value expected (amount, type, timing, constraints, etc.) than it is to adopt a specific flavor of agile.
Incremental delivery is not only feasible, but routine development for many products, even when in a larger predictive lifecycle. Prototyping is a good example that applies far outside software.
The length of the iteration will vary based on the realities of what you're changing. 15 minutes would be on the very short side. Simple changes on large complex systems could take several weeks to execute all the test cases, but it is still iterative and incremental design.
Even the classic systems engineering development model associated with waterfall (top down decomposition/validation and bottoms up verification) includes feedback loops at each layer. Saving Changes...
Instead of asking if sprints/increments are feasible in project management, it might be more informative to ask if they're feasible in the context of a given organization. A sprint is just a block of time; an increment is actually a block of work that you hope to finish within a block of time. Project management is interested in who will do what, when, and how long it will take, regardless of how the work is structured.
How the work is structured does matter, but it matters in the context of the organization, the team doing the work and their way of working, and what they are trying to accomplish. We turn to frameworks, methodologies, approaches, etc. to provide consistency and structure, to create repeatable processes that provide the comfortable illusion that somebody is in control, knows what they're doing, that we're doing the right thing, and that we'll get the results we're looking for.
It's more important to understand the context of the organization, the team(s) and people doing the work, the work to be done, and details about the value expected (amount, type, timing, constraints, etc.) than it is to adopt a specific flavor of agile.
Thanks Mr. Porter. I'll consider your response. Saving Changes...
Community Champion
