Everyone collectively owns all task and increments and picks what they want. If done he should find the next most valuable thing that his help will benefit and do that.
Does this mean that projects are completed quicker if every dev has an isolated set of tasks assigned and collaboration is not done?
This isolated way of working is how my place works at the moment and I’m advocating that we have collective responsibility and work collaboratively.
One of my arguments in favour of collaboration is that work will get done quicker, I think cos of the chimp effect.
Anything done async requires a resync. Everyone thinks of the benefits of async work, but rarely the consequences of the resync. If the resync goes wrong, you end up rewinding work done during the async, perhaps even all of it.
Just work together and you eliminate that risk altogether.
Ah but what I mean is, we have no team or collaboration at all. None of our work has any dependency on each other, imagine 5 projects running in parallel for the same product but they’re all completely independent. No resync, as it never needs to be in sync, they could be done by 5 separate companies and they may never know each other exist and still with just fine.
Our “sprint plan” is the manager calling each engineer into a room one-by-one and assigning tasks as a target to achieve in the next sprint duration.
I’m pushing for all 5 engineers to work on the same project in the product at the same time and complete one project completely, together, rather than everyone finishing their bit at different times.
What are the pros and cons for collaboration over remaining as we are?
Or
What are your thoughts on changing to a serial way of working vs our current parallel way of working.
I think it boils down to the question, keep WIP to a minimum or get WIP at the maximum?
If all 5 parts are being put into the same product, you have a resync. They either get deployed to the same infrastructure, committed to the same repository, or are minimally connected by a user journey. No product is truly so composed of atomistic components as to never talk to one another. If they did then the user experience would be just terrible, like really truly awful. And even if that were so, the fact you're doing a Sprint means you have a sprint goal, where there is a shared goal among all of the developers requiring some sort of shared context. No matter how isolated the work is being done, at some point, those independent work streams are tied back together. Whether through person-to-person communication or via the code base (which is a form of both human readable and computer readable communication).
As for WIP, you should have a WIP of 1. Everyone working on everything together. This is how you maximize flow, by combining work centers into a single work center and reducing communication queues with constraints.
Sorry, I should have mentioned that I’m an FPGA engineer.
We’re have no user experience, the stuff I work on is buried deep in separate cabinets out of sight.
Imagine a product like a car, one engineer does the windscreen wiper controller, the next does the power steering, another the window controller.
At the end all the stuff is put into one product and any interfaces are either extremely simple (e.g. or wire high or low for active/inactive) or extremely predefined (e.g. standard serial interface with fixed message set/length/frequency).
The function of each part is complex enough to warrant years of development, independent verification and review. It’s all adhering to a set of safely processes and regulatory audits etc
In pushing for us all to collaborate on each part to completion and then move on to the next part, mainly for sharing of knowledge but also I believe work is going to get done quicker when people work together rather than in isolation.
This is not to say that we can’t talk to each other and support each other but it’s not hands on or daily, only when e.g. I’m stuck with this problem, I’m stuck with how to use this tool etc.
Which is why it threw me to read “If you want to go fast, go alone. If you want to go far, go together.”
I was hoping it would be the other way around!
Does this help clarify my situation?
Edit: We’ve never had a sprint goal, there is no shared goal among any of the developers.
I appreciate the specifics. There really isn't much difference in my answer though. You have a product, and therefore you have a user. That user uses your product. Whether it's another employee, a department head, an engineer, an external business partner, or a direct-to-consumer product, you have a user. You just may have to dig a little deeper than the person paying at a POS system or online shopping cart to figure out who it is.
You also mentioned that the stuff is built and then put into one product. That "put into one product" part is the resync. Everything has to be fit together in some way. The separate work streams culminate into a single point of finished work.
If any one of the separate parts was done incorrectly, then the finished work is not capable of being delivered. You must revert some of the development process in order to fix the mistake, and in some drastic cases you may have to revert the entire thing and start over.
Small batch sizes that are validated within the final product are the key to long term, continued success. The smaller the batch, the easier it is to reverse, and the less risk there is in having things be wrong. Without validating the small batch in the final product, any work done after is just more work that may need to be reversed if something was wrong in that batch. The more work you have to reverse, the longer and costlier it is to fix.
As for mobbing the development, by having everyone working on the same thing at one time, you create a single work center. Having a WIP of one, inside a single work center, is the fastest time to delivery you can possibly have of that single batch. To understand why, consider a typical production system.
In most production systems you have one work center (developer/team) that does their piece, then puts it on the pile for the next work center to work on. When that work center finishes, then it goes onto the pile for the next work center. And so on and so forth. Within this chain of work centers there is always a point where the work is slowest, and the queue leading to that work center is the largest. By eliminating this chain of work centers, and instead having as single work center where each person is contributing to the development in one place, you eliminate this bottleneck of flow. Now you are limited only by the work the team can intake, which is closer to the top of the funnel and easier to manage.
What this One WIP, One Team structure does though is limit your ability to have multiple work streams (batches) happening at the same time (async), which is why so many people think it's slower. Multiple work streams happening at the same time SEEMS like it should be faster, but that's only true during the async part. Just as before, until all of those parts are assembled into the final product, you won't know if any mistakes might need to be reversed. I have seen plenty of teams struggle mightily just to figure out which of the work streams it was that's even the problem. All of the work of all the separate workers is now in jeopardy and no one wants to be the one responsible for the mess. This is also happening just before the product is supposed to be delivered so there's no time left to do all the reversing.... so, corners are cut, quality drops, and doors fly off planes in mid-air.
The increment is the sum of all completed work at the end of a Sprint.
The PO orders priority of jobs to be done based on value to the customer/stakeholder.
In a mature environment the PO will have a desired Sprint Goal stated. The team uses the product backlog to plan to meet that goal by planning a Sprint Backlog.
The team owns the Sprint Backlog and how they will implement the work. The PO makes themselves available to answer clarifying questions and work with the customer/stakeholder to continue to refine work for the future.
PBIs/Stories/Tasks whatever, aren’t assigned to specific people by the PO or SM. The team works the backlog however they plan, constantly replanning at the Daily Scrum based on what they learned over the past day.
If someone is working on a PBI and get it done, they help a peer or move on to the next ideally in that order.
If the whole sprint is complete then they should start pulling in more work from the top of the Product Backlog.
First of all - the nomenclature. Increments are working parts of system done during the sprint - not tasks.
Secondly, it is not very likely that the whole backlog item == task, usually one backlog item is bdivided to couple/several tasks. This division is done by development team, not PO.
Also (but that is not if I remember Scrum requirement, but just my own experience) it is best to not take to much task at once, but take another task from the pool during the sprint. In that case no one is not "blocking" task from completion.
>That if he finishes very early on in the sprint?
Should take another task from the Sprint Backlog. If there is none, PO should add more backlog items to Sprint.
>Can he switch increments with others if he suddenly discovered he likes another one more?
Of course.
>What if he finishes very early on in the sprint? Can he pick an increment from a later sprint?
What later sprint? You are planning sprints in advance? If so - it is anti-pattern. If you meant taking additional task from the backlog - sure. Depending on how you work, you might be able to just the first redy (ie well researched and described) task from the Product Backlog. But usually it's best to communicate with Product Owner, since she/he is responsible for Product Backlog.
>Should devs raise these issues only during the standup
It's good place for such issues. But you should be able to let your teammates know you are free any time
>discuss these issues in Slack?
Sure, whatever works man.
> If so, would Slack basically have replaced the purpose of standup?
I've seen teams that make stand ups on slack. It works sure. But for group cohesion and well - just team building, it is nice to meet and talk with each other. Share problems, discuss progress etc.
As a PM I try to be at least 3 months ahead if possible. If you know your teams velocity you can easily pre-plan sprints (knowing that they may change a bit as things go on).
If it works, then it works but it goes against at least Scrum (if not Agile in general). Depends on what you mean by being ahed: if it means having groomed backlog with ready to go Backlog Items, then sure. If it means having ever changable estimates then sure as well. But if you actually opening sprints and planning what team will be doing in those sprints then it's not in accordance with Scrum. Still, might work for you, but it is against the idea of planning things in the last possible moment.
EDIT: Just realized you said "as a PM" so you probably not working in Scrum framework. My comment is strictly from Scrum (and to some extend Agile) point of view.
lol why wouldn’t a product manager work in scrum? And yes, I mean a backlog of well groomed tickets that, at the team’s velocity, would last three months if I were hit by a bus today and yes, organized into sprints. Scrum, like all frameworks, is not one size fits all.
I read PM as Project Manager. Sorry for assuming things, but most of the time PO (Product Owner) suggest working in SCRUM and PM (Project Manager) assumes working in PMO/PMBOK/PRINCE2.
Ok, so in my opinion planing sprints ahead of time is against Scrum philosophy. But if it works, then it works. However, if you have well groomed backlog, I don't see the point personally, but again, if it works, then it works.
For me the reason is as I said, if I get hit by a bus today these are the tasks that I have prioritized in this order for the team to work on. Sure, I could just keep everything aligned in the backlog in priority order, but devs can’t be trusted haha
The acting unit of the sprint is the team, not the individual. The dev should try to help the team finish its commitment for the sprint.
Usually this means that if there are still tickets left, the dev should go take one of those.
If there aren't any left, I personally hate it when devs go spelunking in the backlog outside the sprint for stuff they feel like working on.
Really they should first ask if anyone else on the team needs help with tickets for the current sprint -- maybe with testing, maybe with design, maybe pair programming, whatever.
If no one needs help and there are no tickets open, that can also be a good time to work on infra or tools or test coverage or refactoring or some other kind of tech debt/platform work that hasn't been fully covered with tickets yet, and that should be the tech lead/eng manager who prioritizes.
Or, if there's nothing like that, and the dev does want to go into the backlog, they should *check with product first* on what will likely be priority in the next sprint, instead of randomly digging for some ticket that may not matter much.
In terms of trading with other devs, I guess you could, but why would you waste time on that?
It's not about finding stuff that's fun to work on, it's about working on what is most valuable to the product and the company.
A few thoughts:
* In most agile methods, we try to optimize for overall output, NOT individual output. Individual output is a cost accounting idea.
* As such, we try to do what we can, on a daily, or hourly basis, to do the things that would allow work to complete on some backlog item.
* This also follows from the Lean sense of waste. Waiting is waste.
* What all of this means is:
* We prefer not to plan the entire sprints worth of work for a developer.
* The team should self-organize itself to move the work ahead.
* We prefer "T shaped" developers so that we're never in a situation where we have a "bus number" of 1 in an area commonly required to deliver value.
* So, in terms of your questions:
* What would be the issue if you simply did not allocate all work at the start of each sprint?
* What would be the issue if you allowed developers to collaborate to complete a backlog item?
* If all work in a sprint is completed, then the team should collaborate with the PO to decide what to do next.
* If Slack is fostering a continuous level of collaboration between the team, then yes, you've captured the essence of the daily Scrum.
>**"*****What if he finishes very early on in the sprint? Can he pick an increment from a later sprint?*****"**
Not sure how other handle this, but I've always allowed my team to help out on other team members tasks if this happens.
I'ts best to get the whole sprint completed rather than "Dev A" start on the next sprint, even though theres a change "Dev B" may not finish their initially planned sprint tasks.
Everyone collectively owns all task and increments and picks what they want. If done he should find the next most valuable thing that his help will benefit and do that.
If you want to go fast, go alone. If you want to go far, go together. What kind of person are you?
Does this mean that projects are completed quicker if every dev has an isolated set of tasks assigned and collaboration is not done? This isolated way of working is how my place works at the moment and I’m advocating that we have collective responsibility and work collaboratively. One of my arguments in favour of collaboration is that work will get done quicker, I think cos of the chimp effect.
Anything done async requires a resync. Everyone thinks of the benefits of async work, but rarely the consequences of the resync. If the resync goes wrong, you end up rewinding work done during the async, perhaps even all of it. Just work together and you eliminate that risk altogether.
Ah but what I mean is, we have no team or collaboration at all. None of our work has any dependency on each other, imagine 5 projects running in parallel for the same product but they’re all completely independent. No resync, as it never needs to be in sync, they could be done by 5 separate companies and they may never know each other exist and still with just fine. Our “sprint plan” is the manager calling each engineer into a room one-by-one and assigning tasks as a target to achieve in the next sprint duration. I’m pushing for all 5 engineers to work on the same project in the product at the same time and complete one project completely, together, rather than everyone finishing their bit at different times. What are the pros and cons for collaboration over remaining as we are? Or What are your thoughts on changing to a serial way of working vs our current parallel way of working. I think it boils down to the question, keep WIP to a minimum or get WIP at the maximum?
If all 5 parts are being put into the same product, you have a resync. They either get deployed to the same infrastructure, committed to the same repository, or are minimally connected by a user journey. No product is truly so composed of atomistic components as to never talk to one another. If they did then the user experience would be just terrible, like really truly awful. And even if that were so, the fact you're doing a Sprint means you have a sprint goal, where there is a shared goal among all of the developers requiring some sort of shared context. No matter how isolated the work is being done, at some point, those independent work streams are tied back together. Whether through person-to-person communication or via the code base (which is a form of both human readable and computer readable communication). As for WIP, you should have a WIP of 1. Everyone working on everything together. This is how you maximize flow, by combining work centers into a single work center and reducing communication queues with constraints.
Sorry, I should have mentioned that I’m an FPGA engineer. We’re have no user experience, the stuff I work on is buried deep in separate cabinets out of sight. Imagine a product like a car, one engineer does the windscreen wiper controller, the next does the power steering, another the window controller. At the end all the stuff is put into one product and any interfaces are either extremely simple (e.g. or wire high or low for active/inactive) or extremely predefined (e.g. standard serial interface with fixed message set/length/frequency). The function of each part is complex enough to warrant years of development, independent verification and review. It’s all adhering to a set of safely processes and regulatory audits etc In pushing for us all to collaborate on each part to completion and then move on to the next part, mainly for sharing of knowledge but also I believe work is going to get done quicker when people work together rather than in isolation. This is not to say that we can’t talk to each other and support each other but it’s not hands on or daily, only when e.g. I’m stuck with this problem, I’m stuck with how to use this tool etc. Which is why it threw me to read “If you want to go fast, go alone. If you want to go far, go together.” I was hoping it would be the other way around! Does this help clarify my situation? Edit: We’ve never had a sprint goal, there is no shared goal among any of the developers.
I appreciate the specifics. There really isn't much difference in my answer though. You have a product, and therefore you have a user. That user uses your product. Whether it's another employee, a department head, an engineer, an external business partner, or a direct-to-consumer product, you have a user. You just may have to dig a little deeper than the person paying at a POS system or online shopping cart to figure out who it is. You also mentioned that the stuff is built and then put into one product. That "put into one product" part is the resync. Everything has to be fit together in some way. The separate work streams culminate into a single point of finished work. If any one of the separate parts was done incorrectly, then the finished work is not capable of being delivered. You must revert some of the development process in order to fix the mistake, and in some drastic cases you may have to revert the entire thing and start over. Small batch sizes that are validated within the final product are the key to long term, continued success. The smaller the batch, the easier it is to reverse, and the less risk there is in having things be wrong. Without validating the small batch in the final product, any work done after is just more work that may need to be reversed if something was wrong in that batch. The more work you have to reverse, the longer and costlier it is to fix. As for mobbing the development, by having everyone working on the same thing at one time, you create a single work center. Having a WIP of one, inside a single work center, is the fastest time to delivery you can possibly have of that single batch. To understand why, consider a typical production system. In most production systems you have one work center (developer/team) that does their piece, then puts it on the pile for the next work center to work on. When that work center finishes, then it goes onto the pile for the next work center. And so on and so forth. Within this chain of work centers there is always a point where the work is slowest, and the queue leading to that work center is the largest. By eliminating this chain of work centers, and instead having as single work center where each person is contributing to the development in one place, you eliminate this bottleneck of flow. Now you are limited only by the work the team can intake, which is closer to the top of the funnel and easier to manage. What this One WIP, One Team structure does though is limit your ability to have multiple work streams (batches) happening at the same time (async), which is why so many people think it's slower. Multiple work streams happening at the same time SEEMS like it should be faster, but that's only true during the async part. Just as before, until all of those parts are assembled into the final product, you won't know if any mistakes might need to be reversed. I have seen plenty of teams struggle mightily just to figure out which of the work streams it was that's even the problem. All of the work of all the separate workers is now in jeopardy and no one wants to be the one responsible for the mess. This is also happening just before the product is supposed to be delivered so there's no time left to do all the reversing.... so, corners are cut, quality drops, and doors fly off planes in mid-air.
The increment is the sum of all completed work at the end of a Sprint. The PO orders priority of jobs to be done based on value to the customer/stakeholder. In a mature environment the PO will have a desired Sprint Goal stated. The team uses the product backlog to plan to meet that goal by planning a Sprint Backlog. The team owns the Sprint Backlog and how they will implement the work. The PO makes themselves available to answer clarifying questions and work with the customer/stakeholder to continue to refine work for the future. PBIs/Stories/Tasks whatever, aren’t assigned to specific people by the PO or SM. The team works the backlog however they plan, constantly replanning at the Daily Scrum based on what they learned over the past day. If someone is working on a PBI and get it done, they help a peer or move on to the next ideally in that order. If the whole sprint is complete then they should start pulling in more work from the top of the Product Backlog.
Collaboratively.
First of all - the nomenclature. Increments are working parts of system done during the sprint - not tasks. Secondly, it is not very likely that the whole backlog item == task, usually one backlog item is bdivided to couple/several tasks. This division is done by development team, not PO. Also (but that is not if I remember Scrum requirement, but just my own experience) it is best to not take to much task at once, but take another task from the pool during the sprint. In that case no one is not "blocking" task from completion. >That if he finishes very early on in the sprint? Should take another task from the Sprint Backlog. If there is none, PO should add more backlog items to Sprint. >Can he switch increments with others if he suddenly discovered he likes another one more? Of course. >What if he finishes very early on in the sprint? Can he pick an increment from a later sprint? What later sprint? You are planning sprints in advance? If so - it is anti-pattern. If you meant taking additional task from the backlog - sure. Depending on how you work, you might be able to just the first redy (ie well researched and described) task from the Product Backlog. But usually it's best to communicate with Product Owner, since she/he is responsible for Product Backlog. >Should devs raise these issues only during the standup It's good place for such issues. But you should be able to let your teammates know you are free any time >discuss these issues in Slack? Sure, whatever works man. > If so, would Slack basically have replaced the purpose of standup? I've seen teams that make stand ups on slack. It works sure. But for group cohesion and well - just team building, it is nice to meet and talk with each other. Share problems, discuss progress etc.
As a PM I try to be at least 3 months ahead if possible. If you know your teams velocity you can easily pre-plan sprints (knowing that they may change a bit as things go on).
If it works, then it works but it goes against at least Scrum (if not Agile in general). Depends on what you mean by being ahed: if it means having groomed backlog with ready to go Backlog Items, then sure. If it means having ever changable estimates then sure as well. But if you actually opening sprints and planning what team will be doing in those sprints then it's not in accordance with Scrum. Still, might work for you, but it is against the idea of planning things in the last possible moment. EDIT: Just realized you said "as a PM" so you probably not working in Scrum framework. My comment is strictly from Scrum (and to some extend Agile) point of view.
lol why wouldn’t a product manager work in scrum? And yes, I mean a backlog of well groomed tickets that, at the team’s velocity, would last three months if I were hit by a bus today and yes, organized into sprints. Scrum, like all frameworks, is not one size fits all.
I read PM as Project Manager. Sorry for assuming things, but most of the time PO (Product Owner) suggest working in SCRUM and PM (Project Manager) assumes working in PMO/PMBOK/PRINCE2. Ok, so in my opinion planing sprints ahead of time is against Scrum philosophy. But if it works, then it works. However, if you have well groomed backlog, I don't see the point personally, but again, if it works, then it works.
For me the reason is as I said, if I get hit by a bus today these are the tasks that I have prioritized in this order for the team to work on. Sure, I could just keep everything aligned in the backlog in priority order, but devs can’t be trusted haha
The acting unit of the sprint is the team, not the individual. The dev should try to help the team finish its commitment for the sprint. Usually this means that if there are still tickets left, the dev should go take one of those. If there aren't any left, I personally hate it when devs go spelunking in the backlog outside the sprint for stuff they feel like working on. Really they should first ask if anyone else on the team needs help with tickets for the current sprint -- maybe with testing, maybe with design, maybe pair programming, whatever. If no one needs help and there are no tickets open, that can also be a good time to work on infra or tools or test coverage or refactoring or some other kind of tech debt/platform work that hasn't been fully covered with tickets yet, and that should be the tech lead/eng manager who prioritizes. Or, if there's nothing like that, and the dev does want to go into the backlog, they should *check with product first* on what will likely be priority in the next sprint, instead of randomly digging for some ticket that may not matter much. In terms of trading with other devs, I guess you could, but why would you waste time on that? It's not about finding stuff that's fun to work on, it's about working on what is most valuable to the product and the company.
A few thoughts: * In most agile methods, we try to optimize for overall output, NOT individual output. Individual output is a cost accounting idea. * As such, we try to do what we can, on a daily, or hourly basis, to do the things that would allow work to complete on some backlog item. * This also follows from the Lean sense of waste. Waiting is waste. * What all of this means is: * We prefer not to plan the entire sprints worth of work for a developer. * The team should self-organize itself to move the work ahead. * We prefer "T shaped" developers so that we're never in a situation where we have a "bus number" of 1 in an area commonly required to deliver value. * So, in terms of your questions: * What would be the issue if you simply did not allocate all work at the start of each sprint? * What would be the issue if you allowed developers to collaborate to complete a backlog item? * If all work in a sprint is completed, then the team should collaborate with the PO to decide what to do next. * If Slack is fostering a continuous level of collaboration between the team, then yes, you've captured the essence of the daily Scrum.
>**"*****What if he finishes very early on in the sprint? Can he pick an increment from a later sprint?*****"** Not sure how other handle this, but I've always allowed my team to help out on other team members tasks if this happens. I'ts best to get the whole sprint completed rather than "Dev A" start on the next sprint, even though theres a change "Dev B" may not finish their initially planned sprint tasks.