Ditching Scrum for Kanban - The best decision we’ve made as a team(medium.com)
medium.com
Ditching Scrum for Kanban - The best decision we’ve made as a team
https://medium.com/cto-school/ditching-scrum-for-kanban-the-best-decision-we-ve-made-as-a-team-cd1167014a6f
117 comments
You get a quick status update of all the bits everyone is working on.
>> 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.
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.
If you were waiting on Bob to finish xyz, why does he wait up to a day before telling you he's done?
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.
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'm not sure I was waiting for bob, I probably have other tasks too.
I don't know of a better alternative that maintains the face to face element.
I don't know of a better alternative that maintains the face to face element.
The point is: are you really interested in what those people are working on? If you are, then you should communicate with them much more often than once every 24 hours, or have decent conversations with them. A few seconds aren't enough anyway. If you're not, then scrum is a frustrating waste of time.
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.
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.
>> The point is: are you really interested in what those people are working on? If you are, then you should communicate with them much more often than once every 24 hours
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.
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.
I prefer ditching standups in favor of constant communication, people should know who they need to talk to and avoid waiting for specific checkpoints.
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.
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.
As I said to the other response like this, I dislike team meetings as without strong leadership (something I have found lacking in a lot of places) it usually degenerates into an hour or more of griping and grandstanding.
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.
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.
Yeah, those could be bad. I've always seen it done with strong team leads or technical managers when they existed instead of standups. I have seen that devolve though, and I know what you mean.
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.
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.
> It should take no more than a few seconds per person and I find it far more effective than any agile status tool I've used, be that a physical board or an online system.
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.
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.
Personally I hate weekly meetings as, unless you have strong leadership (rare) they turn into long, boring gripe-fests.
Yes thank you. I think the reality of DSM don't live up to their theoretical usefulness.
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 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 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'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.
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.
If you have a long important task, then surely you can break it down into sub-tasks that take less than a day to implement? Not just for the sake of having something to say in the daily status meeting, but to be able to manage your own work and evaluate your progress? In my own work, I find that anything taking longer than a day benefits from my doing some planning and task breakdown.
If it's possible, sure, but you always get these problems you never predicted where you burn hours getting nowhere. I really meant a task that turns out to be unpredictably lengthy, annoying and tricky.
Pretty often it's also a sign that Scrum and DSMs have been imposed on the team by their managers and/or PMs. Scrum is meant to be a tool for the dev team to self-organize. When it's not a bottom up effort (coming from the dev team based on their actual needs) it devolves into a micromanagement framework.
You need to tighten up your standups. Each person should be saying what they did yesterday, what they're going to do today, and identify any dependencies or blockers.
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.
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.
> You need to tighten up your standups. Each person should be saying what they did yesterday, what they're going to do today, and identify any dependencies or blockers.
Why do this in a standup though? This information isn't on your planning board? I don't find standups efficient for this.
Why do this in a standup though? This information isn't on your planning board? I don't find standups efficient for this.
There is a unique motivating factor to standing in front of your peers and saying you didn't get anything finished yesterday. That is, in my opinion, the entire point of the stand up. Everyone knows they are going to have to say something tomorrow and that adds some impetus to finishing their task as quickly as possible.
It adds impetus to appear busy and/or find something to report. I think it was said higher in this discussion: recurring meetings are a form of "social engineering"; and I'll follow that with an assertion that they have more affect on the structure of the team (and individuals therein) than they do on the effort the team is nominally working to achieve.
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.
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.
I think motivating factor is the least helpful thing stand ups provide so your assertions are slightly correct if that was the goal of stand ups.
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.
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.
"better communication" and "cross training" are the biggest misconceptions about the stand-ups. A good/proper standup is short and there's no way to communicate and exchange enough detailed information and context to make it a meaningful communication and especially cross training tool. Standups are meant for peer-to-peer coordination on the dev team. This leads to another misconception... Standups are not status reports for managers. The manager's primary job is to support his/her team and to be aware of what's going on to facilitate the team needs and to resolve external blockers. Sitting in his/her ivory tower planning stuff is not it :-)
If the dev team isn't coordinating and communicating outside the meeting, then you have problems the meeting isn't going to solve.
I do agree with you that a manager's job is to support the team, and not the other way around.
I do agree with you that a manager's job is to support the team, and not the other way around.
1) Better how? For whom? What's your metric on that and does it hold true in all circumstances and contexts? I'd make a general assertion that "better" communication is written communication as it is more easily reviewed later and by parties not originally involved. An asynchronous persistent communication channel beats a synchronous one when you need to coordinate non-synchronous activity (which often involves coordinating with external teams and stakeholders).
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.
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.
I think stand-ups are valuable, but not for this reason. It is simple to exaggerate the unexpected difficulties of a task. You can watch videos on YouTube all day today and tomorrow say, "Yesterday I worked on auto frobbing widgets but ran into difficulties with the foo widget because it didn't frob correctly. Today I'll be fixing the foo widget and completing the auto frobber".
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]
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]
Interesting conversation, I appreciate it.
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.
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.
Sounds like being treated like a school kid to me
Because some things just pop up during the conversation.
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.
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.
Plus the real sharing of knowledge happens in ad hoc meetings outside of the standup when people talk about details of the issues-- things you can't talk about in the standup.
One thing is you can have a conversation about things and ask questions about what you're stuck on.
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.
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.
No, at the standup you shouldn't have conversations about things. You should just do a quick recap of what you've been doing and what you'll work on. It's a standup because it's meant to be very quick.
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.
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.
It should not turn into long discussions, but if standup is for mentioning what you're stuck on, it seems really strange that others are forbidden from mentioning how to get unstuck.
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.
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.
Are you blocking a whole bored and standing team to get help from a workmate on an issue that is relevant to you only? I hope not. I think the Agile orthodoxy prescribes that any conversation that lasts more than a few tens of seconds should be saved for after the standup. And it makes sense. However, if you were stuck on something, then you've probably been for some time before the standup. So I guess you had plenty of time to ask that knowledgeable team member before.
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.
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.
Yeah, a few tens of seconds is all I'm talking about too. We may differ mostly in terminology.
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.
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.
I find that many of the colleagues who spend the day with earphones on are regularly available on chat. Isn't that a much better way to communicate rather than assume your problem is the most important and worth disrupting other people from their work?
Yes but either you don't know what they're talking about (different part of the project), or already know what they're talking about (because you are a tight team). So, zone out. Who's the Punch and Judy show for?
At least where I work (Pivotal) where we are often rotating between pairs, and changing tracks of work in the order of every day to every few days, being kept up to date on the state of the rest of the work is useful.
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.
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.
> where we are often rotating between pairs, and changing tracks of work in the order of every day to every few days
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.
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.
you are in between those 2 extremes and standups are useful?
Right - some fraction of the team isn't zoned out, sure. Maybe working on the communication skills of those remaining ones is a better idea, than derailing everybody for a standup.
No matter how tight you make the stand up, it still creates an artificial time to do a disruptive start/stop. A 5 minute meeting really leads to close to an hour of derailment. http://paulgraham.com/makersschedule.html summarizes it better than I ever can.
If your team communicates effortlessly with each other and the stakeholders anyway, you don't really needs scrum, at least not now. But most places where scrum has made a difference, individual maker productivity is not the limiting factor, so even an hour of disruption is worth the cost.
Usually it's the managers who find it helpful - for them. Getting verbal confirmation from everyone of what's on the board.
The value is in creating a summary, to collect all the stream of conscience updates into a coherent statement about status and next steps. A daily standup of summaries removes the burden of mentally remembering yesterday's minutiae to reconstruct the current state.
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.
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.
>Scrummerfall
My classically trained PM after taking an Agile training class:
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...Having seen some of how the sausage of dashboards get made, you go look at the real data, not the fancy crap that is thrown on the dashboard to sell the product in demos...
My current team does not do standups (or Scrum or... any of these things, really). We have a rolling list of open features/cleanups/bugs and a polite triage convention. In my last company we were all-in on what I can only call Scrummerfall.
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.
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.
> I find most people zone out during the standup
Out of curiosity, how long do your standups last? How big is the team?
Out of curiosity, how long do your standups last? How big is the team?
15 (goal) minutes with a 10 person team.
Everybody didn't zone out every day, but most did, most of the time.
Everybody didn't zone out every day, but most did, most of the time.
It's also detrimental to morale when you realize that other people are zoned out through standup. Nothing much more frustrating than when a coworker asks a question that was answered in the "meeting" we were all just in.
Frankly, it's a huge opportunity for the listeners to shine. (Yay for being a listener)
Frankly, it's a huge opportunity for the listeners to shine. (Yay for being a listener)
Exactly. It's a waste of time. Best to give a direct message or face-to-face telling the person what they need to know. Or not say anything if nothing is needed. At most, I'd say weekly meetings that were a mix of tracking project status and fun just for team-building purposes. Keeping people connected.
I'm a project manager/scrum master, with a team that varies from 6 to 12 (roughly half the team is semi-permanently on-loan to other related projects/teams).
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.
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.
I've found this with big and small teams. With small teams you already know what everyone is up to and with larger ones the meetings go on for longer.
You want people to elaborate on the concept that standups "keep people aligned on the work"
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.
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.
I think the standup meeting is there because it follows the first principle of the Agile Manifesto:
"Individuals and interactions over processes and tools"
"Individuals and interactions over processes and tools"
I thought that the scrum meeting is a process. The whole Agile thing is a strictly defined process. That needs a lot of specific tools too.
Correct, Agile is a development process. As for needing tools, at least scrum doesn't need anything more than pen and paper to generate its artifacts: 2 lists (backlogs) and a chart (burndown).
> Perhaps Kanban is better suited towards long-lived product development than Scrum.
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.
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.
I completely agree with this.
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.
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.
Kanban was invented at Toyota in the '40s and '50s: https://en.wikipedia.org/wiki/Kanban
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.
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.
My experience too. A short deadline (few months to a year) and a green new codebase is a good place for scrum.
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.
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.
Was the author's team just totally lacking a leader who could point out the patterns in underestimating the scope of work. If you are consistently missing your estimates, you adjust. Get to a point where you are consistently under-promising, and over-delivering. Morale problem solved. It's not rocket science.
That said, I agree that regular timelines aren't the only way to create a sense of urgency in your team.
That said, I agree that regular timelines aren't the only way to create a sense of urgency in your team.
It's not that easy.
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.
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.
Estimation is just educated guessing. If you were guessing a non-randomly generated number, and you found you were guessing high every single time, wouldn't you eventually try reducing by orders of magnitude?
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.
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 love this. We briefly flirted with scrum but now just have a much more Kanban-like system now, too. The only issue I foresee long term is that the sprint mentality of Scrum might recharge people and get them to, well, sprint, at product goals. Kanban, because it is never ending, might start to feel like a slog. There is never a way to have that feeling of "wow, we crushed it and cleared out our list. We are awesome." The list just extends forever. We have put measures in to help with this: primarily just having our engineers say at the beginning of the week what they hope/plan to get done this week (or two). Sometimes that is just noting subtasks in pursuit of a larger feature, but at least it borrows some of what is a very powerful part of Scrum: the social commitment that comes from standing up and saying "this is what I will finish this sprint."
I see it the other way round. We're doing Scrum (ish, I guess) right now, and the see-saw between either ending a sprint with a couple of late-night panic sessions to get everything out of the door, or ending it with most of the team kicking their heels with one pair still going up to the deadline is what feels like the slog. I see Kanban as much smoother: I don't see artificial, self-imposed crunch mode every fortnight as a positive. It's all very well aiming at a social commitment, but the way it works in practice is either a) you under-estimate and have dead time; b) you over-estimate and crunch; or c) you nail it and one sprint runs smoothly into the next. The trap is that c) never happens.
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.
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.
The crunch approach to sprints is the killer. If you know you can't complete all the work in a sprint the answer should not be to bust yourself to try and complete it. Have a conversation with yourselves and the product owner to readdress what you can realistically achieve in the time remaining and then do that.
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.
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.
Aligns with my experience. We're always continuously delivering, with madeup goals stuck in to align with arbitrary sprints. The real activity takes as long as it takes. Sprints are a stilted reporting structure, adding drama but little real value.
...ending a sprint with a couple of late-night panic sessions to get everything out of the door...
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.
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 that case, do you use retrospectives at all ? if you dont have a goal post, then how do you retrospect.
Our crew use a Kanban approach, and to counter the 'slog' mentality, we have a retrospective every 2 weeks. I find that it really helps air what good we've done, and where we could improve. If we've accomplished a lot it's a great place to reflect and think positively.
I really like this idea. We groom our Kanban board, which creates a similar effect, but not so explicitly.
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.
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.
Waiting for this title: "Ignoring waterfall and agile fads while sticking with Boehm spiral model (1986), good management, minimal meetings/paperwork, regular code reviews, and usage-driven testing. Best decision I ever made."
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.
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.
+1. I was taught this as a young lad at Intel by a graybeard who'd been developing since the 60s. It made a lot of sense then, and it makes a lot of sense now.
I really like KanBan and think it's a better fit for a lot of teams than SCRUM is. SCRUM works great for teams which have a stable backlog of work and an incidental problem that might pop up. If you can't keep a backlog stable for three weeks, you shouldn't do scrum. KanBan allows you to pick and choose practices from scrum that do add value, and ignore the ones you are just doing to follow the book.
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.
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.
If you can't keep a backlog stable for a few weeks then you aren't doing project work you're on support or firefighting. Scrum is all about IT project work, Kanban is a more general "efficiently get a pile of tasks done" process which can apply to small IT tasks or building a car.
Depends where you are in your product lifecycle. Pre-product market fit, it's often a bad idea to build and keep a stable backlog a few weeks in length.
The context and mode defines your process: agile, lean or six sigma. Most companies have no clear understanding about their context (should read Simon Wardley [1]) or mode.
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
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
Any text links? Thanks.
Simon Wardley blogs at http://blog.gardeviance.org/
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)
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)
thats' a very interesting blog on strategy. Thanks for that - the only problem I see is that the "settlers" analogy has no real life mapping (unlike Pioneers <-> scrum and TownPlanners <-> six sigma).
As someone in similar circumstances a couple of things jump out which trouble me:
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...
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...
One of the biggest problems with Scrum (as mentioned in other comments) is that in a lot of large companies you have strong top-down enforcement of budgets, deadlines & expectations, which usually means the PMO is in control. This means you end up with a project manager as an awkward intermediary between the stakeholders & the product team. In almost every case, the product owner should be the project manager, but this very rarely happens in enterprise, and Scrum fails.
I agree with that assessment except for "the product owner should be the project manager". I do internal dev so product owners are from the business and know the problem domain and (with our help) know what they want.
It's going to be different for software for selling - but still, the project owner should be the person with the vision who is the "single wringable neck", they should be responsible for negotiating on budget, deadlines etc.
The job of being a PM is always going to be in tension with that of the PO, I can see them forming a good team but fundamentally the PM is the representative of management imposed from above.
I should have been clearer. I meant the tech-side PO. There has to be a PO in the IT org If there isn't, the product will languish under the weight of mounting technical debt and eventually die. The same often happens if there's no biz-side PO, but in those cases someone from the tech org usually adopts the product and just does their best, for better or for worse.
The team I was previously on tried to use Scrum and seemed to naturally fall into a similar model to Kanban; we got rid of what helped, and stopped doing what didn't. It was an amazing relief, especially since Scrum sprints and the numbers just weren't working.
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.
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.
It is really stupid to NOT allow any team choose its own process. Your scrum leader is not a wise person, to put it lightly.
I think the most frustrating part was that I explained we had tried Scrum and adapted it for our team's needs. We weren't anti-Scrum, we just found a way to make it work for us. I was then told "[Company] is a Scrum company. We all use Scrum as it is" and was brushed off. Same Scrum leader would yell at the operations team for failing to complete sprints in time when servers fell over, and other nastiness that becomes the priority when you work in a position where you prioritize server health and function over new builds and features.
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. :)
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. :)
I think the value of Scrum is that it provides great visibility into development for stakeholders. They can see the progress of the backlog and know what's being committed to every sprint. It does put some artificial boundaries on work getting done, but I think it strikes a good balance between pure agile and keeping business happy.
Remember the triple constraints of cost, scope and time. If you are going to commit to releasing at a certain time you are going to have to let the scope slide. (Sometimes you can add more people on a 2 week basis but the ramp up time makes it usually impractical.)
And this is exactly the difference between Scrum and Kanban. Scrum fixes the time periods and allows for adjusting scope, by cutting stories and features. Kanban fixes the scope while allowing the time period to be open-ended. Which methodology is more appropriate depends on which constraint a business wants or needs to optimize for.
It is even better to do something hybrid that is tuned to the application.
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.
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.
There is a fourth one - quality. It is important to acknowledge its existence, otherwise you can find yourself in a position where you can alter "all 3" constraints for the better at the cost of a hidden fourth one.
> Say what you want about our supposed inability to estimate, but I challenge any team to nail estimates within a 20% margin for a large feature on a large app.
Not to be pessimistic but this sounds like stories and tasks needed to be broken out in even finer detail.
Not to be pessimistic but this sounds like stories and tasks needed to be broken out in even finer detail.
I think that's a fair assessment. If people can grasp creating small independent deliverables for their projects (of any size) then things become a lot easier to estimate. Monitor velocity and pull less into future sprints if you're still getting it wrong.
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.
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.
We've used Kanban (or something like it) for 20 years. Long before Kanban existed as a thing. Near the end of a project, we'd draw up the "finishers' list" with numbered items and initials next to each. Daily team review of each remaining item, reassign priority or responsibility as needed.
It sounds like you got a lot of positive things out of it. Which is great. Also great that you are iterating and not sticking to what the coach gave you. My take on what made many elements of SCRUM work for me follows.
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.
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.
That long grooming session IS a warning sign. I recall working for one disaster where we were required to have one grooming session for us (1 hour) and then it got re-groomed the same week where we heard all the tickets again.
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.
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.
I've preferred Kanban for a while now.
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)?
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)?
I read this article hoping to learn what "kanban" really is.
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...
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...
The commonly understood aspects of Kanban is that it is a pull (team members assign themselves work based on priorities) system that has a 'work in progress' limit - ie the most number of items a team/person can work on at once. If something urgent comes up that needs working on right now, something else will need to go back on hold.
Kanban works best when tasks are explicitly prioritised against each other.
Kanban works best when tasks are explicitly prioritised against each other.
Scrum is supposed to be about regular feedback and sustainable pace, not motivation.
Can anyone recommend a good, concise book on Kanban in software - preferably without mingling in Scrum?
There are multiple titles that come up on an Amazon search, all with similar review scores.
There are multiple titles that come up on an Amazon search, all with similar review scores.
Would people recommend a team moving directly to Kanban, or is it useful to learn/use Scrum first?
What books/resources would people recommend to learn Kanban effectively?
What books/resources would people recommend to learn Kanban effectively?
>is it useful to learn/use Scrum first?
'Smart people learn from their mistakes. But the real sharp ones learn from the mistakes of others.'
'Smart people learn from their mistakes. But the real sharp ones learn from the mistakes of others.'
I was curious to understand what exactly software managers were calling by "kanban" now that the name is fashionable.
Well, I was not disappointed. The articles talks about everything, except anything marginally related to the meaning of "kanban" in manufacturing.
Well, I was not disappointed. The articles talks about everything, except anything marginally related to the meaning of "kanban" in manufacturing.
Can you elaborate?
In physical production (where it comes from), kanban is a lean method for ensuring that you don't spend on producing right now something that is not needed right now.
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.
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.
Thanks. I'll confess to being a Kanban noob. Do you have any resources that you can share? Looking with Google seems to present more of this sort of article.
Wikipedia has a surprisingly good explanation:
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.
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.
This really resonates with me. My experience with scrum was very similar, and I thought Kanban might be a nice answer to the arbitrary deadlines that frustrated me. Never got a chance to try it, though.
Waiting for the follow up post on how he's ditching kanban for X next.
Wampaku has worked out very well for my team.
Sounds like they're about to throw out Kanban in favor of quitting
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.