5 ms·

I really don't see why it has to be that way, and if people feel like that, there's something weird going on. If you've been given a large feature that involve

I really don't see why it has to be that way, and if people feel like that, there's something weird going on. If you've been given a large feature that involves, say, analytics, there is surely nothing wrong with your standup contribution being: "Yesterday, analytics. Today, analytics. Yes, I said the same yesterday, it's a big job, but it's going fine. Anyone can come over and ask me about analytics if they like! No blockers. Thanks." It tells people what you're doing and that it's broadly going ok. If you're five days into something that was supposed to take three days and you're actively embarrassed about this, then that's a problem - but it's a problem that should be discussed at the end of the third day with the stakeholders, not in the standup.

rejschaap 9y ago
The problem is you feel like you need to justify working on one thing for two days: "Yes, I said the same yesterday, it's a big job, but it's going fine." and, this is even more defensive, you feel people will not believe you so you invite them to see some proof: "Anyone can come over and ask me about analytics if they like!" Maybe the biggest problem is this though: "Yesterday, analytics. Today, analytics" This task needs to be broken up into manageable pieces badly.
- matthewmacleod 9y ago
  This task needs to be broken up into manageable pieces badly. This would also be my immediate thought as well. "Yesterday I setup integration with the analytics service. Today, I'm going to audit the places where we currently send analytics and see if it would be possible to centralise it – I'll share the results later". It's hard to track progress and estimate if your tickets are huge multi-week affairs.
  - bshimmin 9y ago
    Thanks one and all for the responses to my comment, which was written in some haste but seems to have generated useful discussion nonetheless. Just responding to this one, I would say that it really depends. If your task is implementing analytics and no one else on the team has anything much to do with it, then maybe it's best not to trouble them with the specifics. Your summary is much better, and only a few extra words, but if no one really cares about the analytics except to know that it's cheerfully in progress, maybe it's not all that necessary to go into more detail. This is definitely something you need to be wary of in a multi-disciplinary team. Also, I didn't mean "Anyone can come over and ask me about analytics if they like!" to sound defensive - it was actually more tongue-in-cheek! Here's another attempt: "I can't imagine why you would want to bore yourself with my analytics implementation, but please come over and ask me about it if you're having trouble sleeping at night." (I will freely admit that I am a confident person and would have no trouble saying something like that in front of a dozen people.)
  - sheepmullet 9y ago
    Is it really important to track progress on a day to day basis? IMO, only for a small minority of tasks. The vast majority of projects I've seen and worked on are measured in dev years of effort. My current project is well over a thousand dev years. In comparison a few days is meaningless. Most often it's a trust issue.
    - matthewmacleod 9y ago
      Is it really important to track progress on a day to day basis? It depends on the team. We find it useful specifically because we want to make sure we are estimating relatively accurately. Since we work in essentially 10-working-day periods, it's great to know when a piece of work we thought we could easily achieve is actually a blocker, or much more complex than we thought.
    - jakubp 9y ago
      A thousand man-years of effort? Sounds like a very large project. Just for contrast: I've been working for a medium size software house for the past 4 years. Typical project size is somewhere around 500 to 1000 man days. On that scale, individual days matter. Still, I also have the impression that they matter because Clients demand certainty and precision in reporting rather than focusing on actual value delivered, but the management doesn't always see it that way.
      - sheepmullet 9y ago
        > A thousand man-years of effort? Sounds like a very large project. Kind of. It's upper-medium. It's nothing compared to Microsoft Office, a web browser, etc. Microsoft for example has maybe 50k developers and so creates 50,000 man years of work every single year. > Typical project size is somewhere around 500 to 1000 man days. That's roughly 2 devs for a year. That's hardly even a prototype where I work. It is fascinating to see the difference in scale in our industry.
    - lairdpop 9y ago
      Daily standups aren't for tracking progress, they're for keeping the team in sync, and in particular are a forum for raising blockers/dependencies so that they an be addressed. Tracking progress goes on a Kanban board (or digital equivalent).
  - ljw1001 9y ago
    > It's hard to track progress and estimate if your tickets are huge multi-week affairs. So what you are saying is that the standup really _is_ for project tracking. I don't disagree. In my experience that has been the main point to the meeting, but it's not really how it's supposed to be done according to agile doctrine. The point of the meeting is often (A) let management/outsiders assess progress across devs with minimal time investment on the manager's part, and (B) put subtle pressure on the devs via the daily confession.
    - matthewmacleod 9y ago
      So what you are saying is that the standup really _is_ for project tracking Only in the sense that the team needs to know itself how work is progressing, in order to understand what they can realistically achieve, or to estimate more accurately, or to identify pain points that need to be resolved. Not tracking in the 'report to an external agency how much is being done every day', which I agree is awful. The point of the meeting is often… I maintain that is this happens, you are in a bad environment.
      - humanrebar 9y ago
        > Only in the sense that the team needs to know itself how work is progressing That's what retrospectives, demos, and stories are for. If there is concern about individual performance, managers could create dashboard of their teams' git commits, allowing them to jump around and see peoples' work passively without disrupting the entire team.
        lairdpop 9y ago
        When developers pull tasks, their name goes on it. If one dev keeps pulling tasks that don't get done, or take far too long, that becomes obvious to the whole team quite rapidly. That doesn't "disrupt" the team at all.
        humanrebar 9y ago
        Right. The point is you don't really need them to stand up every day to say "still working on tasks A, B, and C". You'd just look at the board and say, "Hey, you have four things assigned to you. Are they blocked? Otherwise, please do one thing at a time."
  - pjbster 9y ago
    I think some organisations have deeper problems [than developer communication] which SCRUM and Agile are simply not equipped to cope with. Here’s one example: * Moving functionality from a legacy^2 to legacy (mainframe to client-server) * Target system groaning under 15 years of neglect, developer outsourcing, technical debt and band-aids. Source system simply untouched for nearly 20 years. * Source and target systems inherently un- unit testable * Mediocre developers with no intrinsic sense of craftsmanship nor any desire to acquire some * Developers with no experience of legacy codebase so completely unqualified to estimate cost of stories * Culture of fear reinforced by performance reviews, stack ranking and PIPs * Locked down QA systems and silo’d resources Any one of these would be a project killer but my last employer suffered from all of them in the same project and showed no inclination to address any of them because they were deemed to be out of scope. But it was totally fine to tie up 10 people for 15 minutes every day to enable the PM to derive a magical velocity curve to feed back to the stakeholders so that the company could demonstrate how effective this SCRUM process was going to be.
- jakubp 9y ago
  "This task needs to be broken up into manageable pieces badly." This seems to be a sentiment I see a lot, but I don't think it applies equally to all people. Maybe it depends whether the person doing the task is a mature worker (in the sense of doing independent work). When you break things down, you make it easier for less experienced workers to complete work. It helps the managers with tracking progress. However, increased breakdown is very costly on many levels. You need extra time to break things down (senior dev), extra effort to track it in project management tools, extra time to deal with it all every day. It's costly. Moreover, dividing work that way is harder and less efficient for more experienced workers. They often dislike being micromanaged and probed multiple times a week (or day) about their progress. Give them space and they excel, but ask them to explain what they do, what's next, how much time is left, etc. and they get annoyed. Mature workers generally know who needs to be informed of issues, recognize them early on, and proactively resolve those. "Process" is what you typically need when you don't have many mature workers. It's fine, but perhaps it's best to be careful who we apply it to.
  - matwood 9y ago
    > When you break things down, you make it easier for less experienced workers to complete work. Actually you make it easier for everyone. The point of breaking down a task is to start removing assumptions, and make it so others can also lend a hand. > However, increased breakdown is very costly on many levels. You need extra time to break things down (senior dev), extra effort to track it in project management tools, extra time to deal with it all every day. It's costly. Time and again I have heard this reasoning, but in my experience the real costs comes when not breaking down tasks. There is an unknown unknown problem with large tasks, that is often solved by breaking them down with the stake holder instead of finding the issues during acceptance. I do agree though that the right level to break down tasks is an art that ends up being team specific.
    - ryandrake 9y ago
      It's also so you can get the jump on risks as early as possible. Consider two projects, both roughly a week long. Project A is broken down into day-long tasks, and project B isn't. On day two, the guy doing project A reports he wasn't able to get milestone 1 completely done yesterday. Others can now step in and help if needed, after only a day. The guy doing project B, who reports "analytics yesterday, analytics today" needs to subjectively assess whether or not he's behind, and depending on how experienced he is at this, nobody will know until the sprint is blown that he was unrecoverably behind.
- _pmf_ 9y ago
  > The problem is you feel like you need to justify working on one thing for two days: The problem is that the Agile industry caters to the fast world of write-only web site and app producers where the most complex thing is usually the decision whether a IAP purchase should be 0.49 USD or 0.99 USD. The fact that there might exist some actual real-world problems that map to features that take weeks to month to implement and are not trivially decomposable is completely foreign to them.
  - aardvark179 9y ago
    It may be foreign to the "Agile Industry" but I've worked on a complex re-implementation of a dynamic language and supporting libraries on the JVM which involved a lot of quite complex problems and various agile techniques served us extremely well. Having said that the team should be the ones driving this sort of thing - we switched between scrum and kanban several times depend on the nature of the work, and we kept looking at what we were doing to see if it was helping us, and when it wasn't we stopped doing it or changed it.
    - _pmf_ 9y ago
      > but I've worked on a complex re-implementation of a dynamic language and supporting libraries on the JVM which involved a lot of quite complex problems and various agile techniques served us extremely well. Any specifics? I would have imagined this to be a case with very strict up front requirements with a relatively heavy toll on changing the design during the project.
  - lairdpop 9y ago
    Actually, agile was first invented for writing mission critical enterprise software more effectively - thus the emphasis on test-drive-development and a very tight confirmation loop with the users. The fact that it also works well for web sites is great, of course, but it's not where it started.
- watwut 9y ago
  Three days long task is not unmageably large. Personally, I find the "tasks must be tiny teeny as you can not manage task larger then few hours autonomly" management insulting - it feels like babysitting. Ok if one was irresponsible in the past or is too junior to work normally, but not ok if I was working alright.
  - humanrebar 9y ago
    The goal in small tasks, to me, is to encourage collaboration more than to micromanage. Sometimes you can get three free devs working on one story and turn it around in a day or two, but if it was all one "get the feature done" task, there are no opportunities there.
    - dasmoth 9y ago
      Fine grained efforts to "encourage collaboration" in places where it's not clearly needed is micromanagement. In fact, from an introvert's point of view, it could be the very worst form of micromanagement.
      - lairdpop 9y ago
        Agile only works for certain kinds of developers. In particular, it works well for people who are team oriented and communicate well, able to talk to the rest of the team to coordinate for at least 10 minutes a day, and responsible enough that they push themselves to deliver and get what they need from the rest of the team. If someone's an introvert who wants to be left alone to code, or to rely on a manager for all discipline, they need to be in a different environment, perhaps an old-school waterfall company where the manager hands out assignments and badgers people until they are done. I've done many agile transformations, and some developers just don't fit in agile, and are perfectly happy in waterfall, and that's fine. Though it might mean needing to find a new job.
        tutufan 9y ago
        Or it might mean that the company should be asking whether agile is actually a net benefit.
jakubp 9y ago
[edit] Reporting on a high level ("yesterday - analytics, today - analytics") is fine only up to a point. This statement only works when team members are 1) mature (to admit problems) and 2) very self-aware (to accurately assess if they are making progress). Unfortunately, huge percentage of people in software houses I've seen are young and therefore both immature and not very self-aware. They have a hard time recognizing the upcoming issues, and will not admit they made a mistake or are unsure if they can succeed on time. The results? People claim they are on track, then they fail, goals aren't achieved. This happens over and over. Eventually Project Manager or senior developers start probing more and more, dividing the work more, creating smaller (shorter) tasks to cater for less independent employees, adding short iterations, daily checkups and ... Wait, we created "agile". Haven't we? Overreport and micromanage to deal with issues.
- humanrebar 9y ago
  This is why I regularly advise new hires, both senior and right out of college, that communicating when you're blocked or stuck is not optional. The quickest way to get me to recommend a performance improvement plan isn't if you can't hack it on a particular task, it's if you aren't clear that you don't have what you need (voodoo to get tools working, training, experience) to get the job done. Being stuck and not speaking up is a cardinal sin in knowledge work.
taneq 9y ago
Basically this. If you're working on a large decoupled task, no-one else (other than team lead) has to know or care what you're doing other than that you're not waiting on anyone else. The moment your work has to interact with someone else's work, then you need to know what each other are doing.
- maaaats 9y ago
  Sounds like a bus-factory way of working, which has its own set of problems.
  - taneq 9y ago
    As in a high-bus-number way? Not necessarily. We're talking about a few days here, not someone going off in a silo for months on end. If your standards for documentation, testing, etc. are reasonable then the results of their work should be maintainable by any team member after they're done.
conradfr 9y ago
> "Yesterday, analytics. Today, analytics. Yes, I said the same yesterday, it's a big job, but it's going fine. Anyone can come over and ask me about analytics if they like! No blockers. Thanks." "You're not transparent enough. It feels you are blocked and you're not communicating. The task is too big, we will divide them more next sprint" (later that year) "Why have you lost your motivation?"
- tutufan 9y ago
  The Agile will continue until morale improves... :-)

rejschaap 9y ago

The problem is you feel like you need to justify working on one thing for two days: "Yes, I said the same yesterday, it's a big job, but it's going fine." and, this is even more defensive, you feel people will not believe you so you invite them to see some proof: "Anyone can come over and ask me about analytics if they like!" Maybe the biggest problem is this though: "Yesterday, analytics. Today, analytics" This task needs to be broken up into manageable pieces badly.

matthewmacleod 9y ago
This task needs to be broken up into manageable pieces badly. This would also be my immediate thought as well. "Yesterday I setup integration with the analytics service. Today, I'm going to audit the places where we currently send analytics and see if it would be possible to centralise it – I'll share the results later". It's hard to track progress and estimate if your tickets are huge multi-week affairs.
- bshimmin 9y ago
  Thanks one and all for the responses to my comment, which was written in some haste but seems to have generated useful discussion nonetheless. Just responding to this one, I would say that it really depends. If your task is implementing analytics and no one else on the team has anything much to do with it, then maybe it's best not to trouble them with the specifics. Your summary is much better, and only a few extra words, but if no one really cares about the analytics except to know that it's cheerfully in progress, maybe it's not all that necessary to go into more detail. This is definitely something you need to be wary of in a multi-disciplinary team. Also, I didn't mean "Anyone can come over and ask me about analytics if they like!" to sound defensive - it was actually more tongue-in-cheek! Here's another attempt: "I can't imagine why you would want to bore yourself with my analytics implementation, but please come over and ask me about it if you're having trouble sleeping at night." (I will freely admit that I am a confident person and would have no trouble saying something like that in front of a dozen people.)
- sheepmullet 9y ago
  Is it really important to track progress on a day to day basis? IMO, only for a small minority of tasks. The vast majority of projects I've seen and worked on are measured in dev years of effort. My current project is well over a thousand dev years. In comparison a few days is meaningless. Most often it's a trust issue.
  - matthewmacleod 9y ago
    Is it really important to track progress on a day to day basis? It depends on the team. We find it useful specifically because we want to make sure we are estimating relatively accurately. Since we work in essentially 10-working-day periods, it's great to know when a piece of work we thought we could easily achieve is actually a blocker, or much more complex than we thought.
  - jakubp 9y ago
    A thousand man-years of effort? Sounds like a very large project. Just for contrast: I've been working for a medium size software house for the past 4 years. Typical project size is somewhere around 500 to 1000 man days. On that scale, individual days matter. Still, I also have the impression that they matter because Clients demand certainty and precision in reporting rather than focusing on actual value delivered, but the management doesn't always see it that way.
    - sheepmullet 9y ago
      > A thousand man-years of effort? Sounds like a very large project. Kind of. It's upper-medium. It's nothing compared to Microsoft Office, a web browser, etc. Microsoft for example has maybe 50k developers and so creates 50,000 man years of work every single year. > Typical project size is somewhere around 500 to 1000 man days. That's roughly 2 devs for a year. That's hardly even a prototype where I work. It is fascinating to see the difference in scale in our industry.
  - lairdpop 9y ago
    Daily standups aren't for tracking progress, they're for keeping the team in sync, and in particular are a forum for raising blockers/dependencies so that they an be addressed. Tracking progress goes on a Kanban board (or digital equivalent).
- ljw1001 9y ago
  > It's hard to track progress and estimate if your tickets are huge multi-week affairs. So what you are saying is that the standup really _is_ for project tracking. I don't disagree. In my experience that has been the main point to the meeting, but it's not really how it's supposed to be done according to agile doctrine. The point of the meeting is often (A) let management/outsiders assess progress across devs with minimal time investment on the manager's part, and (B) put subtle pressure on the devs via the daily confession.
  - matthewmacleod 9y ago
    So what you are saying is that the standup really _is_ for project tracking Only in the sense that the team needs to know itself how work is progressing, in order to understand what they can realistically achieve, or to estimate more accurately, or to identify pain points that need to be resolved. Not tracking in the 'report to an external agency how much is being done every day', which I agree is awful. The point of the meeting is often… I maintain that is this happens, you are in a bad environment.
    - humanrebar 9y ago
      > Only in the sense that the team needs to know itself how work is progressing That's what retrospectives, demos, and stories are for. If there is concern about individual performance, managers could create dashboard of their teams' git commits, allowing them to jump around and see peoples' work passively without disrupting the entire team.
      - lairdpop 9y ago
        When developers pull tasks, their name goes on it. If one dev keeps pulling tasks that don't get done, or take far too long, that becomes obvious to the whole team quite rapidly. That doesn't "disrupt" the team at all.
        humanrebar 9y ago
        Right. The point is you don't really need them to stand up every day to say "still working on tasks A, B, and C". You'd just look at the board and say, "Hey, you have four things assigned to you. Are they blocked? Otherwise, please do one thing at a time."
- pjbster 9y ago
  I think some organisations have deeper problems [than developer communication] which SCRUM and Agile are simply not equipped to cope with. Here’s one example: * Moving functionality from a legacy^2 to legacy (mainframe to client-server) * Target system groaning under 15 years of neglect, developer outsourcing, technical debt and band-aids. Source system simply untouched for nearly 20 years. * Source and target systems inherently un- unit testable * Mediocre developers with no intrinsic sense of craftsmanship nor any desire to acquire some * Developers with no experience of legacy codebase so completely unqualified to estimate cost of stories * Culture of fear reinforced by performance reviews, stack ranking and PIPs * Locked down QA systems and silo’d resources Any one of these would be a project killer but my last employer suffered from all of them in the same project and showed no inclination to address any of them because they were deemed to be out of scope. But it was totally fine to tie up 10 people for 15 minutes every day to enable the PM to derive a magical velocity curve to feed back to the stakeholders so that the company could demonstrate how effective this SCRUM process was going to be.
jakubp 9y ago
"This task needs to be broken up into manageable pieces badly." This seems to be a sentiment I see a lot, but I don't think it applies equally to all people. Maybe it depends whether the person doing the task is a mature worker (in the sense of doing independent work). When you break things down, you make it easier for less experienced workers to complete work. It helps the managers with tracking progress. However, increased breakdown is very costly on many levels. You need extra time to break things down (senior dev), extra effort to track it in project management tools, extra time to deal with it all every day. It's costly. Moreover, dividing work that way is harder and less efficient for more experienced workers. They often dislike being micromanaged and probed multiple times a week (or day) about their progress. Give them space and they excel, but ask them to explain what they do, what's next, how much time is left, etc. and they get annoyed. Mature workers generally know who needs to be informed of issues, recognize them early on, and proactively resolve those. "Process" is what you typically need when you don't have many mature workers. It's fine, but perhaps it's best to be careful who we apply it to.
- matwood 9y ago
  > When you break things down, you make it easier for less experienced workers to complete work. Actually you make it easier for everyone. The point of breaking down a task is to start removing assumptions, and make it so others can also lend a hand. > However, increased breakdown is very costly on many levels. You need extra time to break things down (senior dev), extra effort to track it in project management tools, extra time to deal with it all every day. It's costly. Time and again I have heard this reasoning, but in my experience the real costs comes when not breaking down tasks. There is an unknown unknown problem with large tasks, that is often solved by breaking them down with the stake holder instead of finding the issues during acceptance. I do agree though that the right level to break down tasks is an art that ends up being team specific.
  - ryandrake 9y ago
    It's also so you can get the jump on risks as early as possible. Consider two projects, both roughly a week long. Project A is broken down into day-long tasks, and project B isn't. On day two, the guy doing project A reports he wasn't able to get milestone 1 completely done yesterday. Others can now step in and help if needed, after only a day. The guy doing project B, who reports "analytics yesterday, analytics today" needs to subjectively assess whether or not he's behind, and depending on how experienced he is at this, nobody will know until the sprint is blown that he was unrecoverably behind.
_pmf_ 9y ago
> The problem is you feel like you need to justify working on one thing for two days: The problem is that the Agile industry caters to the fast world of write-only web site and app producers where the most complex thing is usually the decision whether a IAP purchase should be 0.49 USD or 0.99 USD. The fact that there might exist some actual real-world problems that map to features that take weeks to month to implement and are not trivially decomposable is completely foreign to them.
- aardvark179 9y ago
  It may be foreign to the "Agile Industry" but I've worked on a complex re-implementation of a dynamic language and supporting libraries on the JVM which involved a lot of quite complex problems and various agile techniques served us extremely well. Having said that the team should be the ones driving this sort of thing - we switched between scrum and kanban several times depend on the nature of the work, and we kept looking at what we were doing to see if it was helping us, and when it wasn't we stopped doing it or changed it.
  - _pmf_ 9y ago
    > but I've worked on a complex re-implementation of a dynamic language and supporting libraries on the JVM which involved a lot of quite complex problems and various agile techniques served us extremely well. Any specifics? I would have imagined this to be a case with very strict up front requirements with a relatively heavy toll on changing the design during the project.
- lairdpop 9y ago
  Actually, agile was first invented for writing mission critical enterprise software more effectively - thus the emphasis on test-drive-development and a very tight confirmation loop with the users. The fact that it also works well for web sites is great, of course, but it's not where it started.
watwut 9y ago
Three days long task is not unmageably large. Personally, I find the "tasks must be tiny teeny as you can not manage task larger then few hours autonomly" management insulting - it feels like babysitting. Ok if one was irresponsible in the past or is too junior to work normally, but not ok if I was working alright.
- humanrebar 9y ago
  The goal in small tasks, to me, is to encourage collaboration more than to micromanage. Sometimes you can get three free devs working on one story and turn it around in a day or two, but if it was all one "get the feature done" task, there are no opportunities there.
  - dasmoth 9y ago
    Fine grained efforts to "encourage collaboration" in places where it's not clearly needed is micromanagement. In fact, from an introvert's point of view, it could be the very worst form of micromanagement.
    - lairdpop 9y ago
      Agile only works for certain kinds of developers. In particular, it works well for people who are team oriented and communicate well, able to talk to the rest of the team to coordinate for at least 10 minutes a day, and responsible enough that they push themselves to deliver and get what they need from the rest of the team. If someone's an introvert who wants to be left alone to code, or to rely on a manager for all discipline, they need to be in a different environment, perhaps an old-school waterfall company where the manager hands out assignments and badgers people until they are done. I've done many agile transformations, and some developers just don't fit in agile, and are perfectly happy in waterfall, and that's fine. Though it might mean needing to find a new job.
      - tutufan 9y ago
        Or it might mean that the company should be asking whether agile is actually a net benefit.

jakubp 9y ago

[edit] Reporting on a high level ("yesterday - analytics, today - analytics") is fine only up to a point. This statement only works when team members are 1) mature (to admit problems) and 2) very self-aware (to accurately assess if they are making progress). Unfortunately, huge percentage of people in software houses I've seen are young and therefore both immature and not very self-aware. They have a hard time recognizing the upcoming issues, and will not admit they made a mistake or are unsure if they can succeed on time. The results? People claim they are on track, then they fail, goals aren't achieved. This happens over and over. Eventually Project Manager or senior developers start probing more and more, dividing the work more, creating smaller (shorter) tasks to cater for less independent employees, adding short iterations, daily checkups and ... Wait, we created "agile". Haven't we? Overreport and micromanage to deal with issues.

humanrebar 9y ago
This is why I regularly advise new hires, both senior and right out of college, that communicating when you're blocked or stuck is not optional. The quickest way to get me to recommend a performance improvement plan isn't if you can't hack it on a particular task, it's if you aren't clear that you don't have what you need (voodoo to get tools working, training, experience) to get the job done. Being stuck and not speaking up is a cardinal sin in knowledge work.

taneq 9y ago

Basically this. If you're working on a large decoupled task, no-one else (other than team lead) has to know or care what you're doing other than that you're not waiting on anyone else. The moment your work has to interact with someone else's work, then you need to know what each other are doing.

maaaats 9y ago
Sounds like a bus-factory way of working, which has its own set of problems.
- taneq 9y ago
  As in a high-bus-number way? Not necessarily. We're talking about a few days here, not someone going off in a silo for months on end. If your standards for documentation, testing, etc. are reasonable then the results of their work should be maintainable by any team member after they're done.

conradfr 9y ago

> "Yesterday, analytics. Today, analytics. Yes, I said the same yesterday, it's a big job, but it's going fine. Anyone can come over and ask me about analytics if they like! No blockers. Thanks." "You're not transparent enough. It feels you are blocked and you're not communicating. The task is too big, we will divide them more next sprint" (later that year) "Why have you lost your motivation?"

tutufan 9y ago
The Agile will continue until morale improves... :-)