3 ms·

>ensure that your team is creating a working, tested, and "shippable" update every ~2 weeks. If you think about this, it falls down a bit because there is no w

>ensure that your team is creating a working, tested, and "shippable" update every ~2 weeks. If you think about this, it falls down a bit because there is no way you can code and do a full regression test in 2 weeks on any substantial product. You might be able to run some automated tests, but would you ever ship a product without eyes on the screen testing? Heck no. Before the agile thing, we did 4 releases a year, 2 majors and 2 minors, so you are looking at a 3 month cycle.

kasey_junk 9y ago
I think Agile in many ways was a reaction to a trend where internal teams where cargo culting what external teams were doing. When I was literally shipping software it made sense to have longer release cycles because the cost of shipping was so high and it was a cost your clients had to pay. But for internal teams, you could ship a lot more cheaply and if you needed to redeploy you typically had the power to do that. You could also literally have the customer in the room with you, which isn't possible when you are shipping to N external customers. I think that also explains the rise of SaaS. By keeping the software on site I can ship much more cheaply, though the client negotiation part then is the more traditional model.
- Clubber 9y ago
  I understand what you are saying, but having done 2 week cycles for several years now, it seems a lot more chaotic to me. With the 3 month cycle, it seemed users (or at least project managers) and developers had time to hash things out before and during coding. Users could get a "look" at how the developer interpreted what they want and could offer suggestions. QA would be able to give it a thorough test with a few bounce backs during the cycle without frantically trying to beat window. Now it seems so hectic and rushed with the 2 week cycle. It was also nice to have a sense of accomplishment after finishing a 3 month cycle release. I was also much more confident in the code quality because it was thoroughly tested with eyes on screen. Now it seems much more of an endless grind and crossing your fingers. Also, I think "shippable, bug free code" in 2 weeks is a pipe dream. It's a great goal, but not often realistic in the time frame. Any time a bug comes back, it interrupts the new 2 week cycle and throws everything off. I'm not saying it's horrible, it's just not ideal. A 3 month cycle seems cleaner. It also gives user time to grasp all the changes. There are always emergency patches allowed as an exception. I don't think a 2 week cycle is the best way to do it, it's just how everyone does it right now.

kasey_junk 9y ago

I think Agile in many ways was a reaction to a trend where internal teams where cargo culting what external teams were doing. When I was literally shipping software it made sense to have longer release cycles because the cost of shipping was so high and it was a cost your clients had to pay. But for internal teams, you could ship a lot more cheaply and if you needed to redeploy you typically had the power to do that. You could also literally have the customer in the room with you, which isn't possible when you are shipping to N external customers. I think that also explains the rise of SaaS. By keeping the software on site I can ship much more cheaply, though the client negotiation part then is the more traditional model.

Clubber 9y ago
I understand what you are saying, but having done 2 week cycles for several years now, it seems a lot more chaotic to me. With the 3 month cycle, it seemed users (or at least project managers) and developers had time to hash things out before and during coding. Users could get a "look" at how the developer interpreted what they want and could offer suggestions. QA would be able to give it a thorough test with a few bounce backs during the cycle without frantically trying to beat window. Now it seems so hectic and rushed with the 2 week cycle. It was also nice to have a sense of accomplishment after finishing a 3 month cycle release. I was also much more confident in the code quality because it was thoroughly tested with eyes on screen. Now it seems much more of an endless grind and crossing your fingers. Also, I think "shippable, bug free code" in 2 weeks is a pipe dream. It's a great goal, but not often realistic in the time frame. Any time a bug comes back, it interrupts the new 2 week cycle and throws everything off. I'm not saying it's horrible, it's just not ideal. A 3 month cycle seems cleaner. It also gives user time to grasp all the changes. There are always emergency patches allowed as an exception. I don't think a 2 week cycle is the best way to do it, it's just how everyone does it right now.