8 ms·

Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure.

by gbro3n 4y ago

Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2 weeks.

brightball 4y ago
Wrote extensively about this a few years back and it generated a great discussion here. https://news.ycombinator.com/item?id=17154355 https://news.ycombinator.com/item?id=17154355
LtWorf 4y ago
In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out. Also all the sprint planning and retrospective took basically 30% of our time.
- haasted 4y ago
  Shouldn't that lead to a team discussion about why the estimates differ so drastically? In most circumstances, the reasons would be inaccurate assessment of scope or complexity. Clearing up misconceptions like that can be a great boost for productivity. "Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."
  - LtWorf 4y ago
    It did. I said I would not stop doing it until he'd stop. So we just continued this way.
  - steveBK123 4y ago
    It inevitably does and then everyone slowly starts estimating everything at the middle point size in the agreed spectrum, with only 2-3 outliers
  - acdha 4y ago
    Theoretically, yes, but if you’re spending half of your time on process overhead there isn’t much left to do that well and most of the time there’ll be enough differences from sprint to sprint that it’s plausible that this time was late for other reasons, until you have a sufficiently long data set to show that it’s a trend.
  - throwaway284243 4y ago
    > "Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach." Next performance review, your manager goes: It seems like you're not really aware of a lot of techniques of how to solve problems efficiently. Maybe you should do more pairing with the other seemingly much better developers to strengthen your skills. And now you've cornered yourself as a junior for the next 2 years, who was "hired on the wrong level". All of this is assuming that the team members will prioritise the performance of the team higher than their own performance, of which there are no incentives. The incentives is to make yourself look as good as possible (don't admit your idea is inferior), and skew the playing field to your advantage (insist on using the tools you know best) etc. People simply don't spontaneously cooperate and simply don't "just get along" in a situation like this. Even in hippie communities where everything is voluntary and there is no personal gain to be had, it still falls apart because some people just don't cooperate. So how do you expect that to happen in a situation with money involved, and competition between people? Why do the software industry and scrum think they have spontaneously discovered how people always just get along, inside a basic weekly planning schedule? That would literally be a nobel peace prize right there.
- gbro3n 4y ago
  Agreed. The differences of opinion during estimating are another form of pressure. Programmers work differently. I might estimate a task longer than a colleague, but I might be the type of programmer who tidies up and refactors along the way, or who spends more time communicating with the team on strategy and architecture. These are hard to quantify behaviors that Jira can't effectively track, unless you're going to spend half your day _in_ Jira writing down every action every day. Don't event get me started on the effect of context switching. Managers are pushed to produce reports to prove they're managing. Reports require metrics, and that's a lot of where all this rubbish starts. The solution in my experience is to keep teams small enough that you don't need those sorts of layers of management (though the opposite is inevitable in larger companies).
- denton-scratch 4y ago
  Estimates should be made in abstract units (e.g. 'function points'), then converted to man-days or dollars or whatever using a scaling factor specific to the estimator. That way, the actual value of the estimate is moot; it's the consistency of the estimates that counts.
- pevey 4y ago
  I find it challenging to estimate my own time in tasks. Part of every task is figuring out how to actually do the thing you are wanting to do, and sometimes that takes 5 minutes and sometimes much longer. So I am terrible at estimating my own time, and even worse at estimating someone else’s. It doesn’t add pressure to a person if you give them a time goal they know is basically arbitrary.
  - LtWorf 4y ago
    That means the task is underspecified. You should schedule a "figure this out" instead, and once the task is well defined it can be done.
    - pevey 4y ago
      You never know if you have really completed the "figure it out" task until the "get it done" task is completed.
    - yucky 4y ago
      A meeting to plan for the meeting. Instead of turtles, it's meetings all the way down.
      - LtWorf 4y ago
        I never said a meeting. That says a lot about you :p
  - nobodyandproud 4y ago
    Software estimation is very hard. This is what scrum (done well) helps with. Unless the software was horribly written, it’s usually easy to estimate effort for very modest, well-defined changes. Take a large enhancement or overhaul, however, and estimates will be wildly off and it’s because of the iceberg effect of unknowns. What scrum forces the inexperienced teams to do is start breaking down, plan and incrementally chip away at a ill-defined, large request by turning it into many smaller and better understood deliverables. It’s what very good teams do, though they do it without the need for formality.
- pwinnski 4y ago
  How does something like this take 30% of your time? On my calendar it's two hours out of 80, or 2.5%. One hour per sprint for planning, one hour for retro, why would it be longer? My team lead spends more time prepping tasks with the PM prior to sprint planning, but even then it's about 5%. My last company, we had one-week sprints, but we didn't do official retros, so it was still 2.5%, one hour of planning for 40 hours of work.
  - pwinnski 4y ago
    Sprint planning today took 26 minutes. The Retro yesterday was 30. So that's less than 1.25% of my time spent.
stingraycharles 4y ago
Sprints and planning are useful for organizations that attach a lot of value to planning and deadlines. It creates a lot of additional work and pressure, as you say, but I can also imagine that for certain types of organizations that may be worth it (eg when doing client work on a fixed budget with strict deadlines). Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses on prioritization and flexibility rather than planning and burndown charts and whatnot.
- throwaway4aday 4y ago
  You can value planning and deadlines and still not do sprints. The key is that whoever is managing the project, whether it's a dedicated PM or just the lead dev, needs to be fully engaged with the team and understand the work that is being done. Cards (beyond a basic todo list and record of who's doing what), points, sprints, standups, backlogs all of these are symptoms of bad communication and a lack of an overall understanding of the project. Unfortunately, or fortunately if you can put it in to practice, this means that the person leading/managing the team needs to understand software development as well as the current tech and tools being used. There is a place for non-technical managers but it is outside of the software development team where they act as an interface between dev and the other departments or interests in the company.
- closeparen 4y ago
  If you place a lot of value on planning and deadlines, you should probably embrace that wholeheartedly, and not try to pretend to be “agile.”
- bluGill 4y ago
  Kanban is still better than sprints. You organize things that are most important at top, and what is done by the deadline is done and ships; what isn't done doesn't ship. Deadlines may mean you branch so can make the release stable, while feature work that clearly won't be done one time can continue if the team working on it isn't involved in the release. It doesn't matter if you have sprints of kanban, if there is a deadline is project managers need to do the same work to verify things are progressing fast enough for the release. This work is estimating how much time remains, and if there isn't plenty take action. The plenty part is where most management goes wrong: they want everything done on time, but the only way to get that is have everything done early. That in turns means you need to have at least 20% (the higher the better) of the things planned for your deadline things that you are willing do allow to slip to the next release. Of course working against that is the human tendency to polish things until the last minute, but that shouldn't be managed by the deadline (even though it often is) I'm against the web release early and often model - don't make your users your beta testers. I'm in favor of spending several months of test after the branch to ensure everything is stable even though this is a lot more expensive. I do agree with the web have automated tests for everything model, I just don't think automated tests alone are enough quality control - automated tests ensure that everything you can think of didn't go wrong, manual testing is about noticing things you didn't think of. (you will note I work in an area where my code can kill people)
polotics 4y ago
KANBAN is good at ensuring you do not have too many themes on your plate at the same time. Producing effort estimates is one of the many approaches to start talking about a task, and not doing it may mean that somebody else's better idea on how to tackle it gets ignored. Having sprints is a good way to coax people in fully finishing things, it is often needed as many developers tend to jump to the next shiny. If any of these three things gets used by a bad manager to get fake importance, to put pressure, push people down instead of pulling them up... then get rid of that manager.
- ozim 4y ago
  From my experience sprints ensure that stuff is "good enough" and pushed out the door. Like QA having idea that some icon is not aligned - but yeah it is end of the sprint close it and fix in next iteration and get to work on other thing that has priority now - not aligning some unimportant details. So sprints are also good way to coax people into cutting scope instead of working till it is "perfect". Then pushing back on management to have breathing space and accepting changes only after sprint ends and not when they have a brilliant idea. Sprints and ceremonies create touch points for business people to interact with dev team instead of constantly breathing on their neck or coming up with ideas. Business using JIRA and writing stories/tickets should make sure there is enough context in these so your tickets are living documentation "who,why,where".
- 29athrowaway 4y ago
  Don't capitalize words that are not acronyms. It's just a 5 letter word, it's not that difficult.
  - quesera 4y ago
    > It's just a 5 letter word, it's not that difficult. Beware the careless pedant!
    - polotics 4y ago
      カンバン then!
kixxauth 4y ago
I think the point of the OP is missed here. Productive teams don’t need any of this garbage; least of all a religious war about methodologies. Productive teams are primarily hackers solving larger problems. This stuff gets in the way, causing the team to morph into developers instead.
- sillyquiet 4y ago
  So... developers aren't productive? This is a weird take.
  - kixxauth 4y ago
    Yeah, good point. If productivity equates to value creation then hackers are more productive. If productivity equates to what software management can measure, then developers are more productive. I’m making a pithy statement about the difference hackers and developers
    - sillyquiet 4y ago
      I gotta say that your distinction between 'hackers' and 'developers' is pretty ill-informed - just out of curiosity, have you primarily worked in start-ups?
- drstewart 4y ago
  This has a real "no TRUE Scotsman" vibe
steveBK123 4y ago
Yup, that was the overall vibe at my last place. Sprints are too micro and lead to tunnel vision. Got a lot of stuff done, but the hard tickets were always underestimated & dragged across sprints. And was it the "right stuff" to be working on to start with? Everyone felt like we were failing even as we got a lot of stuff done. Additionally, despite the attempt at predictability, wider project management was lacking, which lead to cross-team long running projects running over by 100-200%. Often this was failure to capture actual requirements, making generous assumptions that a vendor would provide a magic bullet, allocating little to know time for integration / cross team work, etc. Each team worked on the tickets in their sprint, from their backlog, according to what product management wanted. The fact that none of it tied together at the end was not devs fault if you want to institute such a tunnel vision process on them.
- xxs 4y ago
  > tickets were always underestimated Teach the developers who estimate them to treat the process as the circle circumvent instead of the diameter and multiple by Pi. There you go - done.
  - steveBK123 4y ago
    Many tickets were also overestimated! They just don't stick out as a problem since they close early and make the sprint look good. Naturally, the ones that don't close are the ones that are underestimated! If you overestimate everything then you end up idle at end of sprint & picking backlog items to bring in, so then product wants to put more points/stories into next sprint. The system is seemingly designed to produce this outcome.
    - StevePerkins 4y ago
      This folds in with the mantra of "Do NOT think about blockers and interruptions when estimating your story points, only think about the task in a vacuum"... and then not looking at blockers and interruptions when judging your velocity and results, either. The system is to teach everyone how to lie and juke the system. It feels awful working in most sprint-based environments. Because even when you're highly productive it still feels like you failed in multiple places, and it always feels like you're being dishonest and have no real choice about it.
pelasaco 4y ago
After working with many methodologies, I think the most important thing is: regardless of which methodology you team is using, stick to the rules and deviate as less a possible from that, otherwise after some years, nobody understands the methodology in place, and people have real issues to follow it.
pjmlp 4y ago
On my experience Kanban only works for IT kind of tasks, where each ticket is an isolated action, instead of a small step to a bigger goal.
twic 4y ago
Every competent agile team i've ever been on ended up with vestigial sprints / iterations. There might be a weekly rhythm to meetings, but there is a continuous flow of stories, commits, and releases. Why on earth would you do it any other way?
RamblingCTO 4y ago
If you do scrum properly you shouldn't have a lot of meetings for "planning and ceremonies". We follow "scrum and xp from the trenches" quite closely. We have four meetings: - scrum planning (max 1h/week of the sprint)* - dailies (max 15 minutes per meeting)* - demo (we like to call it sprint review, because it's interactive, not one-sided). takes about 30 minutes - retro (takes an hour) *most of the times we use a lot less So we have 2h of meetings in the first weeks, 2.5h of meetings in the second week if you do a two-week sprint as we do. the rest of the meetings is rather "working together" than having "meetings". If you have much more hours in meetings than this (which can be attributed to scrum) you're simply doing it wrong.

by gbro3n 4y ago

brightball 4y ago

Wrote extensively about this a few years back and it generated a great discussion here. https://news.ycombinator.com/item?id=17154355 https://news.ycombinator.com/item?id=17154355

LtWorf 4y ago

In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out. Also all the sprint planning and retrospective took basically 30% of our time.

haasted 4y ago
Shouldn't that lead to a team discussion about why the estimates differ so drastically? In most circumstances, the reasons would be inaccurate assessment of scope or complexity. Clearing up misconceptions like that can be a great boost for productivity. "Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."
- LtWorf 4y ago
  It did. I said I would not stop doing it until he'd stop. So we just continued this way.
- steveBK123 4y ago
  It inevitably does and then everyone slowly starts estimating everything at the middle point size in the agreed spectrum, with only 2-3 outliers
- acdha 4y ago
  Theoretically, yes, but if you’re spending half of your time on process overhead there isn’t much left to do that well and most of the time there’ll be enough differences from sprint to sprint that it’s plausible that this time was late for other reasons, until you have a sufficiently long data set to show that it’s a trend.
- throwaway284243 4y ago
  > "Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach." Next performance review, your manager goes: It seems like you're not really aware of a lot of techniques of how to solve problems efficiently. Maybe you should do more pairing with the other seemingly much better developers to strengthen your skills. And now you've cornered yourself as a junior for the next 2 years, who was "hired on the wrong level". All of this is assuming that the team members will prioritise the performance of the team higher than their own performance, of which there are no incentives. The incentives is to make yourself look as good as possible (don't admit your idea is inferior), and skew the playing field to your advantage (insist on using the tools you know best) etc. People simply don't spontaneously cooperate and simply don't "just get along" in a situation like this. Even in hippie communities where everything is voluntary and there is no personal gain to be had, it still falls apart because some people just don't cooperate. So how do you expect that to happen in a situation with money involved, and competition between people? Why do the software industry and scrum think they have spontaneously discovered how people always just get along, inside a basic weekly planning schedule? That would literally be a nobel peace prize right there.
gbro3n 4y ago
Agreed. The differences of opinion during estimating are another form of pressure. Programmers work differently. I might estimate a task longer than a colleague, but I might be the type of programmer who tidies up and refactors along the way, or who spends more time communicating with the team on strategy and architecture. These are hard to quantify behaviors that Jira can't effectively track, unless you're going to spend half your day _in_ Jira writing down every action every day. Don't event get me started on the effect of context switching. Managers are pushed to produce reports to prove they're managing. Reports require metrics, and that's a lot of where all this rubbish starts. The solution in my experience is to keep teams small enough that you don't need those sorts of layers of management (though the opposite is inevitable in larger companies).
denton-scratch 4y ago
Estimates should be made in abstract units (e.g. 'function points'), then converted to man-days or dollars or whatever using a scaling factor specific to the estimator. That way, the actual value of the estimate is moot; it's the consistency of the estimates that counts.
pevey 4y ago
I find it challenging to estimate my own time in tasks. Part of every task is figuring out how to actually do the thing you are wanting to do, and sometimes that takes 5 minutes and sometimes much longer. So I am terrible at estimating my own time, and even worse at estimating someone else’s. It doesn’t add pressure to a person if you give them a time goal they know is basically arbitrary.
- LtWorf 4y ago
  That means the task is underspecified. You should schedule a "figure this out" instead, and once the task is well defined it can be done.
  - pevey 4y ago
    You never know if you have really completed the "figure it out" task until the "get it done" task is completed.
  - yucky 4y ago
    A meeting to plan for the meeting. Instead of turtles, it's meetings all the way down.
    - LtWorf 4y ago
      I never said a meeting. That says a lot about you :p
- nobodyandproud 4y ago
  Software estimation is very hard. This is what scrum (done well) helps with. Unless the software was horribly written, it’s usually easy to estimate effort for very modest, well-defined changes. Take a large enhancement or overhaul, however, and estimates will be wildly off and it’s because of the iceberg effect of unknowns. What scrum forces the inexperienced teams to do is start breaking down, plan and incrementally chip away at a ill-defined, large request by turning it into many smaller and better understood deliverables. It’s what very good teams do, though they do it without the need for formality.
pwinnski 4y ago
How does something like this take 30% of your time? On my calendar it's two hours out of 80, or 2.5%. One hour per sprint for planning, one hour for retro, why would it be longer? My team lead spends more time prepping tasks with the PM prior to sprint planning, but even then it's about 5%. My last company, we had one-week sprints, but we didn't do official retros, so it was still 2.5%, one hour of planning for 40 hours of work.
- pwinnski 4y ago
  Sprint planning today took 26 minutes. The Retro yesterday was 30. So that's less than 1.25% of my time spent.

stingraycharles 4y ago

Sprints and planning are useful for organizations that attach a lot of value to planning and deadlines. It creates a lot of additional work and pressure, as you say, but I can also imagine that for certain types of organizations that may be worth it (eg when doing client work on a fixed budget with strict deadlines). Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses on prioritization and flexibility rather than planning and burndown charts and whatnot.

throwaway4aday 4y ago
You can value planning and deadlines and still not do sprints. The key is that whoever is managing the project, whether it's a dedicated PM or just the lead dev, needs to be fully engaged with the team and understand the work that is being done. Cards (beyond a basic todo list and record of who's doing what), points, sprints, standups, backlogs all of these are symptoms of bad communication and a lack of an overall understanding of the project. Unfortunately, or fortunately if you can put it in to practice, this means that the person leading/managing the team needs to understand software development as well as the current tech and tools being used. There is a place for non-technical managers but it is outside of the software development team where they act as an interface between dev and the other departments or interests in the company.
closeparen 4y ago
If you place a lot of value on planning and deadlines, you should probably embrace that wholeheartedly, and not try to pretend to be “agile.”
bluGill 4y ago
Kanban is still better than sprints. You organize things that are most important at top, and what is done by the deadline is done and ships; what isn't done doesn't ship. Deadlines may mean you branch so can make the release stable, while feature work that clearly won't be done one time can continue if the team working on it isn't involved in the release. It doesn't matter if you have sprints of kanban, if there is a deadline is project managers need to do the same work to verify things are progressing fast enough for the release. This work is estimating how much time remains, and if there isn't plenty take action. The plenty part is where most management goes wrong: they want everything done on time, but the only way to get that is have everything done early. That in turns means you need to have at least 20% (the higher the better) of the things planned for your deadline things that you are willing do allow to slip to the next release. Of course working against that is the human tendency to polish things until the last minute, but that shouldn't be managed by the deadline (even though it often is) I'm against the web release early and often model - don't make your users your beta testers. I'm in favor of spending several months of test after the branch to ensure everything is stable even though this is a lot more expensive. I do agree with the web have automated tests for everything model, I just don't think automated tests alone are enough quality control - automated tests ensure that everything you can think of didn't go wrong, manual testing is about noticing things you didn't think of. (you will note I work in an area where my code can kill people)

polotics 4y ago

KANBAN is good at ensuring you do not have too many themes on your plate at the same time. Producing effort estimates is one of the many approaches to start talking about a task, and not doing it may mean that somebody else's better idea on how to tackle it gets ignored. Having sprints is a good way to coax people in fully finishing things, it is often needed as many developers tend to jump to the next shiny. If any of these three things gets used by a bad manager to get fake importance, to put pressure, push people down instead of pulling them up... then get rid of that manager.

ozim 4y ago
From my experience sprints ensure that stuff is "good enough" and pushed out the door. Like QA having idea that some icon is not aligned - but yeah it is end of the sprint close it and fix in next iteration and get to work on other thing that has priority now - not aligning some unimportant details. So sprints are also good way to coax people into cutting scope instead of working till it is "perfect". Then pushing back on management to have breathing space and accepting changes only after sprint ends and not when they have a brilliant idea. Sprints and ceremonies create touch points for business people to interact with dev team instead of constantly breathing on their neck or coming up with ideas. Business using JIRA and writing stories/tickets should make sure there is enough context in these so your tickets are living documentation "who,why,where".
29athrowaway 4y ago
Don't capitalize words that are not acronyms. It's just a 5 letter word, it's not that difficult.
- quesera 4y ago
  > It's just a 5 letter word, it's not that difficult. Beware the careless pedant!
  - polotics 4y ago
    カンバン then!

kixxauth 4y ago

I think the point of the OP is missed here. Productive teams don’t need any of this garbage; least of all a religious war about methodologies. Productive teams are primarily hackers solving larger problems. This stuff gets in the way, causing the team to morph into developers instead.

sillyquiet 4y ago
So... developers aren't productive? This is a weird take.
- kixxauth 4y ago
  Yeah, good point. If productivity equates to value creation then hackers are more productive. If productivity equates to what software management can measure, then developers are more productive. I’m making a pithy statement about the difference hackers and developers
  - sillyquiet 4y ago
    I gotta say that your distinction between 'hackers' and 'developers' is pretty ill-informed - just out of curiosity, have you primarily worked in start-ups?
drstewart 4y ago
This has a real "no TRUE Scotsman" vibe

steveBK123 4y ago

Yup, that was the overall vibe at my last place. Sprints are too micro and lead to tunnel vision. Got a lot of stuff done, but the hard tickets were always underestimated & dragged across sprints. And was it the "right stuff" to be working on to start with? Everyone felt like we were failing even as we got a lot of stuff done. Additionally, despite the attempt at predictability, wider project management was lacking, which lead to cross-team long running projects running over by 100-200%. Often this was failure to capture actual requirements, making generous assumptions that a vendor would provide a magic bullet, allocating little to know time for integration / cross team work, etc. Each team worked on the tickets in their sprint, from their backlog, according to what product management wanted. The fact that none of it tied together at the end was not devs fault if you want to institute such a tunnel vision process on them.

xxs 4y ago
> tickets were always underestimated Teach the developers who estimate them to treat the process as the circle circumvent instead of the diameter and multiple by Pi. There you go - done.
- steveBK123 4y ago
  Many tickets were also overestimated! They just don't stick out as a problem since they close early and make the sprint look good. Naturally, the ones that don't close are the ones that are underestimated! If you overestimate everything then you end up idle at end of sprint & picking backlog items to bring in, so then product wants to put more points/stories into next sprint. The system is seemingly designed to produce this outcome.
  - StevePerkins 4y ago
    This folds in with the mantra of "Do NOT think about blockers and interruptions when estimating your story points, only think about the task in a vacuum"... and then not looking at blockers and interruptions when judging your velocity and results, either. The system is to teach everyone how to lie and juke the system. It feels awful working in most sprint-based environments. Because even when you're highly productive it still feels like you failed in multiple places, and it always feels like you're being dishonest and have no real choice about it.

pelasaco 4y ago

After working with many methodologies, I think the most important thing is: regardless of which methodology you team is using, stick to the rules and deviate as less a possible from that, otherwise after some years, nobody understands the methodology in place, and people have real issues to follow it.

pjmlp 4y ago

On my experience Kanban only works for IT kind of tasks, where each ticket is an isolated action, instead of a small step to a bigger goal.

twic 4y ago

Every competent agile team i've ever been on ended up with vestigial sprints / iterations. There might be a weekly rhythm to meetings, but there is a continuous flow of stories, commits, and releases. Why on earth would you do it any other way?

RamblingCTO 4y ago

If you do scrum properly you shouldn't have a lot of meetings for "planning and ceremonies". We follow "scrum and xp from the trenches" quite closely. We have four meetings: - scrum planning (max 1h/week of the sprint)* - dailies (max 15 minutes per meeting)* - demo (we like to call it sprint review, because it's interactive, not one-sided). takes about 30 minutes - retro (takes an hour) *most of the times we use a lot less So we have 2h of meetings in the first weeks, 2.5h of meetings in the second week if you do a two-week sprint as we do. the rest of the meetings is rather "working together" than having "meetings". If you have much more hours in meetings than this (which can be attributed to scrum) you're simply doing it wrong.