3 ms·

Yeah Agile is used as a way to make money now days. For what other reason there are Agile consultants, Agile agencies and Agile certification. I firmly believe

by Ingon 13y ago

Yeah Agile is used as a way to make money now days. For what other reason there are Agile consultants, Agile agencies and Agile certification. I firmly believe that Agile is about doing what makes sense in this team right now. You let the team to decide on their process, on their way of work and get away. And for good managers this is enough - you are empowering your team to succeed. Recently I had a great success demolishing standups in our team. We clearly weren't getting enough value from them (I though they were plainly hurting us), so it was time for change. I had a great resistance from the management team, but some developers were keen to try a change (some of them were long enough in the industry to remember the pre-agile days, when we were delivering software too). So we tried it for some time, everybody loved it, and we stopped doing it completely. Now days we all agree that iterative development is the way forward. We should also think if we can apply the same on a meta level - the team, the process, the product, the design, the organization. Do small steps, check if you are going into the right direction, repeat. It may work :)

hox 13y ago
What was it about your standups that were hurting your team? I'm on the fence with daily standup meetings. they definitely can help a team communicate when there are a large number of external forces at play in a larger organization and if there are no underlying asynchronous communication channels available. on the other hand, in a team that communicates regularly with historical communications available to new team members, they aren't as useful.
- Ingon 13y ago
  Among the negatives of standups are: - Rarely the right information. Every person in the team have different needs for information. It is even harder to deliver the right amount and on the right level if your team includes designers, quality engineers, project/product managers. - Rarely at the right time. If your company culture includes flexible hours, no matter at what time you put the standup somebody will suffer. Most of the time the team members who come early suffer - they already started work, now you are forcing them to get out of context and attend a meeting. - Sometimes standups are used as a way to force some team members to do what they have promised (the what I'll do today). But if you are using them in this way is really counterproductive - you either trust that your peers are doing their best for the team or you might consider team change (which I understand is beyond our control sometimes). - Failure to communicate (or "the what problems I have/had" part). If your team members are mature enough and they had a problem during the course of the day, they shouldn't wait for the next day's standup to let everybody know about that. The should be proactive and seek resolution as the problem comes up. - Finally the "what I did yesterday" part. This information is commonly used by the managers, but there are better ways to deliver it. Most of us use some way of tracking our work. We only need to flow this information to our managers. It is also a mind shift for them - instead somebody pushing this information to them, they should be proactive and seek it and pull it. If you don't know what somebody is working on, then go and ask him. You don't need to loose the time of the whole team for this. That being said whether you will use standups or not depends largely on your team dynamics. In new teams or teams formed largely by junior developers it makes sense to have standups - its a way to force communication patterns and certainly can be used as a casual form of a team building. But in my opinion as the team matures there is less and less need for standups, so at one point it just becomes a hurdle. And the good thing about being agile (not SCRUM) is that you can evaluate your process and change it as you (and your team) see it fit.
  - vpeters25 13y ago
    I find it really hard to understand how a quick, 5 minute meeting every day can hurt a team. > - Rarely the right information. You were doing it wrong: standups are not to give or receive information, just to inform the team what did you do yesterday, what are you doing to day and any blockers. > - Rarely at the right time. We schedule them 15 minutes before the first team member goes out for lunch (10:45 am), this forces a hard deadline. > - Failure to communicate. You should communicate blockers to your SCRUMMASTER immediately, the daily meeting is to remind him/her the blocker is still there. > - Finally the "what I did yesterday" part.... If you don't know what somebody is working on, then go and ask him. This is so wrong in so many ways. The SCRUMMASTER's job is to keep management off developers back and play interference so they can focus on getting the job done. A stakeholder should NEVER be invited to talk directly to developers about what they are working on. If they want a daily status, they can attend the daily standup where they cannot talk, just listen. If they have questions, ask the scrummaster after the meeting. The daily standup is a tradeoff, as SCRUMMASTER you promise the team they will not get dragged to any other meeting during the iteration.
    - RogerL 13y ago
      That all strikes me as being incredibly rigid for a process called "agile".

by Ingon 13y ago

hox 13y ago

What was it about your standups that were hurting your team? I'm on the fence with daily standup meetings. they definitely can help a team communicate when there are a large number of external forces at play in a larger organization and if there are no underlying asynchronous communication channels available. on the other hand, in a team that communicates regularly with historical communications available to new team members, they aren't as useful.

Ingon 13y ago
Among the negatives of standups are: - Rarely the right information. Every person in the team have different needs for information. It is even harder to deliver the right amount and on the right level if your team includes designers, quality engineers, project/product managers. - Rarely at the right time. If your company culture includes flexible hours, no matter at what time you put the standup somebody will suffer. Most of the time the team members who come early suffer - they already started work, now you are forcing them to get out of context and attend a meeting. - Sometimes standups are used as a way to force some team members to do what they have promised (the what I'll do today). But if you are using them in this way is really counterproductive - you either trust that your peers are doing their best for the team or you might consider team change (which I understand is beyond our control sometimes). - Failure to communicate (or "the what problems I have/had" part). If your team members are mature enough and they had a problem during the course of the day, they shouldn't wait for the next day's standup to let everybody know about that. The should be proactive and seek resolution as the problem comes up. - Finally the "what I did yesterday" part. This information is commonly used by the managers, but there are better ways to deliver it. Most of us use some way of tracking our work. We only need to flow this information to our managers. It is also a mind shift for them - instead somebody pushing this information to them, they should be proactive and seek it and pull it. If you don't know what somebody is working on, then go and ask him. You don't need to loose the time of the whole team for this. That being said whether you will use standups or not depends largely on your team dynamics. In new teams or teams formed largely by junior developers it makes sense to have standups - its a way to force communication patterns and certainly can be used as a casual form of a team building. But in my opinion as the team matures there is less and less need for standups, so at one point it just becomes a hurdle. And the good thing about being agile (not SCRUM) is that you can evaluate your process and change it as you (and your team) see it fit.
- vpeters25 13y ago
  I find it really hard to understand how a quick, 5 minute meeting every day can hurt a team. > - Rarely the right information. You were doing it wrong: standups are not to give or receive information, just to inform the team what did you do yesterday, what are you doing to day and any blockers. > - Rarely at the right time. We schedule them 15 minutes before the first team member goes out for lunch (10:45 am), this forces a hard deadline. > - Failure to communicate. You should communicate blockers to your SCRUMMASTER immediately, the daily meeting is to remind him/her the blocker is still there. > - Finally the "what I did yesterday" part.... If you don't know what somebody is working on, then go and ask him. This is so wrong in so many ways. The SCRUMMASTER's job is to keep management off developers back and play interference so they can focus on getting the job done. A stakeholder should NEVER be invited to talk directly to developers about what they are working on. If they want a daily status, they can attend the daily standup where they cannot talk, just listen. If they have questions, ask the scrummaster after the meeting. The daily standup is a tradeoff, as SCRUMMASTER you promise the team they will not get dragged to any other meeting during the iteration.
  - RogerL 13y ago
    That all strikes me as being incredibly rigid for a process called "agile".