Full stack developer doing UX work?

[svarlet]

Hi,

Thanks for this great tool, I'm sure it will be useful in a training as these concepts are often not known, and incorrect old-fashion assumptions are still the norm.

Having tried it with numbers close to a previous team I managed, I wasn't sure what "fullstack" workers would do in your simulator. After looking at your tests, it seems a full stack worker will do everthing, UX included. In an ideal world, I suppose it's ok because we want to demonstrate the benefits of swarming. But before we get there, the team shown this simulation may find it unreal and could reject the demonstrated results. It would help if we could define a type of worker which can do some specific categories of work but not all. Like "full stack = dev + pull requests + ops".

Another example is when I tried to simulate the effect of code reviews / pull requests. I went for:

• ux: 5, dev: 8, pr: 2
• ux, dev, dev, dev, dev, pr, pr in an attempt to simulate that the devs would only review PRs some of the time. But this setup is doing something else: it's 3 full-time devs and 2 full time code reviewers, and 1/ I never had full time code reviewers, and 2/ it's not representing the undesirable switching and queuing effect of code reviews. If we could correctly simulate this, then I anticipate I would also like to simulate pair programming too: a constraint where stories can only be worked on by 2 devs. And also, if a story was pair programmed, then its PR time is 0.

What do you think?

[michelgrootjans]

Thank you for your comment. I'm thinking about this same concept.

I'm working on an extension where your example could be

• ux: 5, dev: 8, pr: 2
• ux, dev-pr, dev-pr, ...

This would mean that dev-pr can pick up dev and pr work. I would also add the constraint that the dev-pr worker is not allowed to do the pr on their own ticket.

Would that work for you?

[svarlet]

I’m excited!

Sébastien Varlet

On 2 Sep 2021, at 08:48, Michel Grootjans @.***> wrote:

 Thank you for your comment. I'm thinking about this same concept.

I'm working on an extension where your example could be

ux: 5, dev: 8, pr: 2 ux, dev-pr, dev-pr, , ... This would mean that dev-pr can pick up dev and pr work. I would also add the constraint that the dev-pr worker is not allowed to do the pr on their own ticket.

Would that work for you?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[michelgrootjans]

I just merged #22, thanks to @immortaleeb. It is now possible to give one worker multiple skills. The input for your scenario is now possible:

• ux: 5, dev:8, pr: 2
• ux, dev+pr, dev+pr

However, the workers can still do the pr on their own dev work. That will (probably) be for a next change.

[svarlet]

Have you deployed the release at the url shared in the README?

[michelgrootjans]

Yes, it's there

[svarlet]

However, the workers can still do the pr on their own dev work. That will (probably) be for a next change.

Indeed, that's not realistic enough to make the results relevant. Also, I think IRL, PRs tend to cause "rework" and I'd love to demonstrate the catastrophic effect of such a traditional workflow: ✅ dev A works on Story 1 for 5 days ✅ dev A creates a PR for Story 1 ✅ Story 1 waits 1.5 days for first reviewer B ✅ Reviewer B takes 0.5 day to complete the review 🔨 Reviewer B requests changes 🔨 Story 1 waits 3 days for dev A who is now busy with story 2 🔨 dev A takes 0.5 day to make the requested changes 🔨 dev A updates the PR 🔨 Reviewer B is now busy with another review (or story if he/she's a developer too) so Story 1 waits for.... ... and so on

NB.

• Some of the 🔨 items will become a ✅ when dev+pr excludes "dev does their own PR"
• Some of the 🔨 items are related to the loop(s) of rework: dev->pr->dev->pr->.....->pr
• There can be 1..n loops of rework per story, but I suppose we can't say "there will be 2 loops for all stories"
• Each loop of rework may vary in density: one may just be a little bit of formatting, while another loop could be a design overhaul, but I suppose we can't say "each loop costs 2 days"

[michelgrootjans]

This 'rework' is probably necessary for each step in the process: pr can cause dev rework, dev can cause ux rework, ...

How would you specify this in the current UI? An extra global input field %rework that would put items back in the previous process step?

[svarlet]

A global %rework sounds like rework is a probability and we know what this probability is. I'm not sure about that.

Also I would find it very valuable to allow multiple occurrences of rework per story. Not that it happens all the time, but I've often seen in my career a flow like dev->pr->dev->pr->dev->pr for a single story because first and then second pr requested changes. I believe that 2 occurrences of rework for a single story causes more queuing, and that your simulator will show it more if many occurrences of rework can happen (vs a higher probability of rework-once per story).

Thus I wonder, if rework can be simulated realistically with a single parameter? or do we need a pair such as "probability of rework per story per handoff" and "maximum number of rework occurrences per handoff".

What do you think?

[michelgrootjans]

I like the idea of adding rework to the simulation. I've been thinking about this combined with collaboration, which increases skill, which improves quality, which reduces rework as a virtuous cycle. You could also think about the reverse vicious cycle: workers are not skilled enough, causing errors that make it to production, causing bug tickets, causing extra items being queued, delaying the new features, swamping the original workers.

However, the main message I'm trying to convey with this simulation is limit your WIP and focus on queues. Every extra parameter or information added to the UI must support that message. I try to find a good balance between realism and understandability for non-techies.

For the rework proposal, I can't find that right balance. I can think of several alternatives:

• no change in the UI: sneak the rework probability in the simulation. I'm afraid I would introduce my own confirmation bias and limit the options to explore different scenario's.
• global %rework-parameter: as you pointed out, this is a very simplistic view of the system.
• average skill of workers-parameter: Lower than 100% increases the probability of rework. This might make it harder to understand the simulation.
• starting skill of workers-parameter. This opens the possibility to introduce learning by doing or by collaborating (pair-programming, swarming ...)

Right now, these ideas sound good, but I feel they're not ready to be implemented yet.

[svarlet]

However, the main message I'm trying to convey with this simulation is limit your WIP and focus on queues.

Thanks for sharing your intent.

After trying multiple simulator configurations matching past work situations, I felt that the simulator results were much nicer than the reality, to a point where I could not rely on it to demonstrate to a team that "rework causes longer queues".

There seem to be an interesting tension between your original objective and mine: in "X causes queuing and that queuing is undesirable", your X and my X differ but are not mutually exclusive. The tension might exist not in any specific X but in the audience targeted by this simulator. Effectively, by attempting to demonstrate both X in one simulator, we create a multidimensional problem that is much harder for a novice to grasp and use. Could the solution reside in creating another simulator where WIP is perfect in order to focus on the consequences of rework? a bit like lesson 1: WIP, lesson 2: rework?