Ditching Scrum for Kanban - The best decision we’ve made as a team
medium.com
medium.com
Can anyone elaborate why they find standups useful? The planning board should already communicate what's being done, what's been done and why people are blocked. I only find them helpful if some people in the team generally don't communicate well what they're up to (e.g. during daily work, over lunch). Otherwise I find most people zone out during the standup and it just interrupts work.
Oh, Bob finished the xyz bit? Great I'll get started on abc now.
Jim's stuck with the autobuzzulator? I've used those before, I'll jump in and give him a hand after the standup.
Katie's not been able to deliver the turnip functionality? Still can't test the beets either then...
>> I only find them helpful if some people in the team generally don't communicate well what they're up to (e.g. during daily work, over lunch).
I communicate well with people I'm working with in the microcosm of what I'm doing right now, but there may be a few other people on the team doing related tasks that I'm not talking to every day.
And lunchtime is my time to get a few minutes away from screens and work, take a walk, have some food etc.
After doing scrum for a few years, my impression is that stand-ups are useless because you can't depend on them. They're frequently too far away to be used for the purposes you're talking about, so you always need an alternative. If that alternative is good, you might as well always use it and cancel the meeting.
I don't know of a better alternative that maintains the face to face element.
Also, if the company has more than a few devs, scrum meetings are usually limited to your team. And you should already know what your team members are working on - if you don't, then your team has serious communication issues, scrum or not scrum.
I don't believe this is true. I can be interested but not directly involved all the time.
>> And you should already know what your team members are working on
This is exactly what the standup is for.
A not-too-long team meeting once or twice a week to talk about big themes is pretty reasonable, but usually I can't even remember what is said in a standup, because much of it isn't things I need to remember.
If it's forced short, there's usually not enough data, if it's it's too long, everything gets tuned out. It's really another kind of status meeting, and I think meetings should instead produce actionable items.
You don't really need to remember exactly what's said in a standup, IMHO, participate in it and offer your skills or resources to help other people who are stuck, and get an idea of what's going on.
I was very hands on when running meetings when I did it that way. Usually had an agenda, broke when we didn't have anything else to do, and kept on topic.
Isn't that information already on your planning board? Likewise, it should only take a minute to review the planning board updates each day and you should be getting direct notifications for things you're suppose to be helping on.
I can see the value in you all getting together to have a high-level chat on how things are going maybe once a week but every single day is way too much for me.
I think even in a small team where everyone keep it short it's just too much information. I can already see what everyone is doing on Jira/etc and later on git in my IDE, the rest don't stick.
I have tested people by asking them less than 30mn after a DSM questions about who is doing what and nobody could answer and yet they usually can't admit that DSM are mostly worthless.
I also hate DSM when I'm on a long task because I just say the same thing everyday and feel like a slacker. At which point do you start to game the system and only pick short easy tasks ?
I guess maybe Scrum and agile appeal more to young devs ? They seem to like the gamification aspect of it, moving post-its, feeling great by under-estimating tasks' length, the flatness of the team.
Myself I would prefer a competent project manager instead of those empowering retrospectives and those velocity charts that could be turning against you by management any day.
Over dramatization aside :) and in good spirit about the article I would prefer Kanban to Scrum but it seems way less used (at least in webdev).
I've had that feeling too. You feel like dropping the long tricky important task you're doing to complete a couple of easy ones so you have something better sounding to say for the impending standup. A similar and much worse situation happens when you have to give client demos too often I find.
It's important for everyone on the team to know what others are doing in order to share knowledge. If people are zoning out, you're not getting that benefit.
Why do this in a standup though? This information isn't on your planning board? I don't find standups efficient for this.
If you want to build software systems, you should engage in software engineering, not social engineering. Social engineering only supports the manager hierarchy which is probably at that point misaligned with value production.
If I were a deep cynic (instead of just a natural contrarian), I could say they expose the manager as someone who cannot command respect unless they are intimidating subordinates into the social risk of showing themselves impotent to achieve on a day to day basis.
If a manager doesn't know what his team is up to before the meeting, he's not doing a good job. Perhaps because he doesn't already command the respect of the team?
Can "drum-beat" scheduling help in crunch times? Probably. If you are always in a crunch time, the scale of your efforts probably are probably going to shrink, and/or you may lack time to make longer range plans and are effectively navigating without a map.
Stand ups actually provide:
1.) Better communication of what everyone is working on.
2.) This leads to faster cross training as people are able to ask questions.
3.) Making others on the team aware of issues you are working on so they don't make bad assumptions that you're not doing anything etc.
4.) Social engineering shouldn't work here much as far as being lazy. Good team leads and coworkers will ask to help out should they see someone dragging there feet. Your coworker should be doing code reviews or know about how long it takes to setup a server. It should be pretty obvious if you manipulating, at least I've found it is.
5.) In the past 2 months we have let two people go because standups revealed they weren't really doing anything. Stand ups gave us a chance daily to ask what have you done? It gave the chance for a coworker to step in and help out. It identified this person just didn't want to work and we replaced him with someone who did.
>>> If a manager doesn't know what his team is up to before the meeting, he's not doing a good job. Perhaps because he doesn't already command the respect of the team?
I disagree. A good manager should have a broad overview of what's going on but, he should be busy in his own job planning etc. to not have to micromanage. A 15 minute stand up each day gives him insight he needs without standing over anyone's shoulder or worse making false assumptions about what they might not be doing.
I do agree with you that a manager's job is to support the team, and not the other way around.
2) People can ask questions at any time, but in a meeting only one person can really have the floor so provides a synchronous block on communication for anyone not involved in the exchange.
3) "Making others aware" so they don't think "you're not doing anything", is the social pressure "face-saving" style I believe has nothing to do with software engineering (at best). At worse, if your entire team is obsessing that you have less to do than they are doing, then they have way too much time to obsess with, probably the time they spend in those meetings; they should take it up with management, who should have knowledge on what's going on anyway due to status reports and a general involvement with the team in an ongoing basis.
...
>>> I disagree. A good manager should have a broad overview of what's going on but, he should be busy in his own job planning etc. to not have to micromanage. A 15 minute stand up each day gives him insight he needs without standing over anyone's shoulder or worse making false assumptions about what they might not be doing.
The term micro-manage is yours not mine. A 15 minute stand-up gives him the power to assert that for 15 minutes each day, he is the alpha-male. That's really all face-time meetings like that do when it is between subordinates and superiors. For everyone else, its a jockeying up position and pecking order. Welcome to the primate side of human culture; I didn't make the rules I simply observe them every time I see it happen.
If he can't get what he needs without appearing to be micro-managing, he lacks the social skills to manage with greatness. But he'll be in fine company as most of his management peers are roughly equivalent. From my own experience good managers are few and far between because to be a good technology manager you need to be a good manager and a good technologist.
However, if a manager is going to pick a team management religion, he'd do best with Zen.
No one will bat an eye (so long as you put meaningful terms in there) until this happens for several days in a row. Nor should they, because the micromanaging alternative is worse.
Stand-ups aren't a motivating factor for typical developers. It drives some accountability for people who are just accomplishing nothing for weeks, but that could be accomplished by looking at the checkins once a week, too.
[edit: phone typos]
While it is always possible to use any activity for social engineering or shaming (feeling like a school kid) I don't really see that as a good description of the stand ups effect. It is a "deadline" that is artificially imposed, on a particular task.
In my experience good developers have a wide variety of things they could be working on at any given time, and those things have different weights and different "fun" factors. Without some sort of time limit it is possible to get lots and lots and lots of stuff done without the rest of the team being able to move forward. So once you've agreed on the tasks that need to get done, having a deadline to finish them helps prioritize and focus the activity.
My experience is that bad management is completely orthogonal to process. Any process can be abused by a poor manager in ways that are detrimental to the team, and a good manager can keep a team motivated and productive even with a bad process.
So I don't think stand ups are about "managing" teams, they are a good tool to focus you on what, of the many choices you have, you should be working on right now. Oddly enough, the more senior you get as a developer, the harder it is to get that level of clarity.
Another benefit of hard allocated blocks of time for standup - they're explicitly grabbing people's attention. It's very easy to ignore stuff on the board, if you're not directly involved in it, but if you are simply in the room, listening to other people, you may contribute something useful to the otherwise unrelated conversation.
It's also much faster and more fun than writing some mini-report on a planning board people may or may not read.
But the most important thing is that it is quick and encapsulated. Only about things the whole teams need to know. You need to be happy with reporting that nothing interesting for the whole team happened.
On the other hand, if you need a standup to ask questions about stuff you're stuck on, then your work environment has serious issues. It might be 24 hours until the next standup. You need to have colleagues who are available and willing to communicate during most of the office hours - confining this to the standups means that there are issues either at the organization level or, more probably, at personal level.
Personally, I've had more than enough of work environments where standups are used "because we have to communicate" - and then some of your colleagues spend the whole day with earphones on (= impossible to shout a question on the fly) and other look pissed off whenever you ask anything.
I'm used to pair programming and communicating all through the day. This is incompatible with the surly loner programmers you describe in the last paragraph.
As for the lone programmers you haven't met: lucky you. I seriously believe that in the "agile" companies I've worked in, scrum was actually intended to make people talk, if only once a day and for a few minutes. What was that line? Ah yes: "individuals and interaction over processes and tools". Good luck.
Typically when someone says "we're a little stuck on how to do X" someone else chimes in with how to do it. No big (or small) list of questions to discuss.
If the meeting is done right, the team is not bored, and what's discussed is interesting to the whole team, since we collectively own the code base.
I've definitely met those loner programmers. I might even have been a little like that a long time ago. They can do great work, but need to be kept out of my agile teams.
The way to get people to talk about the work is to pair program. I'm not interested in working solo programming.
Additionally, we use it as a chance to bring up anything we need help with, or anything we found interesting in the last day, which wasn't important enough to interrupt the rest of the team with.
These sort of working arrangements sound horribly inefficient. How do you ever get enough real familiarity with what you're actually doing when you're getting jerked around to something different every couple days? It sounds like being constantly on the treadmill.
I mean, if you want to know the status of a system do you go to the dashboard or do you go review every system event for the past few hours? I hope not the latter! That's what you do when something seems off, which is exactly the case too for daily standups. If something doesn't seem right, you go review discussions and updates.
Also, at the risk of triggering on standup philosophy, I do believe that zoning out during standups mean it's being done poorly: updates are too long or people are not engaging each other. That's the problem to fix, by setting an example of good habits yourself: cut off rambling, encourage active cross-questioning and ideas, etc.
My classically trained PM after taking an Agile training class:
First we'll have a planning sprint.
Then we'll have a coding sprint,
Followed by a testing sprint...As far as I can tell, the effectiveness of the team has a lot more to do with people's ability to self manage their workload (under any system) than how much time and effort is dedicated to tracking it.
We are also able to provide other dependent teams with better day to day visibility on specific requests rather than sprint-level visibility.
Out of curiosity, how long do your standups last? How big is the team?
Everybody didn't zone out every day, but most did, most of the time.
Frankly, it's a huge opportunity for the listeners to shine. (Yay for being a listener)
My daily stand-up is usually 5-10 minutes. About 5 minutes of the standard "what I did, what I plan to do, and what's in my way". And 0-5 minutes of resolving problems (figuring out if I need to escalate, or if another team needs to be involved, etc). Anything longer than that, and we schedule follow-up meetings with a more correct set of attendees.
Like you want a bunch of examples? How do you have some much patience for that if a standup interrupts your work?
Maybe you have them at the wrong time. We have one at 9:30 and it works. People who arrive early are pretty much cranking and the standup is a break from that. People who arrive later (me) show up and it's the first thing of the day goes with a cup of coffee or tea.
Any breakouts can happen right after, have those discussions at somebody's desk while you're already interrupted and THEN jump into the long stretch till lunch. I don't really see the interruption there.
Even if I get bored and dont' know what people are talking about some of the time, I'd say it'd be pretty selfish of me to claim that they are a waste of time. And it would also be stupid of me to think that something sent in an email or commmented on slack or lync is enough. I mean if you could send a message and everyone got it the first time, I think there wouldn't be a concept of marketing or advertising in the world. Sometimes people need to hear things twice.
I guess I'm just not big on keeping work in a black box. And I think it's comical and sad that we go to jobs and stare at screens all day. face to face interaction and having to express yourself to a group for a measly 30 seconds a day is a positive. It might even force a few of us to consider our appearance too. And frankly, I think I'm paid to answer questions and be available to people as needed, so a standup is meant to be an efficient way to do that and it's supposed to encourage brevity. If it's not, start communicating push it in that direction.
"Individuals and interactions over processes and tools"
This is the key take-away. And in my experience this is absolutely true.
On the other hand, working now as a consultant where I am frequently on shorter-term projects with a definitive "end" for the engagement, the time-boxed sprint approach (or "Scrum") actually seems to work well.
Scrum might work for individual "projects". It does not scale or coalesce well with long-term development and maintenance.
> Perhaps there is indeed a natural progression of engineering teams adopting Scrum, then moving to Kanban.
This also mirrors my experience.
In shorthand, having been Product Manager for a number of teams at a variety of companies in several industries, I've found that Scrum is better for teams developing mostly new features, with relatively little maintenance; and Kanban better for teams focused primarily on maintenance, with fewer large features.
The rationale is really simple: for new feature launches, reporting and tracking vs. schedule is key; for maintenance, throughout is key.
That said, regularly missing predicted story points by more than about 10% is not the sign of a healthy team. Being bedeviled by routine bug fixes is not the sign of effective management. Both are routine issues that most highly-effective teams, whether Scurm or Kanban, deal with well.
Depending on the scale you're operating at, it's easy to see this as a waterfall methodology. There are lots of different words to describe organizing work, but what's important is that the methodology remains consistent enough that the team understands it.
I think of time-boxed sprints as great for training. Humans aren't going to get better at estimating how long it takes to complete complex engineering tasks. But teams that work together over a long enough period of time can plan ahead better. (For example, time-boxed sprints would suggest that everyone has to take vacations at the same time for Scrum to be effective.) There are plenty of ways to deal with the fact that humans are asynchronous. I particularly liked this author's focus on team morale as a major factor.
A medium/large project (200 man years in the code over 10 years say), then it's a lot harder. A required refactoring in the codebase that would take 200h is a common discovery in issues estimated at a few h.
That said, I agree that regular timelines aren't the only way to create a sense of urgency in your team.
If a team member gets sick for a week, it can already be impossible to meet the goals of a two-week sprint.
It happens (not so often, but it does) that we underestimate the complexity of a task by a factor 5 or so; that alone can also make it impossible to meet the goals.
There are just too many things that lead to building pressure when there's no actual need for pressure from a business point of view.
Team members do get sick, scope tends to sprawl, and life just generally gets in the way; but good estimation includes a buffer. Under-promise and over-deliver, at least until you figure out what you're doing.
I think what makes the difference is that we're continuously delivering, so there's no delivery ceremony between one sprint and the next to make the crunch mode mean something.
It's a really hard thing to do, we all want to be the hero that saves the sprint. It also encourages you to end up with lots of discrete chunks of work in a sprint so you can complete 80% of your initial commitment and salvage a sense of achievement rather than getting 80% through a few big tasks but none of them actually done.
A sprint with 4 developers and 4 tasks each estimated to take 2 weeks will almost never succeed. A sprint with 4 developers and 20 tasks each estimated to take a day or two stands a much better chance of success. Combine that with some metrics around "complexity per developer per available day" and you quickly end up with some charts showing productivity that is hopefully improving which will hopefully improve morale.
My first reaction is you are not sufficiently grooming your backlog. Stories are left too large, with too many unknowns. If you tend to have a small number of large tasks, this is likely the case.
That, or you just aren't very good at estimating. A large number of small tasks would indicate this problem.
In the second case, you need to circle back with the PO and discuss which items can push to the next sprint. And make a concerted effort to estimate better during grooming and planning sessions.
In your case or ours, one of the nice things about stepping back is reprioritization, which happens nicely in Scrum but not so much in Kanban. It is easy to define a path and never diverge only to wake up and realize you built an old vision.
Haven't seen it yet but it's worked for many organizations and projects. For decades. Surely some improvements since then but one has to wonder what the useless-to-critical ratio is in activities of the new things. It still isn't clear to me.
I worked in a team for 2 years that tried to do scrum because it's new thing that everyone should be doing and I feel it added nothing of value.
Very good video from Markus Andrezak explaining the three "modes":
https://vimeo.com/146522220 (Must see)
"The biggest mistake companies can make is to define their (one) process, culture, way of work. The work that needs to be done in a sustainable company differs in at least three fundamental ways."
[1] Simon Wardley and Markus also explain why bimodal IT does not work
One link is http://blog.gardeviance.org/2015/10/agile-vs-lean-vs-six-sig...
(I'm sure his view and his value maps on strategy will be huge in 5 years, although he is relativly unknown today)
Project Managers - That this role is mentioned, but not that of Scrum Master, is odd but unsurprising. PMs aren't mentioned in Scrum at all and often the way they want to do things clashes with the Scrum way of doing things. In the given example of the PM moaning about estimation Scrum at least forces that realisation quickly, something which Kanban lacks. There may well have been a Scrum Master, one of the things I've experienced them doing is guiding my team down from 1 month sprints through 2 week ones down to a single week. "It's really hard to plan for 2 weeks work" is a classic moment for the Scrum Master to say "what about..."
"We tossed out the retrospectives" - Despite acknowledging them as a good thing? For me retrospectives are the most powerful part of Scrum. Stopping retrospectives might save you a few hours and some awkward conversations but is likely to hamper your continued development. Scrum is really good about moving a team to the "conscious incompetent" phase - i.e. you are forced to be aware you are bad at something and really need to work on it. Retrospectives are the way to improve and grow.
"We kept our deadlines" - That you had deadlines (again the sign of a PM somewhere), and view them as important enough to mention again is interesting. It hints at quality not being the most import factor, which is one of the keys to doing Scrum well.
For me moving to Kanban was a fix for a Scrum team that wasn't working well. I've worked on a good Scrum team, that took a while to get going, but got there by being able to be open and honest about poor morale and then dealing with it. The new team didn't get there, we moved to Kanban and while everyone is happier our productivity is much, much lower. I do feel there is a place for switching to Kanban - when the scope of the project has moved into "we know how to do this" space, often close to a major release (if you do infrequent releases) where 3rd party involvement plays havoc with planning. If you're dealing with points high on the "the business don't know what they want" or "we don't know how to do this" chart then, for me, Scrum is still king. If you're high on both axes then you might want to switch projects / companies...
Sadly, our Scrumlessness was found out and it was implemented again shortly before I left. Morale was dropping steadily on the team already (unrelated reasons), reimplementing the parts we already knew didn't work was a bummer, and the Scrum leader talked down to me when I tried to advocate for the team.
The other Scrum leader we had was pretty great, but, unfortunately, was not the one assigned to my team.
Sorry if this borders on ranting. I really enjoyed working for that company, but it was a rough time toward the end of duration there. Apparently I have lingering frustrations, especially since I'm still friendly with many on the ops team. :)
A bad thing about scrum is that it introduces a lot of phony deadlines that have nothing to do with the business; this is like the common practice of the boss setting a short deadline on the hope that they can control the cost (total hours) by controlling calendar time.
On the other hand having a release every two weeks means you actually need a release. There are so many projects where a few programmers spend say 1.5 years building a components and hypothetically the application is feature complete, but they are nowhere near running it on a real server or packing it up for the customer with an installer and all that and it takes another 0.5-1 yr to figure out how to make a release.
Then there is a stressful process of making a few more releases to fix the inevitable problems, then they go off and work another 2 yrs on the next release and then find they've forgotten how to make a release. The best thing about scrum is that it avoids that.
The idea that the phony deadline is fixed is another problem. If you can slip the schedule by 2 or 3 days in scrum to address critical things in the scope there that is no problem but many agilists will fight that.
Another failure mode is the project that is hitting the goals for milestones well (estimating things about 10% accurately) and that makes people feel good, but somehow you never get to the last milestone.
I came in late and helped finish one of those severely troubled projects where there was a huge amount of blame to go around. Scrum and Kanban concepts were being used by teams involved, but a lot of people on my team including the boss and star programmer would not do what scrum required. My boss would bitch me out for making "rediculous" estimates of 4 hours to do something that involved a 45 minute build process and I wondered how the other people on the team didn't have this and I found I was the only one who was serious about estimating and that the star programmer did not do it at all.
In the end we gave up on scrum and got heavy on checklists. We made a checklist with about 300 steps for a release process and it a was a stressful process but we learned how to do it reliably. Also we had a checklist of things to have done before the final release.
It was not pretty but we did cross the finish line and get the product in front of customers and they liked it, so I felt I did my part and felt free to move on when it was done.
Not to be pessimistic but this sounds like stories and tasks needed to be broken out in even finer detail.
If there is a piece of functionality that brings unfamiliarity to the delivery team then create a spike ticket to investigate (though use them sparingly).
If you break things down small enough, really understand your velocity and have a transparent relationship with your product owner then there should be no need for any stress from anyone.
2-3 hour backlog grooming sessions is a warning sign. Of what I couldn't say but maybe it is time to evaluate team size or how meetings are being conducted. Push as much stuff out of meetings as possible.
If you have a morale issue due to stuff slipping (and I suspect maybe you didn't capture everything in this post) then it may not be planned sprints that are the issue. Expectations that people have of themselves and of the team are something you are free to set. I think SCRUM tend to end poorly for developers because they are placed on top of dysfunctional systems of expectation that discourage many kinds of failure.
I am perfectly happy abusing SCRUM and letting things slip from sprint to sprint sometimes excessively. Fitting things into 2 weeks was a goal to gain the benefits of constrained scope and clearly articulated and designed implementations or requirements, but failure is something I made sure to embrace. Sure we had retrospectives to see what could be learned and what we could do better, but you have to be very careful to make sure it isn't second guessing or moving the goal posts. You shouldn't fault people pretty much ever as part of SCRUM, but definitely don't fault them for slippage. There should be next to no onus on an assignee for a task to prove they did the right thing.
IMO That kind of feedback comes best out of band on a very macro scale when there is a pattern of failure for an individual to address AND you must get buy in from the individual that there is improvement to be had. The reason I stress this is that I don't want people to try and avoid things that they might fail at. That pushes people away from important work that needs to be done.
I think that planned sprints and retrospectives are the 1-2 punch of SCRUM. By estimating what you should be capable of you are then capable of reasonably identifying WHY you didn't achieve that and trying things until there is improvement or you establish that the estimates are wrong. SCRUM without high functioning retrospectives is missing 50% of the goodness IMO.
It's great that you kept regularly scheduled meetings. There is a huge amount of buy in, knowledge sharing, and consensus you get for relatively low cost by having regularly scheduled meetings. With small enough teams you can get it all done with one hour long interrupt per week. Socially it's also good because it discourages backroom deals, planning, and cliques which are toxic. Doubly so if you have remote workers.
It should be sufficient for someone to lead and assign tickets as they come in, and for people to talk to people and reassign them as needed.
Again, if you need status on something, don't have a 2-3 hour long meeting, just ask... because when you have a long meeting and only 2 people out of, say, 8, are engaged at the same time, those other people are being very expensive and are getting bored fast.
The team's velocity is what it is - retrospectives can be boiled down to a "hey, how are things working out" that you can fit into a standard team meeting IMHO. Doesn't need it's own time slot, and this can also prevent retros turning into "throw X under the bus / CYA" type meetings. You can also get a lot of this from 1:1 conversations, and probably in greater depth in that context.
When I started doing work on a git-flow/feature branch basis, the sprints lost their value to me. I've begun to wonder if the sprints were simply an artefact from poor practices in old CVS/SVN workflows (like needing a short, regular stabilizition and release cycle)?
From the text, it seems like it's scrum, but without having a deadline every sprint for what you committed to at the start of it.
And... that sounds exactly like the Pivotal school XP I've been doing for 10 years.
Words, words, words...
Kanban works best when tasks are explicitly prioritised against each other.
There are multiple titles that come up on an Amazon search, all with similar review scores.
What books/resources would people recommend to learn Kanban effectively?
'Smart people learn from their mistakes. But the real sharp ones learn from the mistakes of others.'
Well, I was not disappointed. The articles talks about everything, except anything marginally related to the meaning of "kanban" in manufacturing.
It works by tokens that "pull" the production from other productive unities that are ultimately "pulled" from external (client) demand.
The article talks about all kinds of rituals and gains, but never once touches that "pulling" activity that is central to the concept, nor the lean objective.
https://en.wikipedia.org/wiki/Kanban
There's a link to Toyota's site at the bottom, as the inventors, they have plenty of authority on it.
Wikipedia has also an article about Kanban in software development. As expected, the introduction does not even make sense, but the methodology section contains a form of continuous improvement, what could work. Also, I could not understand how any of the experiences related on the article could come from the Wiki's methodology - it has probably no relation at all with was implemented at the author's place.