Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized.
Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared.
Once, just once, I was lucky enough to work on a team that switched from Kanban to Scrum, and then, mercifully, blissfully, back again. To be fair, I think we actually worked quicker after the return, though I don't know if that could be attributed to having actually learned some lessons from Scrum, or out of a fear that we'd one day return to it.
I think the "problem" is that Scrum orients more to the needs of people outside the team. So, (in theory) you get clearer reporting and more visibility into whats going on. People expect that extra reporting to be free, but its not free. The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming.
The sad truth is that most management teams would prefer their employees to be predictable and observable (ie, under control) than be efficient. Especially if nobody can actually quantitatively measure the loss of efficiency.
I agree. In my experience that outside visibility is mostly a mirage.
Velocity metrics, burndown charts, point estimations, and all of that have been at best aspirational white lies and at worst outright falsehoods on almost every scrum/agile team I've ever worked on in the past fifteen years.
In actuality many scrum teams are doing something closer to kanban day-to-day under the fake veneer of scrum/agile sprints on top to satisfy management and/or external parties.
>The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming.
Agree with everything _expect_ retros.
I think the value of the retros is proportional to how senior the team is and to how seasoned managers are. But for me retros are extremely high value _if_ you have:
- Teams that can look at problems head on and be civil addressing things without making it personal.
- Managers that have a 'clear roadblocks' mindset and have a service-providing mindset towards the team.
In this scenario you can really have high value retros, with continuous adjustments to workflow, processes, design, without continuously repeating the same mistakes or falling in the same pitfalls.
The problem is even scrum doesn't give the predictability and observability better than kanban. It's extremely hard to predict what we need to do in next 2 weeks and what we can achieve in next 2 weeks. At my current company, half, if not more, of the tickets come in mid-sprint.
So even though the current company is using scrum, in my team I treat it as kanban with story point limited, meaning I start with a certain amount of story points, then add / remove as the sprint is going.
For the purposes of understanding the way people act, it is important to focus on what they believe to be the truth, not what the truth is.
Software development is incredibly opaque by default (heck, even we don't know how far along we are, most of the time) so anything that improves that will be perceived as improved productivity.
But even if it's not, sometimes progress reporting (however rough) is needed to synchronise with other parts of the organisation. It just needs to be put into a form that is useful (e.g. for agile projects "percent of plan delivered" is not a useful metric) and how it's going to be used should be explained to those producing it. Heck, optimal is if the people making software and the people they need to coordinate with can get together and jointly agree on what type of reporting is actually meaningful for both parties.
Almost always, we're discussing vanity metrics though.
I don't see retrospectives being that much of a time-sink, it's a 30min/1hr meeting every 2 weeks. Even when I was on a kanban team they still had a fortnightly retrospective, it's useful to have a checkup occasionally.
This is just doing scrum badly... management break it by insisting the metrics etc are used as a reporting mechanism, they just cannot get away from "intensive control mode". The metrics are supposed to be for the team to use internally.
But I do agree with the post - Kanban is way way better and you can include the scrum continuous improvement elements as well on a regular cycle.
> most management teams would prefer their employees to be predictable and observable (ie, under control) than be efficient.
we're in this exact phase - sacrificing efficiency, team morale and independence to make the boards look cleaner to "raise the bar" per se.
We're a small efficient team in a massive org. Manager does a great job of not making stupid decisions, values people's time and is clear about the metrics the team gets evaluated on.
somewhere along the way he's, missed the reality that clean user stories and tasks, complete with points down to hours and acceptance criteria can still be completely f$#king wrong compared to the actual work that needs to be done. Not because the people are idiots but because thats how most software work is. You find out when you actually start working on it.
But if you mandate that you need a well cut plan before code gets written, you mostly get well written $hit.
We just embarked on this journey which I can mostly predict the outcome of.
Having predictability and observability is key to a business though, as higher level decision need to be made based on progress of the lower level teams.
I've seen many people complain about reviews and retrospectives in those threads... But they don't seem like a bad thing to me. The problem is if the sprint is too short. But if the review and retro are done e.g. once every month or so, it can be a good way to see what the other teams have been doing and get an overall picture of your software. And the retro can be a good opportunity to talk about any problems that you encountered, and maybe trigger a solution, or at least just vent about it.
I think I'd pick any team, not just software, telling me when something will exist over them saying they're more efficient. Efficient isn't even a metric I'd understand in most cases, e.g. a plumber telling me the house will be done as efficiently as possible but I won't know when any particular room will be unavailable so I can't plan around that info.
But velocity of code written is not the same as velocity of value delivered.
In Scrum, estimation meetings usually result in follow-ups with stakeholders that can (and often do) radically change the stories themselves. Totally different code winds up getting delivered that increases actual value delivered, even if "lines of code written" slows.
That's the whole point of agile, to deliver value rather than code.
To be honest I have never seen this materialize. Usually you get some input from product management, the devs estimate it and then do it. I have never seen feedback from estimation to requirements.
I did scrum once and we were literally always sprinting. The daily standup consisted of trying to think of excuses why the multiweek task wasn't completed (like they expected) and one dude who "zereo'd his inbox" every day.
That the iteration unit of scrum/agile is called a sprint is a huuuuge pet peeve of mine. Sprinting is definitionally an unsustainable pace.
I know, I know, it's just a label applied to the cycle time of the process but labels matter and I think it subtly and subconsciously poisons the whole thing. Especially when managers and PMs start making sprint cycles into hard deadlines.
I think one key issue here is that Scrum without Extreme Programming and rigorous iteration can become a shallow process. Often, products that don't undergo much iteration are broken into arbitrary two-week windows under the guise of iteration.
However, Scrum doesn't make much sense if you don't continuously iterate. Another symptom of this is people measuring velocity instead of value created. To properly implement Scrum, you actually need to measure the impact of the work completed in the past two weeks. Unfortunately, most teams don't do this, instead they focus on measuring velocity since it's easier and within their control. It's worth noting that it's completely fine for teams not to constantly iterate and change direction (including high-performing teams), and in those cases, Scrum simply isn't the best tool for the job imo.
I must admit that I personally prefer Kanban for almost all workloads.
If I am being generous, Scrum is for service teams, which can benefit from some of Scrum to temper unreasonable requests of senior stakeholders by providing a social contract on what is going to be worked on. More autonomous teams don't need it.
I’ve always considered Kanban’s lack of sprints to be well suited to service teams where individual requests are not naturally tied to each other and there is no benefit of delaying delivery into sprints.
> Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized.
This has been my experience. I've seen more than once management teams happier with numbers and estimates that weren't met than actually getting software out quicker at an unanticipated rate.
They'd rather have estimates that they could yell about than revenue generating software through (presumably) happy customers. <shrug>
I have the software engineering uncertainty principle. The more you try to measure and estimate and predict software velocity and delivery the more you slow it down. I think this is probably true of any largely creative and problem solving task, but compounds because most of the uncertainty derives from dependencies requiring those dependencies to likewise measure and slow down. The more complex and interconnected an effort is the more scrum hurts it.
This sounds a lot like the coastline paradox. The more precisely you try to measure a coastline, the harder it gets due to its fractal nature.
Software estimation, similarly, is fractal in nature - you can always drill down deeper to measure but it gets increasingly complex and at some point you have to ask, is it worth it being "accurate"? Or do we just do it? Org charts require the former while developers desire the latter.
As a Product Owner I am biased, but sympathetic. The ceremonies and oversight certainly can slow down velocity. But there are many benefits, and they are not immediately apparent to developers.
Alignment is so important, and it's rare that I've found a team not using scrum which is working harmoniously. In reality, some members of the team aren't pulling their weight and it's causing animosity. Or they're working at odds and not communicating the pieces they're developing. A huge one for me is stakeholder alignment. Without scrum it's awfully common for developers to build things the stakeholder doesn't want. Scrum forces regular check-in and demonstration which otherwise rarely happens organically.
A big part of scrum is accountability. As I touched on, when people aren't pulling their weight, it hurts everyone. Unfortunately developers are rarely extroverts, and they often don't have the skills or desire to have tough conversations with each other. Sometimes it's just agreeing on what they find acceptable behaviour and work. Sometimes it's adapting to different ways of work, or neurological issues with a team member. You might be surprised to learn that a lot of developers are on the spectrum. Scrum forces these conversations to the fore and provides a tested framework for conflict resolution.
We also gain transparency. This is really important so that all the other supporting business functions can operate. Sales can communicate with customers about important updates and new features. Marketing can plan campaigns. Support can prepare. Finance can ensure adequate budget for new infrastructure and FTEs. Sure it's annoying, but this planning is essential for a business. It just doesn't happen organically. Scrum forces developers to work to some kind of schedule, offering short-term (but flexible) estimates on what can be delivered, when.
In a perfect world, none of this is a problem, and all of it happens organically. I've just never seen that happen. The sacrifice in velocity is worth the increase in value output to the stakeholders.
You make it all sound like a factory and blame developers for going rogue.
That’s not how it works. It’s as though developers are dumb and can only execute if you tell them to do exactly as needed. Rather where’s the leadership and direction? Perhaps that’s not clear or the developers don’t even agree with what’s going on. You statement is so 1-sided.
If someone is not performing you shouldn’t need scrum to work that out otherwise you have bigger problems.
I’d argue alignment is useless as most of the time developers are told to implement useless features. Perhaps with some guidance and direction what the developers come up with is better than product.
It’s sad but product is like a theory machine that’s often impractical.
So what would you prefer? Developers without scrum delivering in 4 months or with scrum and taking a year? Even if they do go off for a few months on their own it’s more than worth it.
The problems aren’t accountability or alignment. If people aren’t following a plan, that is if there is 1 then it’s a leadership problem.
Franky, scrum teams I worked in were pretty much worst in all the points you list, except higher management feeling of control. Especially in alignment between developers point. The cooperation is never really good in scrum, it is sorta kinda passable at best. Interpersonal relationship are either horrible or passive to non existence.
> Unfortunately developers are rarely extroverts, and they often don't have the skills or desire to have tough conversations with each other.
I mean, what are you exactly talking about here? Because developers do criticize each other all the time, both in code review and outside of it. If they have trust, they talk plenty. If you do not see developers communicating, it is because of how you lead a process.
> Sometimes it's adapting to different ways of work, or neurological issues with a team member
Scrum is so inflexible, that it literally prevents accommodations for issues like this. And that is not even speaking about the fact literally this should be job of people management. This is literally what leaderships should do, because they have actual power to change the things.
Great comment. If you are enforcing due dates, you are doing it wrong, and stacking up debt and creating bad quality. It's about transparency. As a developer I never loved transparency, because being imperfect, I would sometimes make mistakes. As a manager, I cannot see how anything can be done correctly without transparency. It's not about the developer, it's about the quality analyst, the dev/ops, the UX designer, the customer, the documentation, the salesperson, the stakeholder, the investor, the business analyst, the quality analyst, the configuration analyst, etc.
Yes but raw velocity is not the only thing that matters. For some projects it is, but for many the accountability of Scrum + the grouping helps with dependency management across an organization.
Scrum does not provide accountability. It creates the illusion of accountability while creating artificial touch points that effectively become the only time anyone thinks about what's going on. At least that's how I've seen it operate in almost every instance I've ever worked with it.
Of course, the counter to that is that we're not doing scrum right. The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ...
I've seen Kanban work well on smaller scales, and Scrum work well on larger scales.
I cannot for the life of me work in the churn and development pace of a Scrum team, so Kanban (and the culture around it) is best fit for me.
I think it also depends upon the type and culture of people working in the team as well. Some teams work really, really well with the predictable cadence, others do not.
It's a case by case kind of situation, I think.
That said I highly prefer Kanban personally for an number of reasons.
The commitment to sprints was literally the first thing that got dropped in our company. It's so nonsensical to create completely arbitrary deadlines without any real urgency.
We now have long sprints (~1 months) for reviews and retrospectives. Which are usually well received. You get to see what all the other teams have been doing, and you also get a formal chance to talk about any problems.
Is Scrum supposed to increase velocity? I always view these processes as a consistency enhancer. "What can we accurately promise 6 months out" vs. "how can we get the most done possible?" This is important because the big risk is that you do 80% of 10 projects, rather than 100% of 1 project, especially if you have a team and not just a couple of individuals.
Lots of stuff pushes organizations in the direction of doing 80% of 10 separate projects, and it's a killer. This is good reading in this domain: https://apenwarr.ca/log/20171213
The only way better insight would happen is if the devs behaved like product managers/owners. We don’t want it.
I can actually see predictability improving, but mostly because we will ship whatever at the end of the sprint and let any issues come back as bugs later. We always ship on time at one Scrum job, but the quality is very low.
The underlying triangle here: Out of time, scope, and quality, you can pick two to specify but you can't constrain all three.
Scrum specifies fixed time and quality ("definition of done"), with scope as the flexible variable, as tasks get pushed out of each sprint.
Kanban specifies fixed scope and quality, letting time be the floating factor for each task.
Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way.
There are some applications that Scrum does fit better than Kanban, notably anything tied to a real world calendar, say a scheduled live event or a school year or holiday or other seasonal concern. But yes, most businesses don't need to be time-boxed with Scrum anywhere near as much as they think they do, particularly given how much of that time is always consumed by organizational friction around the time-boxing negotiations.
(What happens if you do try to constrain and specify all three? We call that a death march. Actually, time invisibly flexes as workers cram in effort at a higher pace, until they burn out and then you're back to quality implicitly or time explicitly giving way unless you reduce scope.)
> Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way.
Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically
I think often the supposed failings of waterfall is actually the failings of large scale software development, which crop up even with agile methods (especially with stuff like SAFe).
My experience with small-scale waterfall is one of getting essentially a spreadsheet of requirements, implementing to spec, fixing a small number of bugs during QA, and then going into production on time and with exceptional quality.
There's a project I did that went from zero lines of code to production in two months, that had literally bugs discovered in a decade of operation. Made entirely possible through waterfall-style development. If you know exactly what to build, development goes fast. There is not a chance in the world that would have happened if we'd been discovering new requirements along the way.
That said, it also puts a lot more demand on well thought out requirements. The people who put together the specs were world class, smart, professional and solid engineers. Extremely particular where it mattered yet with very little bike shedding.
My experience is that developing against fixed requirements is fast and produces exceptionally high quality code. So many bugs and so much technical debt is from having to rewrite the same thing over and over because the requirements aren't set when development starts.
> Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically
This is WILDLY different to my experiences. Waterfall projects always drag out months and even years past their expected delivery. The requirements documents become bloated wish lists. Prioritisation is impossible because no one will accept cutting even the really fluffy stuff. Waterfall requires dedicated project managers who spend their whole day arguing with everyone. I admit that the quality is often higher, but that should be expected when it takes three times longer to deliver. Scrum/Agile forces teams to focus on the core value proposition, and not all the nice-to-haves. You believe this is only an issue with incompetent management, but if so, I've never seen what you consider to be competent management.
I think the better solution here is not to buy into any framework as though it's a religion. Waterfall dominated projects for decades, and it has lots of issues. Agile is dominating current ways of work, and it has lots of issues. We should be using the right tool for the job, and even then, only the parts which make sense for our product and team and culture.
I've only ever seen waterfall work with a large enough team and we'll understood problem space. That said, the two teams I was on where both of those existed it was much more productive that even the best run scrum teams I've been on.
Actually the most effective strategy I've seen is Kanban, but with a fixed release deadline.
Inevitably there are some essential tickets and some nice-to-have tickets.
For the nice-to-haves it's a case of progress or die.
Think of it as time constrained Kanban with semi-fixed scope.
The dropped tickets may carry over to a later release (if there is one), or just die forever (make it easy to cull bullshit).
P.S. From this perspective, the first thing to die is the time wasting sprint rituals that Scrum layers on top of Kanban.
Beware blanket statements! I work with sound in games and have multiple times tried to do Kanban, both from an internal team and an outsourcing team, because of basically the same reasons mentioned in the article - it's agile and task based, and seems like a good fit to be a "factory" for sound assets.
However games are iterative by several orders of magnitude more than traditional tech (I've also been CTO at a more traditional design/consulting firm) and constantly evolving and audio team, both internal or external, end up tightly embedded over the course of 2-3 year long projects, and Kanban ALWAYS breaks down because the edges of tasks are fuzzier than you expect.
Scrum (real scrum, not the surface level dogmatism that passes for it in many places) does work better in this situation. I find myself saying this often "The best tool is the simplest one that does what you need it to". I really do prefer Kanban! It's far simpler. For projects that have clear needs and stakeholders it's great. For "factory" type set ups that provide tools to other internal stakeholders it also works great. But for places where the technical requirements are fuzzy the added complexity of Scrum is helpful, since it focuses on OUTCOMES rather than MEANS/tasks.
Don't be afraid to try different approaches for different sprints/releases and tweak formulas. You can normalize estimation by keeping it consistent while also changing methodologies. But just because Scrum is overused and misunderstood doesn't mean it's useless.
This is the real comment here. I've worked in all three, scrum, kanban and waterfall, and I know from personal experience that they all have their shortcomings and it really depends on what you are trying to deliver and how well your team responds. We've moved from waterfall to scrum to kanban and back and the one standout is clarity of minimum requirements and boy is that hard to get from the relevant people. If you don't get that then stick with waterfall because then no one is responsible!
Yeah, I didn't mention in my earlier comment but I've found that scrum does work better with larger teams because it adds ownership into the process. You can define ownership with Kanban (or any process) but it's not integrated into how it operates without some hacking.
edit I sometimes find myself in the position of apologist for Scrum, which is weird because I'm not that crazy about it, I'd almost always prefer to use something less heavyweight. But people are so quick to throw out the baby with the bathwater - there are a lot of great concepts in scrum, and it's quite interesting to see how all the parts interact when it's actually working.
I think they mean it from a softer perspective - Scrum encourages more time ensuring all the team and tasks are clearly directed towards an outcome for that sprint.
Just putting outcomes as cards on a kanban board will not have that same effect in all instances, as it's more about the soft points of engagement and teamwork driving towards that common goal.
Yeah scrum, or any process really, sucks when it's used like spyware. I've been lucky enough to be part of teams in companies that don't treat their employees like the enemy. So doing scrum the every day work aspect happens at the local level. What I like about scrum is being able to talk to other teams about higher level things while keeping the day to day tasks just within our team. It's similar in programming to the TDD approach of making a public interface and testing against the functionality, while the implementation details are kept internally.
Doing reports I find people care less about the day-to-day work and more about when it gets done, and this is where scrum in theory works well but breaks down in reality. In practice is estimation works when team members are kept consistent, because over time you can track historically "t-shirt size" complexity of task as estimated by the team translates to "x number of man-hours". However in game design we get a lot of major team shakeups pretty regularly with teams changing across different milestones. It's hard to fight against the instinct of "Oh this thing needs our a-team players for this release"
I appreciate the article but I worry that Scrum implemented too rigidly is the reason why it gets a bad reputation.
A lot of the arguments being made are really difficult to generalize and say "this works for every org!". One example:
> When that happens, instead of designing features by committee, which demands a significant amount of back-and-forth discussions, decisions happen locally, and thus are easier to make.
This works really well when the engineers themselves have all the knowledge+ability to tackle the problem. Smaller startups are perfect! and teams that are pure technical. But once a key portion of the requirements lives outside the team, this is no longer effective because then you're building without that feedback.
The danger is trying to measure things purely on developer velocity. I'm not saying kanban is wrong or scrum is wrong, just do what's best for your org by building what's important to your business.
"This works really well when the engineers themselves have all the knowledge+ability to tackle the problem."
This reminds me of a similar situation almost a decade ago where someone watched a talk on how GitHub uses GitHub to build GitHub. The people who watched the talk all tried to convince me that we should adopt similar process that puts less emphasis on PMs. However, this worked for GitHub because their engineers had such a strong similarity to their customer base. For us that wasn't the case at all and we typically needed PMs to have lots of customer conversations and explain to us how customers used our product because we were building Enterprise software for people whose day-to-day we didn't understand easily.
Scrum has prescriptive method of who is supposed to gather requirements, the meeting for requirements gathering, estimation for "understanding of requirements", and demo... well for demo'ing the feature back to "the powers that be".
Kanban doesn't prescribe any stakeholder methodology. It's not that it's not important, it's just up to the organization.
This is definitely a point of contention in Scrum because "oh this is so slow", "there are too many stakeholders", "why do we have to do it this way".
I'm at the belief - some way is better than no way. If you don't like Scrum, cool! Go build your own, but if you don't mind it, Scrum is good-enough^tm.
> This demand for estimations leads to unproductive and unnecessary estimation meetings. These meetings are unproductive because they cause developers to spend time debating whether something is worth two or three story points instead of actually writing code. They’re also unnecessary because if you feed the system with more work as soon as software comes out, estimations don’t matter.
Only if all tasks are of equal priority, which is rare. Otherwise you need some (very basic) cost estimation in order to prioritize.
> Retrospective sessions are also fundamental for a team to continuously improve the way it works. The problem with these sessions in Scrum is that they either happen too early or late. Although it’s good for teams to discuss their practices and look for ways to improve them, it may not be necessary to hold a retrospective session if everything is going fantastically well. Conversely, it may be harmful to wait for two or more weeks to discuss systemic problems impacting the current pieces of work or the overall goal the team is working towards.
> In Kanban, there’s nothing preventing teams from scheduling regular meetings. Yet, teams have the flexibility to schedule meetings whenever they’re necessary.
But unfortunately this means they also have the flexibility to not hold a meeting when it's necessary.
I don't think this article is exactly wrong - Scrum is to a certain extent a crutch, just as any process is to a certain extent a crutch - but I think it overestimates the average manager/team. In my experience teams that pick Kanban over Scrum tend to have issues with stalled, overly-large, and poorly-prioritised tasks (e.g. an undesirable task can sit indefinitely in the "ready for work" column which is usually not what you want), too little process refinement (in particular, retrospectives end up being rare) and take too long to recognise issues.
Scrum is prescriptive and restrictive, but it's like that because it works. After all, if your team was perfect you wouldn't need Kanban either. Just do the right thing and don't do the wrong thing bro.
> They’re also unnecessary because if you feed the system with more work as soon as software comes out, estimations don’t matter.
The question is: estimations don't matter to who? As much as I'd like a constant stream of quality features to be good enough, in reality senior managers and clients want to know what they're getting for their money, and when they'll get it (at least roughly). If your software is doing something important, it's likely that people will be depending on it and when a new feature ships can have a significant impact on how they work, and in turn, what they can deliver.
> As much as I'd like a constant stream of quality features to be good enough, in reality senior managers and clients want to know what they're getting for their money, and when they'll get it (at least roughly).
IME most of the time they need to get over it. The reality is that estimating in that kind of detail would be expensive and not worth the effort.
However what they do reasonably need is the ability to prioritise feature A over feature B and they need a vague comparison of costs in order to do that (like, is feature B going to be 3x as much work as feature A?). Scrum provides that at minimum cost.
Thanks. I found it annoying that the author never says what kanban is. By leading the title with scrum, you can argue that it’s for those familiar with it. But then the article neglects to describe the alternative it claims is better.
It’s akin to saying, “You don’t need yoga; just do twiddlebop right,” and never saying what twiddlebop is.
It’s also rife with meaningless declarations, like the one about “pushing decisions to the edge of the team.” WTF is that supposed to mean?
"When applied correctly, good project management ends up better for everyone."
With good project management you can make any process work, be it waterfall, scrum, kanban or others. All dysfunction comes from people perpetuating processes that don't work. That's what agile was about originally.
I hope you are correct. Finding companies with good project management has so far been quite elusive though. In my career I've had about eight project managers so far, six of which were in a scrum environment. Without exception the scrum PMs have not been effective at all.
I don't doubt that effective scrum management is theoretically possible, but based on personal experience and also by reading through the rest of this thread it seems that scrum is too difficult to do correctly for the vast majority of project managers.
haha, we started by following the scrum rules,
some folks didn't think it is the way to go, sadly not everyone spoke out,
because PM/PO thought it is useful from their perspective...
fortunately, over time, no sub team continued the way, it has mutated back to the kanban style more or less...
I am probably missing something but is kanban even the correct metaphor for creative work(like software development).
Kanban is a back pressure mechanism that can get your factory logistics system running smoothly. However the logistics of creative work is very different than the logistics of assembly work. There are almost no parts needed, why is a backpressure system for part delivery even useful?
It's about limiting the amount stuff under construction.
You got a list of shit that needs to get done. You have 5 people in the team.
On the Kanban board you can see how long each item has been in each column and you can see who's working on it.
You can also limit the amount of items each person can be working on simultaneously. It should be exactly one or you're multitasking, which isn't good for anything.
You have a single task you work on, when it's done you move it forward. If you get stuck you move it backward and comment on it why it's stuck and pick a new one.
It's not, it's one of those cases where IT took some vague ideas related to a concept (e.g. visualizing/minimizing WIP and having a continuous flow) and decided that those meant we're doing the same thing.
See also "lean manufacturing/software development" and obviously "software engineering".
Readit News
Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared.
Once, just once, I was lucky enough to work on a team that switched from Kanban to Scrum, and then, mercifully, blissfully, back again. To be fair, I think we actually worked quicker after the return, though I don't know if that could be attributed to having actually learned some lessons from Scrum, or out of a fear that we'd one day return to it.
The sad truth is that most management teams would prefer their employees to be predictable and observable (ie, under control) than be efficient. Especially if nobody can actually quantitatively measure the loss of efficiency.
Velocity metrics, burndown charts, point estimations, and all of that have been at best aspirational white lies and at worst outright falsehoods on almost every scrum/agile team I've ever worked on in the past fifteen years.
In actuality many scrum teams are doing something closer to kanban day-to-day under the fake veneer of scrum/agile sprints on top to satisfy management and/or external parties.
Agree with everything _expect_ retros.
I think the value of the retros is proportional to how senior the team is and to how seasoned managers are. But for me retros are extremely high value _if_ you have:
- Teams that can look at problems head on and be civil addressing things without making it personal.
- Managers that have a 'clear roadblocks' mindset and have a service-providing mindset towards the team.
In this scenario you can really have high value retros, with continuous adjustments to workflow, processes, design, without continuously repeating the same mistakes or falling in the same pitfalls.
So even though the current company is using scrum, in my team I treat it as kanban with story point limited, meaning I start with a certain amount of story points, then add / remove as the sprint is going.
Software development is incredibly opaque by default (heck, even we don't know how far along we are, most of the time) so anything that improves that will be perceived as improved productivity.
But even if it's not, sometimes progress reporting (however rough) is needed to synchronise with other parts of the organisation. It just needs to be put into a form that is useful (e.g. for agile projects "percent of plan delivered" is not a useful metric) and how it's going to be used should be explained to those producing it. Heck, optimal is if the people making software and the people they need to coordinate with can get together and jointly agree on what type of reporting is actually meaningful for both parties.
Almost always, we're discussing vanity metrics though.
But I do agree with the post - Kanban is way way better and you can include the scrum continuous improvement elements as well on a regular cycle.
Yet ironically they care and tout about their ability to measuring efficiency.
An easy way to boost efficiency: hide inefficiency out from view!
we're in this exact phase - sacrificing efficiency, team morale and independence to make the boards look cleaner to "raise the bar" per se.
We're a small efficient team in a massive org. Manager does a great job of not making stupid decisions, values people's time and is clear about the metrics the team gets evaluated on.
somewhere along the way he's, missed the reality that clean user stories and tasks, complete with points down to hours and acceptance criteria can still be completely f$#king wrong compared to the actual work that needs to be done. Not because the people are idiots but because thats how most software work is. You find out when you actually start working on it.
But if you mandate that you need a well cut plan before code gets written, you mostly get well written $hit.
We just embarked on this journey which I can mostly predict the outcome of.
sad, true.
In Scrum, estimation meetings usually result in follow-ups with stakeholders that can (and often do) radically change the stories themselves. Totally different code winds up getting delivered that increases actual value delivered, even if "lines of code written" slows.
That's the whole point of agile, to deliver value rather than code.
1. Does the team have the right people, with the right skill sets, wearing the right hats? (e.g. BAs or PMs doing those actual jobs)
2. Does the team have self-motivated, high-performance people?
I have yet to see any process that can overcome "No and no."
Large tech org's knee-jerk response to failures is to increase the formalism of their agile frameworks, but that's just a bandaid over gangrene.
If they think the solution to bad people is more process, they've already lost.
Deleted Comment
I know, I know, it's just a label applied to the cycle time of the process but labels matter and I think it subtly and subconsciously poisons the whole thing. Especially when managers and PMs start making sprint cycles into hard deadlines.
However, Scrum doesn't make much sense if you don't continuously iterate. Another symptom of this is people measuring velocity instead of value created. To properly implement Scrum, you actually need to measure the impact of the work completed in the past two weeks. Unfortunately, most teams don't do this, instead they focus on measuring velocity since it's easier and within their control. It's worth noting that it's completely fine for teams not to constantly iterate and change direction (including high-performing teams), and in those cases, Scrum simply isn't the best tool for the job imo.
I must admit that I personally prefer Kanban for almost all workloads.
This has been my experience. I've seen more than once management teams happier with numbers and estimates that weren't met than actually getting software out quicker at an unanticipated rate.
They'd rather have estimates that they could yell about than revenue generating software through (presumably) happy customers. <shrug>
Software estimation, similarly, is fractal in nature - you can always drill down deeper to measure but it gets increasingly complex and at some point you have to ask, is it worth it being "accurate"? Or do we just do it? Org charts require the former while developers desire the latter.
Alignment is so important, and it's rare that I've found a team not using scrum which is working harmoniously. In reality, some members of the team aren't pulling their weight and it's causing animosity. Or they're working at odds and not communicating the pieces they're developing. A huge one for me is stakeholder alignment. Without scrum it's awfully common for developers to build things the stakeholder doesn't want. Scrum forces regular check-in and demonstration which otherwise rarely happens organically.
A big part of scrum is accountability. As I touched on, when people aren't pulling their weight, it hurts everyone. Unfortunately developers are rarely extroverts, and they often don't have the skills or desire to have tough conversations with each other. Sometimes it's just agreeing on what they find acceptable behaviour and work. Sometimes it's adapting to different ways of work, or neurological issues with a team member. You might be surprised to learn that a lot of developers are on the spectrum. Scrum forces these conversations to the fore and provides a tested framework for conflict resolution.
We also gain transparency. This is really important so that all the other supporting business functions can operate. Sales can communicate with customers about important updates and new features. Marketing can plan campaigns. Support can prepare. Finance can ensure adequate budget for new infrastructure and FTEs. Sure it's annoying, but this planning is essential for a business. It just doesn't happen organically. Scrum forces developers to work to some kind of schedule, offering short-term (but flexible) estimates on what can be delivered, when.
In a perfect world, none of this is a problem, and all of it happens organically. I've just never seen that happen. The sacrifice in velocity is worth the increase in value output to the stakeholders.
That’s not how it works. It’s as though developers are dumb and can only execute if you tell them to do exactly as needed. Rather where’s the leadership and direction? Perhaps that’s not clear or the developers don’t even agree with what’s going on. You statement is so 1-sided.
If someone is not performing you shouldn’t need scrum to work that out otherwise you have bigger problems.
I’d argue alignment is useless as most of the time developers are told to implement useless features. Perhaps with some guidance and direction what the developers come up with is better than product.
It’s sad but product is like a theory machine that’s often impractical.
So what would you prefer? Developers without scrum delivering in 4 months or with scrum and taking a year? Even if they do go off for a few months on their own it’s more than worth it.
The problems aren’t accountability or alignment. If people aren’t following a plan, that is if there is 1 then it’s a leadership problem.
> Unfortunately developers are rarely extroverts, and they often don't have the skills or desire to have tough conversations with each other.
I mean, what are you exactly talking about here? Because developers do criticize each other all the time, both in code review and outside of it. If they have trust, they talk plenty. If you do not see developers communicating, it is because of how you lead a process.
> Sometimes it's adapting to different ways of work, or neurological issues with a team member
Scrum is so inflexible, that it literally prevents accommodations for issues like this. And that is not even speaking about the fact literally this should be job of people management. This is literally what leaderships should do, because they have actual power to change the things.
Of course, the counter to that is that we're not doing scrum right. The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ...
Deleted Comment
I cannot for the life of me work in the churn and development pace of a Scrum team, so Kanban (and the culture around it) is best fit for me.
I think it also depends upon the type and culture of people working in the team as well. Some teams work really, really well with the predictable cadence, others do not.
It's a case by case kind of situation, I think.
That said I highly prefer Kanban personally for an number of reasons.
We now have long sprints (~1 months) for reviews and retrospectives. Which are usually well received. You get to see what all the other teams have been doing, and you also get a formal chance to talk about any problems.
Lots of stuff pushes organizations in the direction of doing 80% of 10 separate projects, and it's a killer. This is good reading in this domain: https://apenwarr.ca/log/20171213
I can actually see predictability improving, but mostly because we will ship whatever at the end of the sprint and let any issues come back as bugs later. We always ship on time at one Scrum job, but the quality is very low.
As an engineer on a team using scrum, this is my favorite part.
Deleted Comment
Scrum specifies fixed time and quality ("definition of done"), with scope as the flexible variable, as tasks get pushed out of each sprint.
Kanban specifies fixed scope and quality, letting time be the floating factor for each task.
Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way.
There are some applications that Scrum does fit better than Kanban, notably anything tied to a real world calendar, say a scheduled live event or a school year or holiday or other seasonal concern. But yes, most businesses don't need to be time-boxed with Scrum anywhere near as much as they think they do, particularly given how much of that time is always consumed by organizational friction around the time-boxing negotiations.
(What happens if you do try to constrain and specify all three? We call that a death march. Actually, time invisibly flexes as workers cram in effort at a higher pace, until they burn out and then you're back to quality implicitly or time explicitly giving way unless you reduce scope.)
Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically
My experience with small-scale waterfall is one of getting essentially a spreadsheet of requirements, implementing to spec, fixing a small number of bugs during QA, and then going into production on time and with exceptional quality.
There's a project I did that went from zero lines of code to production in two months, that had literally bugs discovered in a decade of operation. Made entirely possible through waterfall-style development. If you know exactly what to build, development goes fast. There is not a chance in the world that would have happened if we'd been discovering new requirements along the way.
That said, it also puts a lot more demand on well thought out requirements. The people who put together the specs were world class, smart, professional and solid engineers. Extremely particular where it mattered yet with very little bike shedding.
My experience is that developing against fixed requirements is fast and produces exceptionally high quality code. So many bugs and so much technical debt is from having to rewrite the same thing over and over because the requirements aren't set when development starts.
This is WILDLY different to my experiences. Waterfall projects always drag out months and even years past their expected delivery. The requirements documents become bloated wish lists. Prioritisation is impossible because no one will accept cutting even the really fluffy stuff. Waterfall requires dedicated project managers who spend their whole day arguing with everyone. I admit that the quality is often higher, but that should be expected when it takes three times longer to deliver. Scrum/Agile forces teams to focus on the core value proposition, and not all the nice-to-haves. You believe this is only an issue with incompetent management, but if so, I've never seen what you consider to be competent management.
I think the better solution here is not to buy into any framework as though it's a religion. Waterfall dominated projects for decades, and it has lots of issues. Agile is dominating current ways of work, and it has lots of issues. We should be using the right tool for the job, and even then, only the parts which make sense for our product and team and culture.
Think of it as time constrained Kanban with semi-fixed scope. The dropped tickets may carry over to a later release (if there is one), or just die forever (make it easy to cull bullshit).
P.S. From this perspective, the first thing to die is the time wasting sprint rituals that Scrum layers on top of Kanban.
https://www.projectmanager.com/blog/triple-constraint-projec...
Deleted Comment
However games are iterative by several orders of magnitude more than traditional tech (I've also been CTO at a more traditional design/consulting firm) and constantly evolving and audio team, both internal or external, end up tightly embedded over the course of 2-3 year long projects, and Kanban ALWAYS breaks down because the edges of tasks are fuzzier than you expect.
Scrum (real scrum, not the surface level dogmatism that passes for it in many places) does work better in this situation. I find myself saying this often "The best tool is the simplest one that does what you need it to". I really do prefer Kanban! It's far simpler. For projects that have clear needs and stakeholders it's great. For "factory" type set ups that provide tools to other internal stakeholders it also works great. But for places where the technical requirements are fuzzy the added complexity of Scrum is helpful, since it focuses on OUTCOMES rather than MEANS/tasks.
Don't be afraid to try different approaches for different sprints/releases and tweak formulas. You can normalize estimation by keeping it consistent while also changing methodologies. But just because Scrum is overused and misunderstood doesn't mean it's useless.
edit I sometimes find myself in the position of apologist for Scrum, which is weird because I'm not that crazy about it, I'd almost always prefer to use something less heavyweight. But people are so quick to throw out the baby with the bathwater - there are a lot of great concepts in scrum, and it's quite interesting to see how all the parts interact when it's actually working.
Just putting outcomes as cards on a kanban board will not have that same effect in all instances, as it's more about the soft points of engagement and teamwork driving towards that common goal.
Doing reports I find people care less about the day-to-day work and more about when it gets done, and this is where scrum in theory works well but breaks down in reality. In practice is estimation works when team members are kept consistent, because over time you can track historically "t-shirt size" complexity of task as estimated by the team translates to "x number of man-hours". However in game design we get a lot of major team shakeups pretty regularly with teams changing across different milestones. It's hard to fight against the instinct of "Oh this thing needs our a-team players for this release"
A lot of the arguments being made are really difficult to generalize and say "this works for every org!". One example:
> When that happens, instead of designing features by committee, which demands a significant amount of back-and-forth discussions, decisions happen locally, and thus are easier to make.
This works really well when the engineers themselves have all the knowledge+ability to tackle the problem. Smaller startups are perfect! and teams that are pure technical. But once a key portion of the requirements lives outside the team, this is no longer effective because then you're building without that feedback.
The danger is trying to measure things purely on developer velocity. I'm not saying kanban is wrong or scrum is wrong, just do what's best for your org by building what's important to your business.
This reminds me of a similar situation almost a decade ago where someone watched a talk on how GitHub uses GitHub to build GitHub. The people who watched the talk all tried to convince me that we should adopt similar process that puts less emphasis on PMs. However, this worked for GitHub because their engineers had such a strong similarity to their customer base. For us that wasn't the case at all and we typically needed PMs to have lots of customer conversations and explain to us how customers used our product because we were building Enterprise software for people whose day-to-day we didn't understand easily.
But how does Scrum help out here?
Kanban doesn't prescribe any stakeholder methodology. It's not that it's not important, it's just up to the organization.
This is definitely a point of contention in Scrum because "oh this is so slow", "there are too many stakeholders", "why do we have to do it this way".
I'm at the belief - some way is better than no way. If you don't like Scrum, cool! Go build your own, but if you don't mind it, Scrum is good-enough^tm.
Only if all tasks are of equal priority, which is rare. Otherwise you need some (very basic) cost estimation in order to prioritize.
> Retrospective sessions are also fundamental for a team to continuously improve the way it works. The problem with these sessions in Scrum is that they either happen too early or late. Although it’s good for teams to discuss their practices and look for ways to improve them, it may not be necessary to hold a retrospective session if everything is going fantastically well. Conversely, it may be harmful to wait for two or more weeks to discuss systemic problems impacting the current pieces of work or the overall goal the team is working towards.
> In Kanban, there’s nothing preventing teams from scheduling regular meetings. Yet, teams have the flexibility to schedule meetings whenever they’re necessary.
But unfortunately this means they also have the flexibility to not hold a meeting when it's necessary.
I don't think this article is exactly wrong - Scrum is to a certain extent a crutch, just as any process is to a certain extent a crutch - but I think it overestimates the average manager/team. In my experience teams that pick Kanban over Scrum tend to have issues with stalled, overly-large, and poorly-prioritised tasks (e.g. an undesirable task can sit indefinitely in the "ready for work" column which is usually not what you want), too little process refinement (in particular, retrospectives end up being rare) and take too long to recognise issues.
Scrum is prescriptive and restrictive, but it's like that because it works. After all, if your team was perfect you wouldn't need Kanban either. Just do the right thing and don't do the wrong thing bro.
> They’re also unnecessary because if you feed the system with more work as soon as software comes out, estimations don’t matter.
The question is: estimations don't matter to who? As much as I'd like a constant stream of quality features to be good enough, in reality senior managers and clients want to know what they're getting for their money, and when they'll get it (at least roughly). If your software is doing something important, it's likely that people will be depending on it and when a new feature ships can have a significant impact on how they work, and in turn, what they can deliver.
IME most of the time they need to get over it. The reality is that estimating in that kind of detail would be expensive and not worth the effort.
However what they do reasonably need is the ability to prioritise feature A over feature B and they need a vague comparison of costs in order to do that (like, is feature B going to be 3x as much work as feature A?). Scrum provides that at minimum cost.
https://www.atlassian.com/agile/kanban/kanban-vs-scrum
It’s akin to saying, “You don’t need yoga; just do twiddlebop right,” and never saying what twiddlebop is.
It’s also rife with meaningless declarations, like the one about “pushing decisions to the edge of the team.” WTF is that supposed to mean?
- the estimate is a joke...
- the standup is useful to know who is pretending work. but no need a daily standup for sure.
and a non-technical PM with scrum makes things worse.
With good project management you can make any process work, be it waterfall, scrum, kanban or others. All dysfunction comes from people perpetuating processes that don't work. That's what agile was about originally.
I don't doubt that effective scrum management is theoretically possible, but based on personal experience and also by reading through the rest of this thread it seems that scrum is too difficult to do correctly for the vast majority of project managers.
fortunately, over time, no sub team continued the way, it has mutated back to the kanban style more or less...
Kanban is a back pressure mechanism that can get your factory logistics system running smoothly. However the logistics of creative work is very different than the logistics of assembly work. There are almost no parts needed, why is a backpressure system for part delivery even useful?
You got a list of shit that needs to get done. You have 5 people in the team.
On the Kanban board you can see how long each item has been in each column and you can see who's working on it.
You can also limit the amount of items each person can be working on simultaneously. It should be exactly one or you're multitasking, which isn't good for anything.
You have a single task you work on, when it's done you move it forward. If you get stuck you move it backward and comment on it why it's stuck and pick a new one.
See also "lean manufacturing/software development" and obviously "software engineering".