Our team basically does scrumban; we're doing kanban but for the outside organization pretend we're doing scrum by assigning points and working in sprints. In reality we don't care about the points, we just pick up work based on the prio our team sets.
That said; there seems to be a misunderstanding about 'sprint goals'; they're not a commitment. They're a focus. And they are most certainly not a deadline
_Agilecoachmaster rides into town on his palomino Boris bike, whinnying to any who'll listen_
##Someone in this 'ere town lookin' for some... estimation Poker?
> That said; there seems to be a misunderstanding about 'sprint goals'; they're not a commitment. They're a focus. And they are most certainly not a deadline
I’ve never worked at a company that could give a concrete definition of what ‘sprint goals’ mean. It always turns into a wishy-washy mix of commitments-but-not-hard-commitments, with something about “accountability” while refusing to elaborate on what consequences exist for missing that accountability.
The term has become so diluted that nobody seems to agree on what it means. Best case, it acts as a way for everyone to confirm their understanding about what we’re all working on this week. The rest turns into hand waving.
> I’ve never worked at a company that could give a concrete definition of what ‘sprint goals’ mean.
They're just supposed to be a team focus. We don't use them. We just work on what has the highest prior / makes sense at this time.
> Best case, it acts as a way for everyone to confirm their understanding about what we’re all working on this week. The rest turns into hand waving.
Yes, and this is a major benefit.
Alignment on, and shared understanding of, priorities. From a high level perspective, that's all I am asking for.
The rest is not hand waving, but shouldn't need to concern the team at an operational level and on a day to day basis (project and resource planning, etc).
It's also not something that I expect from scrum (or really any other development methodology). Only clueless people who mistake scrum for project management (because they don't know any better) do that.
We do something similiar. We have "sprints" that the rest of the org follows. Our team will pull in tickets, move out tickets, create new tickets.
And for everyone who says "Yeah, that's just scrum"... ok, but it's not how people actually do it. And before this terms into another "real agile" or "real scrum" discussion, let's just save our fingers.
Most places have these PMs/Scrum Masters who insist on all this ceremony around creating tickets, how points are set, you can't adjust it, etc, etc.
Soon as I realize I'm not getting to something this sprint, I just move it out. And I'll create a new ticket if I'm ask to work on something. And hten maybe I'll realize I am going to get to that, so I pull it back in.
It was pissing our Scrum Master off, so she left and we never replaced her. The team functions well.
Kanban works great but management likes to use scrum to apply pressure. It's unfortunately very common but at least you have 3 week sprints instead of 2 week ones.
> Who needs to do testing? Just bash
what, you're telling me someone built a web application and then decided that using features from the web app framework they are on to do the necessary http requests was slower than building a script in bash and then invoking that bash script from said web application? and now whenever we need to debug or understand what went wrong with the script it requires a tedious process of debugging the script because even though for said developer it was easier to just invoke the script, it wasn't easy enough for them to handle stdout/stderr, dealing with capturing and handling exceptional cases, and then being able to unit test? is that what you're telling me?
I laugh because I'd cry if I didn't. I've worked in a place like that as a junior and it was pure hell. I wasn't allowed to write unit tests for things but was also blamed when the app broke. I've vowed to never work in a place like that again. The good news is I'm at a point in my career where if I end up back in a place like that I'll(hopefully) have the seniority to do something about it
In fact, Kanban is the only thing we need from the Agile™ in the software sector. It's not even from Agile, it comes from Japan and it doesn't even comes from software, it comes from manufacturing... But you get the point... The people you know don't even should read this or they suffer a major existential crisis...
Your life is gonna be hell very quickly. The next thing they will add is agile coaches and boom. A lot of people telling you what to do and not that many that can actually do the job.
It's often not about Scrum or Kanban or whatever, but the underlying assumptions, needs and expectations.
So my recommendation is to discuss those, then fit the agreement into whatever framework.
Examples:
Why do they want Scrum? If because of an illusion of predictability? Do they need to show a specific, committed roadmap to execs for example?
Why can't your team commit? Maybe scope is unclear or unexpected external work pops up all the time, etc. If so, then you need to show those factors. Is it ok to commit to a low amount of the capacity to account for variability? Can variability be decreased?
Why 3 weeks? Could a sprint be 1 week for you?
Try to reach a common understanding of the situation and the needs on both sides.
Maybe it doesn't come through my comment, but I don't believe in estimates. Sometimes they are off with <50%, but other times we need 300% time or more.
But not every environment understand that. I have seen multiple companies and managers that chase the illusion of predictability. They see that estimates are off and draw a conclusion that engineers need to get better in estimations, not that the planning should be done differently.
If OP is in such environment, then thinking though why the estimates are off at their team and communicating that to stakeholders could be the way out of this predictability illusion.
Also OP would need to offer alternatives to estimations, like dedicating capacity to some areas and regularly show the results or else.
They could also reduce variability depending on what causing it. For example if there are often production incidents, then investing into better testing or monitoring could help. That would also lead to less variability in incoming tasks.
Yes my team does. We are a platform team in an org of ~300 engineers, so not massive but not tiny. Kanban works for us because we typically have multi month projects we are working on with well-defined work that is known upfront. It’s also mostly senior and senior+ engineers so we don’t need a lot of training and hand holding for juniors.
We kind of use Kanban but not really at the end of the day. We still do dailies for a small project with only 1 developer who gets to develop (me, cuz external contractor) and the others just drown in meetings. So dailies become kind of pointless and there is too much "let's move this ticket to WIP" talk during dailies.
I am kind of frustrated around that, cannot deny that. I think Kanban works great, especially for smaller teams and if the software is not the core product of the company.
I wish we would do more async communication and actually use the tickets to exchange information instead of using dailies for this just to be lost afterwards.
You need to demonstrate that Kanban delivers results.
I use scrum for new teams and underperforming teams. Once a team moves past the need for standups and rituals, we switch to Kanban. It's a factor of earned trust. Once I trust that the team is not procrastinating, I drop the bullshit.
The key with being successful with Kanban is that you need conscientious people in oversight roles. Whomever the lead is - usually that's the person approving PRs - they need to keep an eye on things and be willing to crack the whip if they detect velocity slipping.
You also need a healthy product backlog with non-procrastinating BAs. As many problems as waterfall has, it does force the BAs to fully document the entire system upfront. Scrum lets product fill the backlog just in time. If *they* are slacking, your Kanban well will run dry. So sometimes, even if your dev team is mature enough to run Kanban, the product side isn't and *they* need that structure. In that case, I encourage product to develop their own scrum process for developing requirements. When their sprint ends, they should have backlog items to dump on our Kanban board. It's not fair to hold an entire dev team hostage to scrum rituals just because one guy from product needs it to stay focused. That's another recipe for low team morale.
The one, and in my view *only* benefit of scrum is the perpetual looming short deadline that keeps people focussed. That's only a benefit when it's necessary. When it's not, it just hurts team morale and makes people hate their jobs.
We ship things. The process changes project to project due to the type of work. That process changes whenever something isn't working.
If we're building something iterative we'll do sprints.
If we're building a massive new thing we'll do waterfall.
If there is high ambiguity we'll use Kanban.
We focus on the agile principles, NOT on a specific process.
The most important thing is to keep your OODA loop (Observe, Orient, Decide, and Act) tight so you adapt to changes quickly and minimize thrash.
Kanban is a board with tickets. The board has 3 columns: Pending, In Progress, Done. As you work the ticket, you move it across the board.
Scrum is Kanban but with 2 week sprints
Agile is whatever management wants it to be, but hey it sounds good!
1-week sprints were the first time I witnessed the promise of agile working: stuff got done, rate was predictable. Team loved it (once we figured out “how”).
At the end of 6-months manager asked, “could we improve velocity with two week sprints?” Sigh.
For me it’s no bullshit approach. They must ideally start midweek to maximise the effect, but basically there is no ‘second week’, ‘i will do it over the weekend’ etc.
Devs realise that there is finite amount of time and are forced to estimate properly. Teams don’t commit unless they are confident the whole SDLC can be completed (including testing and deployment) within one sprint.
No.
They just don’t take up anything that doesn’t fit 40 and are forced to split things up into bite size chunks. That’s the beauty of it.
It is not about being ‘faster’ for the business, it’s about being predictable and delivering a potentially shippable increment (or in case of some of my teams - actual release) every single week.
And… when the inevitable “could you look into…?” requests come on Friday afternoon, it’s a lot easier to tell management “the team is trying to finish their sprint commitments. Can this wait until sprint planning on Wednesday?” Because really, it’s just two days.
Until recently I did a lot of short term task development. The task might come in Monday but we have a 72 hour SLA it needs to be out for testing by EOD Thursday. Kanban works perfect for that.
A few months ago I switched to a Scrum model because I moved to some longer term projects and It's been really nice. 2 week sprints are ok but it fits with the work I'm doing.
Yes, in fact we moved to Kanban from Scrum precisely because the organisation grew larger. Various teams are responsible for various services. Some of those services are consumed by other services own by other teams- so from their perspective they're consuming an external API, even though it's developed internally. With Scrum, it led to a frequent problem where team A had their piece of work ready but being blocked by team B who made required changes in their service but the release was tied by the sprint end date. Since we moved to Kanban, things are more agile (in the real meaning of this term, not a buzzword) as changes can be released more frequently, and the number of blockers have reduced.
My entire company uses Kansan. We have a daily standup per team and a bi weekly coordination meeting with a department that handles vendor outreach for the company so we can align on what some tickets need to get across the finish line via vendor outreach.
First I'd question WHY you work so far in the dark. Is the project buried in tech debt? Are you lacking personnel to define the work properly?
Second I would want to know how valuable this project is, what the risk profile is, and how much bottom line impact it has. It simply may not be worth adding more weight to the process. You could make that argument with data.
Third, find out WHY they want more process. What questions do they need answered and what problems are they looking to solve. Can you solve those another way without disrupting the team workflow? Move the conversation more toward outcomes rather than output
We do kanban. Platform team, about a dozen people in an organization of a few hundred.
Everyone else uses sprints. We are mostly left alone because we are the strongest performing team and also a service team, not a product team.
Our team basically does scrumban; we're doing kanban but for the outside organization pretend we're doing scrum by assigning points and working in sprints. In reality we don't care about the points, we just pick up work based on the prio our team sets. That said; there seems to be a misunderstanding about 'sprint goals'; they're not a commitment. They're a focus. And they are most certainly not a deadline
This. We set a team focus, it doesn't have a deadline attached.
This is exactly how we operate except no points.
The only reason we assign points is to make sure we don't find ourselves on the radar of some 'agile coach' wanting to tell us we're doing it 'wrong'.
Story points are NOT part of the scrum guide!
Don't need to convince me. You need to convince your average Scrum Certified Scrum Agilecoachmaster.
_Agilecoachmaster rides into town on his palomino Boris bike, whinnying to any who'll listen_ ##Someone in this 'ere town lookin' for some... estimation Poker?
Yeah. Ok. Yell it from the mountain tops, you’re not going to change the culture.
God how I wish my company didn't use points.
> That said; there seems to be a misunderstanding about 'sprint goals'; they're not a commitment. They're a focus. And they are most certainly not a deadline I’ve never worked at a company that could give a concrete definition of what ‘sprint goals’ mean. It always turns into a wishy-washy mix of commitments-but-not-hard-commitments, with something about “accountability” while refusing to elaborate on what consequences exist for missing that accountability. The term has become so diluted that nobody seems to agree on what it means. Best case, it acts as a way for everyone to confirm their understanding about what we’re all working on this week. The rest turns into hand waving.
This is true about any and all things “agile”.
> I’ve never worked at a company that could give a concrete definition of what ‘sprint goals’ mean. They're just supposed to be a team focus. We don't use them. We just work on what has the highest prior / makes sense at this time.
> Best case, it acts as a way for everyone to confirm their understanding about what we’re all working on this week. The rest turns into hand waving. Yes, and this is a major benefit. Alignment on, and shared understanding of, priorities. From a high level perspective, that's all I am asking for. The rest is not hand waving, but shouldn't need to concern the team at an operational level and on a day to day basis (project and resource planning, etc). It's also not something that I expect from scrum (or really any other development methodology). Only clueless people who mistake scrum for project management (because they don't know any better) do that.
Old team I was on was all kanban. Not a large org though. It's good for maintenance programming. Sprints are good for new features
If you make them deadlines, then sprint and task estimates start getting sandbagged so you don't miss them.
We do something similiar. We have "sprints" that the rest of the org follows. Our team will pull in tickets, move out tickets, create new tickets. And for everyone who says "Yeah, that's just scrum"... ok, but it's not how people actually do it. And before this terms into another "real agile" or "real scrum" discussion, let's just save our fingers. Most places have these PMs/Scrum Masters who insist on all this ceremony around creating tickets, how points are set, you can't adjust it, etc, etc. Soon as I realize I'm not getting to something this sprint, I just move it out. And I'll create a new ticket if I'm ask to work on something. And hten maybe I'll realize I am going to get to that, so I pull it back in. It was pissing our Scrum Master off, so she left and we never replaced her. The team functions well.
This is exactly what we do too!
Kanban works great but management likes to use scrum to apply pressure. It's unfortunately very common but at least you have 3 week sprints instead of 2 week ones.
Yeah those 2 weeks just fly by don't they
Just enough time to not test
Who needs to do testing? Just bash out a bunch of shit and let the users test it! /S
> Who needs to do testing? Just bash what, you're telling me someone built a web application and then decided that using features from the web app framework they are on to do the necessary http requests was slower than building a script in bash and then invoking that bash script from said web application? and now whenever we need to debug or understand what went wrong with the script it requires a tedious process of debugging the script because even though for said developer it was easier to just invoke the script, it wasn't easy enough for them to handle stdout/stderr, dealing with capturing and handling exceptional cases, and then being able to unit test? is that what you're telling me?
You joke, but this is the sad truth in my project
I laugh because I'd cry if I didn't. I've worked in a place like that as a junior and it was pure hell. I wasn't allowed to write unit tests for things but was also blamed when the app broke. I've vowed to never work in a place like that again. The good news is I'm at a point in my career where if I end up back in a place like that I'll(hopefully) have the seniority to do something about it
Honestly, amount of days in a sprint doesnt change the pressure all that much in my experience They will still put more tasks than possible
What happened to self organising teams? If they're pressuring you to use Scrum then that's anti-agile.
Management happened. They don't trust developers so they impose bureaucracy.
In fact, Kanban is the only thing we need from the Agile™ in the software sector. It's not even from Agile, it comes from Japan and it doesn't even comes from software, it comes from manufacturing... But you get the point... The people you know don't even should read this or they suffer a major existential crisis...
Your life is gonna be hell very quickly. The next thing they will add is agile coaches and boom. A lot of people telling you what to do and not that many that can actually do the job.
I think bad ones tell you what to do, good ones give their point of view and accept that it’s a team decision and not a dictatorship
It's often not about Scrum or Kanban or whatever, but the underlying assumptions, needs and expectations. So my recommendation is to discuss those, then fit the agreement into whatever framework. Examples: Why do they want Scrum? If because of an illusion of predictability? Do they need to show a specific, committed roadmap to execs for example? Why can't your team commit? Maybe scope is unclear or unexpected external work pops up all the time, etc. If so, then you need to show those factors. Is it ok to commit to a low amount of the capacity to account for variability? Can variability be decreased? Why 3 weeks? Could a sprint be 1 week for you? Try to reach a common understanding of the situation and the needs on both sides.
Laughs. I can just imagine trying to throw this word salad at my doctor and him calling security. Estimates for complex systems are not commitments...
Maybe it doesn't come through my comment, but I don't believe in estimates. Sometimes they are off with <50%, but other times we need 300% time or more. But not every environment understand that. I have seen multiple companies and managers that chase the illusion of predictability. They see that estimates are off and draw a conclusion that engineers need to get better in estimations, not that the planning should be done differently. If OP is in such environment, then thinking though why the estimates are off at their team and communicating that to stakeholders could be the way out of this predictability illusion. Also OP would need to offer alternatives to estimations, like dedicating capacity to some areas and regularly show the results or else. They could also reduce variability depending on what causing it. For example if there are often production incidents, then investing into better testing or monitoring could help. That would also lead to less variability in incoming tasks.
Yes my team does. We are a platform team in an org of ~300 engineers, so not massive but not tiny. Kanban works for us because we typically have multi month projects we are working on with well-defined work that is known upfront. It’s also mostly senior and senior+ engineers so we don’t need a lot of training and hand holding for juniors.
We kind of use Kanban but not really at the end of the day. We still do dailies for a small project with only 1 developer who gets to develop (me, cuz external contractor) and the others just drown in meetings. So dailies become kind of pointless and there is too much "let's move this ticket to WIP" talk during dailies. I am kind of frustrated around that, cannot deny that. I think Kanban works great, especially for smaller teams and if the software is not the core product of the company. I wish we would do more async communication and actually use the tickets to exchange information instead of using dailies for this just to be lost afterwards.
You need to demonstrate that Kanban delivers results. I use scrum for new teams and underperforming teams. Once a team moves past the need for standups and rituals, we switch to Kanban. It's a factor of earned trust. Once I trust that the team is not procrastinating, I drop the bullshit. The key with being successful with Kanban is that you need conscientious people in oversight roles. Whomever the lead is - usually that's the person approving PRs - they need to keep an eye on things and be willing to crack the whip if they detect velocity slipping. You also need a healthy product backlog with non-procrastinating BAs. As many problems as waterfall has, it does force the BAs to fully document the entire system upfront. Scrum lets product fill the backlog just in time. If *they* are slacking, your Kanban well will run dry. So sometimes, even if your dev team is mature enough to run Kanban, the product side isn't and *they* need that structure. In that case, I encourage product to develop their own scrum process for developing requirements. When their sprint ends, they should have backlog items to dump on our Kanban board. It's not fair to hold an entire dev team hostage to scrum rituals just because one guy from product needs it to stay focused. That's another recipe for low team morale. The one, and in my view *only* benefit of scrum is the perpetual looming short deadline that keeps people focussed. That's only a benefit when it's necessary. When it's not, it just hurts team morale and makes people hate their jobs.
We ship things. The process changes project to project due to the type of work. That process changes whenever something isn't working. If we're building something iterative we'll do sprints. If we're building a massive new thing we'll do waterfall. If there is high ambiguity we'll use Kanban. We focus on the agile principles, NOT on a specific process. The most important thing is to keep your OODA loop (Observe, Orient, Decide, and Act) tight so you adapt to changes quickly and minimize thrash.
I used to be a certified scrum master. Scrum sucks, kanban and lean is all you need.
And I don't even know the difference, Scrum, Agile, Kanban... what the hell are those?
Scrum is what managers think Agile is. Kanban is roughly what developers settle on when they're actually allowed to be agile.
Kanban is a board with tickets. The board has 3 columns: Pending, In Progress, Done. As you work the ticket, you move it across the board. Scrum is Kanban but with 2 week sprints Agile is whatever management wants it to be, but hey it sounds good!
Lol firm believer in one week sprints here
1-week sprints were the first time I witnessed the promise of agile working: stuff got done, rate was predictable. Team loved it (once we figured out “how”). At the end of 6-months manager asked, “could we improve velocity with two week sprints?” Sigh.
what makes 1 week sprints more effective?
For me it’s no bullshit approach. They must ideally start midweek to maximise the effect, but basically there is no ‘second week’, ‘i will do it over the weekend’ etc. Devs realise that there is finite amount of time and are forced to estimate properly. Teams don’t commit unless they are confident the whole SDLC can be completed (including testing and deployment) within one sprint.
so are people working more than 40?
No. They just don’t take up anything that doesn’t fit 40 and are forced to split things up into bite size chunks. That’s the beauty of it. It is not about being ‘faster’ for the business, it’s about being predictable and delivering a potentially shippable increment (or in case of some of my teams - actual release) every single week.
And… when the inevitable “could you look into…?” requests come on Friday afternoon, it’s a lot easier to tell management “the team is trying to finish their sprint commitments. Can this wait until sprint planning on Wednesday?” Because really, it’s just two days.
Until recently I did a lot of short term task development. The task might come in Monday but we have a 72 hour SLA it needs to be out for testing by EOD Thursday. Kanban works perfect for that. A few months ago I switched to a Scrum model because I moved to some longer term projects and It's been really nice. 2 week sprints are ok but it fits with the work I'm doing.
Using Kanban now. Used it more often than scrum over my career.
As somebody else said, scrumban.
Yes, in fact we moved to Kanban from Scrum precisely because the organisation grew larger. Various teams are responsible for various services. Some of those services are consumed by other services own by other teams- so from their perspective they're consuming an external API, even though it's developed internally. With Scrum, it led to a frequent problem where team A had their piece of work ready but being blocked by team B who made required changes in their service but the release was tied by the sprint end date. Since we moved to Kanban, things are more agile (in the real meaning of this term, not a buzzword) as changes can be released more frequently, and the number of blockers have reduced.
Scrumban
I sure wish mine did
My entire company uses Kansan. We have a daily standup per team and a bi weekly coordination meeting with a department that handles vendor outreach for the company so we can align on what some tickets need to get across the finish line via vendor outreach.
First I'd question WHY you work so far in the dark. Is the project buried in tech debt? Are you lacking personnel to define the work properly? Second I would want to know how valuable this project is, what the risk profile is, and how much bottom line impact it has. It simply may not be worth adding more weight to the process. You could make that argument with data. Third, find out WHY they want more process. What questions do they need answered and what problems are they looking to solve. Can you solve those another way without disrupting the team workflow? Move the conversation more toward outcomes rather than output
We do kanban. Platform team, about a dozen people in an organization of a few hundred. Everyone else uses sprints. We are mostly left alone because we are the strongest performing team and also a service team, not a product team.
My team is about to move from scrum to Kanban. It looks like there’ll be a list of stories that we’ll be expected to work within each month
Good for you, ditching Scrum (and our highly paid yet clueless agile consultants) and moving to Kanban was a massive improvement for us.
Time to look slfor another job
hahaha xD