Add agile workflow document#1
Conversation
|
|
||
| 1. **PM Kickoff** (30-60 min, once per OCPSTRAT): | ||
| - PM explains the what/why, success criteria, and priority. | ||
| - The 2 engineers who will own the breakdown attend. |
There was a problem hiding this comment.
At the strat level, we assign a single "architect" who is repsonsible for this. I am totally +1 for having this be shared, but you may want to clarify how the single architect to 2 engineers alignment works
There was a problem hiding this comment.
At the strat level, we assign a single "architect" who is repsonsible for this.
What I saw -> the pod managers are assigned at the OCPSTRAT level. Just verified in our pod, yes the OCPSTRATS are assigned to managers, not architects.
I'll explain this in more detail:
- The 2 engineers who will own the breakdown attend.
When our pod gets an OCPSTRAT I'd propose the two most senior engineers in the team take it for the PM Kickoff and after that refine it together till they have at least one refined epic and a bunch of unrefined stories.
Once we have at least one refined epic and a bunch of unrefined stories we'll involve the remaining engineers, they can then start refining the stories. And the 2 most senior engineers continue on more epics or help with the stories -> they know best at that point.
Step 3 and 4 stays as is -> the team reviews the "ready to be develop" stories async and in the optional weekly refinement slot stuff which is not clear can be discussed.
I answer below why "optional weekly refinement".
There was a problem hiding this comment.
the pod managers are assigned at the OCPSTRAT level
The strats are assigned to managers yes, there's also an architect field that we assign to the engineering lead. E.g. https://redhat.atlassian.net/browse/OCPSTRAT-2660 is assigned to Dam as architect
There was a problem hiding this comment.
I'd propose the two most senior engineers in the team take it for the PM Kickoff
Be careful here to ensure everyone gets an opportunity to do this kind of refinement if they want to, good for individual growth
| - Goal | ||
| - Scope | ||
| - Mapping back to the OCPSTRAT | ||
| - Technical design (architecture decisions, component interactions, API contracts), done by the principal/architect engineers |
There was a problem hiding this comment.
Don't understand.
Do you mean to add Enhancements to this list?
Technical design (architecture decisions, component interactions, API contracts, enhancements?), done by the principal/architect engineers
| - T-shirt size estimate (S/M/L). Anything bigger than L, split it. | ||
| - Technical design (only if non-obvious), added by whoever picks up the story | ||
| 3. **Async Review**: Rest of team reviews in Jira, leaves comments. | ||
| 4. **Open Questions**: Go to the optional weekly refinement slot (45 min). |
There was a problem hiding this comment.
I mean the meeting to be optional, not the attendance.
Two reasons:
- There won't be questions to the stories / epics every week that will need a team meeting. Probably many questions will be answered in the comment section. Only if they can't the refinement meeting should happen. I will also add that sometimes the PM needs to be invited.
- To keep the group meetings minimal.
| **Weekly Sync** (Wednesdays, 30 min) | ||
|
|
||
| - Quick round: what's progressing, what's blocked, any decisions needed. | ||
| - Not a status report, Jira has that. This is for things that need a conversation. |
There was a problem hiding this comment.
Who's veriyfing that Jira has that? An element of a sync status update allows the team to keep each other honest on Jira hygiene
There was a problem hiding this comment.
I am so used to working with Jira for the last 10 years that I'm often absolutely blind to the fact that many never worked with it. Sorry for that.
Then I'd actually change the weekly sync a bit and add a Jira sanity check to it. Lets see how it works, I don't want it to take more that 30 min, shorter is better, most of the time 20 should be enough.
I'll add more details to this section. The facilitator role (the one which rotates) has the responsibility to sanity check Jira each weekly sync for each attendee:
- Is the story the engineer is working on assigned to him?
- Is the status of that story correct?
- PR added to story if there is one?
- status of "story in refinement" up to date?
- Questions/comments on the "story in refinement" answered?
- Does the story has the correct parent epic?
Would you add anything else?
If the weekly sync gets over 20 minutes regularly we're doing something wrong and need a change. For such discussions we'll have the retro.
| - Quick round: what's progressing, what's blocked, any decisions needed. | ||
| - Not a status report, Jira has that. This is for things that need a conversation. | ||
|
|
||
| **Optional Refinement Slot** (weekly, 45 min) |
There was a problem hiding this comment.
No. Sizing is to be done by the engineer who is refining the story.
developer-education/agile-workflow.md
Line 45 in 1170597
I don't see much value in group sizing. Sizing is inherently inaccurate even in your own expertise and now that we're being out our our expertise it'll be even more inaccurate. But I understand that the managements wants at least "some" estimate, so we'll do it but not in a group. I trust the judgement of my team mates.
There was a problem hiding this comment.
One value I've seen of group sizing, and of course YMMV, is that if you have multiple engineers who have different values for the size, the discussion about why their sizes are different often leads to clarification on scope. So we have had genuinely useful conversations out of "but I thought this was a 2, you thought 5, what did I miss"
| - 5 min break. | ||
| - Second half (30 min): what went well, what didn't, one thing to change next sprint. | ||
|
|
||
| **Rotation:** The team decides who facilitates. After every 2 sprints, rotate to the next person. |
There was a problem hiding this comment.
So with the new model we are expecting to have feature leads assigned as architects in the strat. That person is ultimately the "technical lead" (not scrum master, not product owner) for that feature.
Have you considered how those might be assigned/rotated? I'm thinking about how we provide equal opportunities for growth across the team
There was a problem hiding this comment.
That person is ultimately the "technical lead" (not scrum master, not product owner) for that feature.
Yes, there will be the "architect" and his "lieutenant". The architect owns, the lieutenant is his right hand and stand-in, he is the one who will be helping with the refinement of the OCPSTRAT.
Have you considered how those might be assigned/rotated? I'm thinking about how we provide equal opportunities for growth across the team
Yeah I thought about it, but it's not relevant now. Probably in a future release cycle we'd open the architect slot for rotation and encourage younger talent to get in to the lieutenant role or be the architect and get as lieutenant a principal engineer who helps. But we'll see. That's for later.
We first have to test drive this system and see how it works.
|
|
||
| **Process:** | ||
|
|
||
| 1. **PM Kickoff** (30-60 min, once per OCPSTRAT): |
There was a problem hiding this comment.
For context: it's my understanding that in principal:
- OCPSTRAT can span releases
- Epic can span sprints
- Story is <1 sprint
This is not always the reality, but if we followed guidance on splitting stories better perhaps it could be.
However, the point here is that OCPSTRAT entering the cycle has been fairly rare for me of late, and the scope has been large. Perhaps this will change, but it colours my comments.
There was a problem hiding this comment.
This is not always the reality, but if we followed guidance on splitting stories better perhaps it could be.
...and the scope has been large.
This will be up to us. We scope the stories that they can be finished in a sprint or a chunk of them which is behind a feature flag.
That's the plan at least.
| 2. **Async Breakdown**: The 2 engineers break the OCPSTRAT into epics and stories in Jira. | ||
| - **Epic**: A deliverable chunk of work. | ||
| - Goal | ||
| - Scope | ||
| - Mapping back to the OCPSTRAT | ||
| - Technical design (architecture decisions, component interactions, API contracts), done by the principal/architect engineers | ||
| - **Story**: Small enough for one engineer to finish in a few days to a week. | ||
| - Summary | ||
| - Scope | ||
| - Acceptance criteria | ||
| - T-shirt size estimate (S/M/L). Anything bigger than L, split it. | ||
| - Technical design (only if non-obvious), added by whoever picks up the story |
There was a problem hiding this comment.
My question is around how much should be refined up front.
I certainly think 'known' epics should be defined up front. Perhaps also given a 'finger in the air' estimate. I would argue a DoD is also necessary at this point, but a technical design is only nice to have. Creating the technical design for the CAPI installer was a couple of months of work, for example.
My concern is that looking back on every effort we ever made to entirely scope the CAPI work over the couple of years we've been working on it now has been wildly, hopelessly inaccurate. I suspect that the limit of what we can refine moderately usefully is close to the amount of work which is currently unblocked, or close to being unblocked. I think trying to refine an epic in any useful detail which requires the implementation of N prior non-trivial tasks is unlikely to be usable once you actually get to it, and you're going to have to do it again anyway.
If we said:
- All epics and stories must be created with a summary and a DoD
- Epics and stories which are currently implementable should be refined before planning
- Epics and stories which are not currently implementable are deferred for refinement until they are
Would that work?
There was a problem hiding this comment.
I certainly think 'known' epics should be defined up front. Perhaps also given a 'finger in the air' estimate.
I wouldn't estimate epics, only stories.
I would argue a DoD is also necessary at this point, but a technical design is only nice to have.
Good, I'll add a refinement DoD. I agree that technical design is a nice to have. I wrote (only if non-obvious):
developer-education/agile-workflow.md
Line 46 in 1170597
Creating the technical design for the CAPI installer was a couple of months of work, for example.
That's good to know and alright. For complex technical designs like for the CAPI we'll create a dedicated story (or stories) and/or spike.
My concern is that looking back on every effort we ever made to entirely scope the CAPI work over the couple of years we've been working on it now has been wildly, hopelessly inaccurate.
Exactly! That's why I usually don't estimate at all and if I have to then on the story level, never on epic level or higher. So that management has something for their plans.
We could additionally introduce a "scope change" during sprint if we notice that a story we're working on is much larger, which will happen for sure. Then we'd break it down, refine, re-estimate and put the new stories in the backlog.
I suspect that the limit of what we can refine moderately usefully is close to the amount of work which is currently unblocked, or close to being unblocked. I think trying to refine an epic in any useful detail which requires the implementation of N prior non-trivial tasks is unlikely to be usable once you actually get to it, and you're going to have to do it again anyway.
Yes. We won't refine what is blocked!
I'll put it into the refinement bullet list. I'll make a checklist of it.
There was a problem hiding this comment.
I wouldn't estimate epics, only stories.
T-shirt sizing for epics is an important part of the workflow for most of the PMs across core openshift. I would still expect engineers to t-shirt size epics to help PM understand the rough size of work under them. If you don't estimate their size, I can almost guarantee that a PM will ask you to do so. (We even used to call out the size on readouts, but maybe that'll change with pixaa)
|
@JoelSpeed @mdbooth Thanks for the feedback! I'll do some re-work and ping you. |
Restructure document into async ceremonies, sync ceremonies, and workflow sections. Add ToC, glossary, and future considerations. Key changes from team feedback: - Rename sprint to iteration - Introduce primary/secondary architect roles - Add epic and story definition of done - Reduce iteration planning to 20 min - Add Jira sanity check for facilitator - Clarify optional refinement slot rules - Add rule to not refine blocked work - Add facilitator and engineer checklists
Add iterative workflow description covering kickoff, OCPSTRAT breakdown, and the ongoing develop-and-refine cycle during iterations. Add architect refinement and facilitator duty checklists. Move rules under refinement process where they belong.
|
LGTM, but this is up to your pod to agree on and merge |
3 participants
Proposes a lightweight agile workflow for our team. Please review, comment, and ask questions directly on this PR.
What's in here:
This is a starting point. We'll iterate on it as we learn what works.