Project Management Central
|
Please login or join to subscribe to this thread
|
|||
|
|||
Sergio Luis Conte
Helping to create solutions for everyone| Worldwide based Organizations
Buenos Aires, Argentina
I will ask about what I am living from years including today. I´d like to say that I never lived iterations with that longitude, but that´s not matter. The key point here is the the statement "if we are on plan". Suppose you use fixed longitude iterations (I think is what you are doing). The only thing you can assure is you will deliver what is committed before the iteration begins. So, there is no plan in the "traditional" meaning if this is what your customer is referring to. What there is a set of features that you will release each 4 month. The "plan" is the whole roadmap. What you can publish is a Kanban board or the way you like call it to make your customer visible how features are progressing in the 4 month iteration. I know it is hard to implement but is the same way that a factory works with this type of things.
...
1 reply by Keith Novak
Sep 28, 2021 7:14 PM
Keith Novak
...
Thank you Sergio,The Kanban idea gives me something to work with. I have tried a bar-chart type view like you would see in a factory and a few self-invented tools but they were mostly lost on the managers. The Kanban format would need some adaptation, but it does help show the individual pieces progressing, as well as the larger picture of will we achieve the end date. Despite the customer desire to be more modern in how they develop software, the reporting to management is archaic. They expect maturity levels for each team to align like major program milestones. That over-constrains the entire plan and is unworkable. The Kanban type format can show maturity milestones by individual team (content identified, software received, integration, test, etc.) but not require the milestones be at the same date in the vertical columns. I will have to experiment with this. Thank you again! Keith 
Keith -
I'm assuming you are referring to iterations as a release rather an a sprint as four months is awfully long for a sprint. At that length, it makes for a big batch so inspection and adaptation are pretty difficult. If individual features or functions roll up to epics, then you could use epic status (done/not done) as one measure of customer-facing progress. Burnup charts at an iteration (release) level might also help. Finally, you might consider using a dependency map to visualize the dependencies between teams working on the same product. Kiron ...
1 reply by Keith Novak
Sep 28, 2021 7:29 PM
Keith Novak
...
Kiron,
You are picking up on exactly the problem. I don't want to call them sprints because they are not, and the big batch creates big problems. Between myself and a SAFe expert I collaborate with, we can tell that they are trying to insert some agile concepts, but missing others entirely. We are trying to develop a dependency map. Certain teams are clearly assuming there is only one way to do things (theirs), so I am trying to challenge those assumptions and break the 4 months down into more manageable pieces with integration points. The burnup chart is something I have considered, but not tried yet. When plan dates keep moving, it is difficult to show the progressing slide overall. By plotting all the intermediate dates, that will paint a better picture if we are generally following the release curve, or if we continue to diverge. I might need a couple views on a 4-square like the overall trajectory, and which teams account for the variance. Thank you for the valuable input! Keith 
Keith Novak
Tukwila, Wa, USA
Sep 28, 2021 5:58 PM
Replying to Sergio Luis Conte
...
I will ask about what I am living from years including today. I´d like to say that I never lived iterations with that longitude, but that´s not matter. The key point here is the the statement "if we are on plan". Suppose you use fixed longitude iterations (I think is what you are doing). The only thing you can assure is you will deliver what is committed before the iteration begins. So, there is no plan in the "traditional" meaning if this is what your customer is referring to. What there is a set of features that you will release each 4 month. The "plan" is the whole roadmap. What you can publish is a Kanban board or the way you like call it to make your customer visible how features are progressing in the 4 month iteration. I know it is hard to implement but is the same way that a factory works with this type of things.
The Kanban idea gives me something to work with. I have tried a bar-chart type view like you would see in a factory and a few self-invented tools but they were mostly lost on the managers. The Kanban format would need some adaptation, but it does help show the individual pieces progressing, as well as the larger picture of will we achieve the end date. Despite the customer desire to be more modern in how they develop software, the reporting to management is archaic. They expect maturity levels for each team to align like major program milestones. That over-constrains the entire plan and is unworkable. The Kanban type format can show maturity milestones by individual team (content identified, software received, integration, test, etc.) but not require the milestones be at the same date in the vertical columns. I will have to experiment with this. Thank you again! Keith ...
1 reply by Sergio Luis Conte
Sep 29, 2021 7:01 AM
Sergio Luis Conte
...
You are welcome. I agree with you that some "artifact" needs adaptation for being adopted. For example, when I started using Kanban with this type of customers I used MS Teams Planner which is "disrespect Kanban" to call it Kanban. But, it helped me to introduce them in this type of tools mainly because as you know Kanban is not the board only, is a whole method/way of working. It worked for me. But at the end, as you know, the important thing is try to understand how the goal is reached.
Keith Novak
Tukwila, Wa, USA
Sep 28, 2021 6:12 PM
Replying to Kiron Bondale
...
Keith -
I'm assuming you are referring to iterations as a release rather an a sprint as four months is awfully long for a sprint. At that length, it makes for a big batch so inspection and adaptation are pretty difficult. If individual features or functions roll up to epics, then you could use epic status (done/not done) as one measure of customer-facing progress. Burnup charts at an iteration (release) level might also help. Finally, you might consider using a dependency map to visualize the dependencies between teams working on the same product. Kiron You are picking up on exactly the problem. I don't want to call them sprints because they are not, and the big batch creates big problems. Between myself and a SAFe expert I collaborate with, we can tell that they are trying to insert some agile concepts, but missing others entirely. We are trying to develop a dependency map. Certain teams are clearly assuming there is only one way to do things (theirs), so I am trying to challenge those assumptions and break the 4 months down into more manageable pieces with integration points. The burnup chart is something I have considered, but not tried yet. When plan dates keep moving, it is difficult to show the progressing slide overall. By plotting all the intermediate dates, that will paint a better picture if we are generally following the release curve, or if we continue to diverge. I might need a couple views on a 4-square like the overall trajectory, and which teams account for the variance. Thank you for the valuable input! Keith ...
1 reply by Anthony Little
Oct 08, 2021 8:26 PM
Anthony Little
...
Hi I would highly recommend looking at 'agile product owner in a nutshell' on youtube by Henrik Kniberg. It's a short 15mins but it is a massive knowledge donation to the product development community. He does some very short discussion around burnup charts that uses plain language and simple powerful insights.
Milestone is used often in Project Management conversations in general. It's not specifically an Agile (nor Scrum) term, but its meaning is broad enough (as shown above) to be usable in Agile contexts.
Sergio Luis Conte
Helping to create solutions for everyone| Worldwide based Organizations
Buenos Aires, Argentina
Sep 28, 2021 7:14 PM
Replying to Keith Novak
...
Thank you Sergio,The Kanban idea gives me something to work with. I have tried a bar-chart type view like you would see in a factory and a few self-invented tools but they were mostly lost on the managers. The Kanban format would need some adaptation, but it does help show the individual pieces progressing, as well as the larger picture of will we achieve the end date. Despite the customer desire to be more modern in how they develop software, the reporting to management is archaic. They expect maturity levels for each team to align like major program milestones. That over-constrains the entire plan and is unworkable. The Kanban type format can show maturity milestones by individual team (content identified, software received, integration, test, etc.) but not require the milestones be at the same date in the vertical columns. I will have to experiment with this. Thank you again! Keith 
David Portas
Ny, USA
Hi Keith,
With such long iterations maybe one approach is to start by asking the team to work from a backlog. Encourage them to record activities in INVEST form and close them off as they are done. If they can do that for a while then you have the evidence that things really can be achieved in shorter cycles. Share information with them informally (brown bag meetings) on the experience of other teams who work in shorter iterations. Example: https://www.youtube.com/watch?v=0XpAtr24uUQ
Anthony Little
Mulgrave, Vic, Australia
Sep 28, 2021 7:29 PM
Replying to Keith Novak
...
Kiron,
You are picking up on exactly the problem. I don't want to call them sprints because they are not, and the big batch creates big problems. Between myself and a SAFe expert I collaborate with, we can tell that they are trying to insert some agile concepts, but missing others entirely. We are trying to develop a dependency map. Certain teams are clearly assuming there is only one way to do things (theirs), so I am trying to challenge those assumptions and break the 4 months down into more manageable pieces with integration points. The burnup chart is something I have considered, but not tried yet. When plan dates keep moving, it is difficult to show the progressing slide overall. By plotting all the intermediate dates, that will paint a better picture if we are generally following the release curve, or if we continue to diverge. I might need a couple views on a 4-square like the overall trajectory, and which teams account for the variance. Thank you for the valuable input! Keith |
|||
Please login or join to reply
ADVERTISEMENTS
|
"Every child is an artist. The problem is how to remain an artist once he grows up." - Pablo Picasso |
