3 ms·

I would recommend the following: Assume you can't get the process right to begin with. Therefore, the most important piece of your process is something that let

I would recommend the following: Assume you can't get the process right to begin with. Therefore, the most important piece of your process is something that lets you modify it as you go. Retrospective meetings (where the topic is how the work is getting done, not what is getting done) are a standard and useful way to do this (assuming the results lead to actionable change). The frequency of the retros themselves should be part of your discussion (pick something to start with ("every 2 weeks") and periodically decide if that's the right cadence). Length of sprints, styles of coding, amount of pairing, etc. -- all of these are variable based on the experience of the team and the problem being tackled. Pick reasonable defaults to start with and regularly ask yourselves if those defaults make sense given your experiences. I could say more, but the above is the base minimum I've found for success across different teams, different problems, different companies. Cheers.

jerf 11y ago
"Assume you can't get the process right to begin with. Therefore, the most important piece of your process is something that lets you modify it as you go." Honestly, if you aren't doing this, you aren't doing "Agile", in the sense of the Agile Manifesto. If you are getting beat over the head by your scrum master with the "official Scrum process", you're not actually doing Agile. Scrum is an interesting toolbox to pull tools from; if you view it as a proscription, you're not doing Agile. Likewise for the other techniques offered by other people. When people complain about fake Agile, I believe this is the big error that is being made. I've done projects where we did 1 week iterations. I've done projects with story points and without. Right now I'm on a project where we're doing one iteration a month. And if you're about to jump up and try to explain to me why that's not "doing it right"... well, that's exactly what I mean. It turns out that for this project it's working great. We didn't start at that rate... we evolved into it when it became clear that 2 weeks wasn't useful for us. See, my previous projects haven't had much use for the "sprint demo" but it's a critical part of this one, and we were noticing that neither the project team nor the customers were all that excited about the demos every 2 weeks, and we were running the risk of exhausting our customer's patience. This project isn't "customer facing" per se, and the tasks I get in this project aren't the sort where we need to do lots of UI explorations, where we need the demos very frequently to make sure we're going down the right track. Generally we get handend relatively well-defined tasks and our demos are more for convincing people progress is being made, getting feedback about priorities, and ensuring that the customers are happy and aware of what is going on. (The customers in this case are other developers in the organization.) I offer that as an example of the sort of justification a team properly doing Agile ought to be able to provide for their choices. "Our Scrum book says" is not a reason to do something, or at least, it shouldn't be past the first 3 months.
- jander 11y ago
  Amen :-)
ironchef 11y ago
Jason's spot on on this one....and what works for one team doesn't often work for others. Hell, sometimes that's the case for individuals (some individuals are not meant for pair programming where they might excel at code reviews instead). Also, OP mentioned something re: "minimize future modifications to already developed parts". Be aware of the technical debt you're incurring _as_ you develop it. We used to have regular sprints specifically to pay down the debt (one out of every 4 for example).
- diegoperini 11y ago
  Thanks for the alert! :)
qwer 11y ago
Retros are my #1 as well. Retros can derive the rest of the changes that need to be made, and if you're doing them right, the team will be making the changes together. My next two are: #2 Never say "Agile" again. If you can't explain an idea from first principles without defending it as Agile then you're not ready to promote it. #3 Never suggest a change that isn't a real solution to an actual major problem. You're only going to lose supporters if you're continually trying to get them to do things that don't help them. If you do these things, you'll have a much greater chance of success, though the end result might not look anything like Scrum, XP, etc. (and that's okay).
- diegoperini 11y ago
  Is there a term that can cover those consensus bullets in my post that is more suitable than agile? I personally may be ignorant on that part.
  - qwer 11y ago
    None of your points are actually particularly necessary for agile. For example, I work on a team that does planning on demand (which is still many times per week) and deployments all day long, so we don't do iterations at all. Check the manifesto: Sprints aren't mentioned. We're definitely agile though. I suggest you don't use the word Agile at all because everyone has different expectations of what it means and it detracts from good arguments about the right things to do. Agile should never be more important than doing the right thing. And you can sell your ideas individually if they're worth doing. There's no need for an umbrella term. That will only tie the ideas together and create an all-or-nothing mentality.
    - diegoperini 11y ago
      I am more like buying ideas tbh. :) Thank you.
  - gkop 11y ago
    I call it "fast-paced, iterative" software development.
skrebbel 11y ago
A thousand times this. The retrospective blows all the other elements of $YOUR_FAVOURITE_PROCESS out of the water. 3 things about it: if you do sprints, and they have busy beginnings and endings, then there's no harm in planning the retrospective halfway the sprint instead of at the end. Improvements can be made at any time. Also, if your sprints are weeks, consider making the retrospective bi-weekly, that's usually enough. Second, don't skip the retrospective. It's never urgent, but it's very important. Every team is different and every situation is different, and no agile book can cover all cases. The retrospective makes you own your process, makes the entire team feel like their opinion matters. It improves both effectiveness and morale. Give it time - especially in the beginning it might last 2 hours easily. It's worth that. Finally, do the retrospective right. You want actionable results out of it. If it's just a complaining session, you're missing out on its value. What I usually do is this: I make a poster with 3 columns, :-), :-/ and !. Every team member has to make at least 2 green and 2 red sticky notes, on which great stuff and improvement points are written, respectively. More is OK, less is not. This forces them to really think about what could be better even if on first thought they think things are going pretty OK. Make every team member put the sticky note on the board in the left two columns and explain what it's about and why it matters. Have people group sticky notes that are about roughly the same thing. Finally, and this is the part people tend to forget, distill a bunch of action points for the third column that will help tackle the problems in the 2nd column. Make these actionable, assignable. You might want to make them tasks in your scrum process, just like programming tasks. Without action points, a retrospective is mostly a waste of time. If a discussion about one action point is long or very technical (discussions about how to use source control come to mind), ask the people who care about it to discuss it amongst each other present the solution a day later. This works great for distributed teams too ("Problem: the git is becoming a mess. Solution: $NAME makes a Slack channel and presents the outcome tomorrow"). Everybody who doesn't involve himself in that discussion is expected to agree automatically. You can't improve the process super much in a short amount of time. If you make too many action points, half of them will not get done - people need to make software, too! So if there's, say, >4 real decent problems in column 2, ask the team to score problems and pick the ones with the highest score. One good way is to give everyone 3 votes that they can arbitrarily spread across the problem stickies (multiple votes per sticky allowed). Pick the 4 problems with the most points. Consider using real stickies and not computer stuff, even if your team is partly remote. Tangible things that you move across a board somehow makes things seem more real, like they matter more. Good luck!
burkemw3 11y ago
I agree with parent and siblings that retros are awesome! Initially, my team started by sitting around talking about work item by work item and other miscellaneous topics. Most of the time, this was cathartic but didn't lead to much change. Recently, we've had a facilitator lead us through activities to drive toward 1-2 actionable outputs to work on for the next sprint. This focus has helped the team actually improve things with our process. We've been using http://plans-for-retrospectives.com/ http://plans-for-retrospectives.com/ for ideas of the activities. A number of our Agile Coaches have recommended the "Agile Retrospectives: Making Good Teams Great" book (but I haven't read it myself).

jerf 11y ago

"Assume you can't get the process right to begin with. Therefore, the most important piece of your process is something that lets you modify it as you go." Honestly, if you aren't doing this, you aren't doing "Agile", in the sense of the Agile Manifesto. If you are getting beat over the head by your scrum master with the "official Scrum process", you're not actually doing Agile. Scrum is an interesting toolbox to pull tools from; if you view it as a proscription, you're not doing Agile. Likewise for the other techniques offered by other people. When people complain about fake Agile, I believe this is the big error that is being made. I've done projects where we did 1 week iterations. I've done projects with story points and without. Right now I'm on a project where we're doing one iteration a month. And if you're about to jump up and try to explain to me why that's not "doing it right"... well, that's exactly what I mean. It turns out that for this project it's working great. We didn't start at that rate... we evolved into it when it became clear that 2 weeks wasn't useful for us. See, my previous projects haven't had much use for the "sprint demo" but it's a critical part of this one, and we were noticing that neither the project team nor the customers were all that excited about the demos every 2 weeks, and we were running the risk of exhausting our customer's patience. This project isn't "customer facing" per se, and the tasks I get in this project aren't the sort where we need to do lots of UI explorations, where we need the demos very frequently to make sure we're going down the right track. Generally we get handend relatively well-defined tasks and our demos are more for convincing people progress is being made, getting feedback about priorities, and ensuring that the customers are happy and aware of what is going on. (The customers in this case are other developers in the organization.) I offer that as an example of the sort of justification a team properly doing Agile ought to be able to provide for their choices. "Our Scrum book says" is not a reason to do something, or at least, it shouldn't be past the first 3 months.

jander 11y ago
Amen :-)

ironchef 11y ago

Jason's spot on on this one....and what works for one team doesn't often work for others. Hell, sometimes that's the case for individuals (some individuals are not meant for pair programming where they might excel at code reviews instead). Also, OP mentioned something re: "minimize future modifications to already developed parts". Be aware of the technical debt you're incurring _as_ you develop it. We used to have regular sprints specifically to pay down the debt (one out of every 4 for example).

diegoperini 11y ago
Thanks for the alert! :)

qwer 11y ago

Retros are my #1 as well. Retros can derive the rest of the changes that need to be made, and if you're doing them right, the team will be making the changes together. My next two are: #2 Never say "Agile" again. If you can't explain an idea from first principles without defending it as Agile then you're not ready to promote it. #3 Never suggest a change that isn't a real solution to an actual major problem. You're only going to lose supporters if you're continually trying to get them to do things that don't help them. If you do these things, you'll have a much greater chance of success, though the end result might not look anything like Scrum, XP, etc. (and that's okay).

diegoperini 11y ago
Is there a term that can cover those consensus bullets in my post that is more suitable than agile? I personally may be ignorant on that part.
- qwer 11y ago
  None of your points are actually particularly necessary for agile. For example, I work on a team that does planning on demand (which is still many times per week) and deployments all day long, so we don't do iterations at all. Check the manifesto: Sprints aren't mentioned. We're definitely agile though. I suggest you don't use the word Agile at all because everyone has different expectations of what it means and it detracts from good arguments about the right things to do. Agile should never be more important than doing the right thing. And you can sell your ideas individually if they're worth doing. There's no need for an umbrella term. That will only tie the ideas together and create an all-or-nothing mentality.
  - diegoperini 11y ago
    I am more like buying ideas tbh. :) Thank you.
- gkop 11y ago
  I call it "fast-paced, iterative" software development.

skrebbel 11y ago

A thousand times this. The retrospective blows all the other elements of $YOUR_FAVOURITE_PROCESS out of the water. 3 things about it: if you do sprints, and they have busy beginnings and endings, then there's no harm in planning the retrospective halfway the sprint instead of at the end. Improvements can be made at any time. Also, if your sprints are weeks, consider making the retrospective bi-weekly, that's usually enough. Second, don't skip the retrospective. It's never urgent, but it's very important. Every team is different and every situation is different, and no agile book can cover all cases. The retrospective makes you own your process, makes the entire team feel like their opinion matters. It improves both effectiveness and morale. Give it time - especially in the beginning it might last 2 hours easily. It's worth that. Finally, do the retrospective right. You want actionable results out of it. If it's just a complaining session, you're missing out on its value. What I usually do is this: I make a poster with 3 columns, :-), :-/ and !. Every team member has to make at least 2 green and 2 red sticky notes, on which great stuff and improvement points are written, respectively. More is OK, less is not. This forces them to really think about what could be better even if on first thought they think things are going pretty OK. Make every team member put the sticky note on the board in the left two columns and explain what it's about and why it matters. Have people group sticky notes that are about roughly the same thing. Finally, and this is the part people tend to forget, distill a bunch of action points for the third column that will help tackle the problems in the 2nd column. Make these actionable, assignable. You might want to make them tasks in your scrum process, just like programming tasks. Without action points, a retrospective is mostly a waste of time. If a discussion about one action point is long or very technical (discussions about how to use source control come to mind), ask the people who care about it to discuss it amongst each other present the solution a day later. This works great for distributed teams too ("Problem: the git is becoming a mess. Solution: $NAME makes a Slack channel and presents the outcome tomorrow"). Everybody who doesn't involve himself in that discussion is expected to agree automatically. You can't improve the process super much in a short amount of time. If you make too many action points, half of them will not get done - people need to make software, too! So if there's, say, >4 real decent problems in column 2, ask the team to score problems and pick the ones with the highest score. One good way is to give everyone 3 votes that they can arbitrarily spread across the problem stickies (multiple votes per sticky allowed). Pick the 4 problems with the most points. Consider using real stickies and not computer stuff, even if your team is partly remote. Tangible things that you move across a board somehow makes things seem more real, like they matter more. Good luck!

burkemw3 11y ago

I agree with parent and siblings that retros are awesome! Initially, my team started by sitting around talking about work item by work item and other miscellaneous topics. Most of the time, this was cathartic but didn't lead to much change. Recently, we've had a facilitator lead us through activities to drive toward 1-2 actionable outputs to work on for the next sprint. This focus has helped the team actually improve things with our process. We've been using http://plans-for-retrospectives.com/ http://plans-for-retrospectives.com/ for ideas of the activities. A number of our Agile Coaches have recommended the "Agile Retrospectives: Making Good Teams Great" book (but I haven't read it myself).