4 ms·

I've worked in a variety of environments, and the most important thing in my experience is simply to ensure that your team is creating a working, tested, and "s

by ozmbie 9y ago

I've worked in a variety of environments, and the most important thing in my experience is simply to ensure that your team is creating a working, tested, and "shippable" update every ~2 weeks. It amazes me how many teams fail to do this, despite calling themselves "agile" and "customer driven". Use whatever methodology, technology, and processes you need to accomplish that singular task. Orient your entire organisation around doing that. Your customers don't care how you do it. They just want frequent updates and progress. And if you're not giving them useful updates (you'll know, they'll tell you) then the problem isn't methodology, it's probably your ideas. No methodology will fix that.

amelius 9y ago
Customers want updates? I want my software to stop changing!
- tfigment 9y ago
  Depends on the product but indeed I want stability over all else with updates for security. We have a product sold to us 2 years ago and still hasn't passed UAT. It is enterprise and they use agile so after every 3 to 6 weeks we get a new build to verify. There is always something new that fails so we go back to waiting. At this point I wish I could write the thing ourselves as I would have been done 18 months ago.
savrajsingh 9y ago
How about every week? :)
maxxxxx 9y ago
This only works in certain kinds of projects. I often work on projects where you need to spend months figuring out some technologies and see what works best. For a while we tried to deliver "shippable" updates every 3 weeks but this just created a lot of work creating artificial prototypes without any real benefit so we gave up. If you work on some web site where the tech is well understood then shipping something every 2 weeks probably works.
- silvestrov 9y ago
  > figuring out some technologies That is research, not software development. For software development you know your tools and how to use them, and only what the resulting product should be is slightly unknown.
  - maxxxxx 9y ago
    I call myself a developer but I often work on stuff where at the start we don't know whether it will be desktop, web, mobile or whatever. We don't know which database will be best so we try a few. I guess it's research but it feeds straight into development which is done by the same people within the same project.
    - zo1 9y ago
      >"We don't know which database will be best so we try a few." There is but a handful of valid choices for a relational database, and all of them pretty much able to handle every single thing you can throw at it. Or are you just trying out "flavors" of database? In which case you're wasting the client or employer's time/money, in all honesty.
      - maxxxxx 9y ago
        I work in medical devices. We can store data directly on the device, on some other device, the cloud or our data center. All have their advantages and disadvantages regarding security, maintainability, battery consumption and a lot of others. There is no clear answer up front so you have to try a few approaches and see how they go.
  - varjag 9y ago
    Both are typically filed under R&D on expenses reports and more often than not done by the same people.
humanrebar 9y ago
> "shippable" It's less vague, more value, and barely more work to replace "shippable" with built (no scare quotes), packaged (no scare quotes) and demoed. The first two can be automated. The third is a matter of getting the right people to show up for a quick meeting. If that's too hard, you can just post a changelog including screenshots, animated gifs, etc. if needed. Notice that I didn't say the product should be shipped. That's varies a lot from domain to domain and project to project. Sometimes even feature to feature.
Clubber 9y ago
>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.
wott 9y ago
You still have a whole variety of environments to discover, I believe :-) In none of the situations I've been working, updates as frequent as 2 weeks have been a request. It would have been either a nightmare to do that (you end up spending 50-80% of your time delivering under pressure), or just impossible (in cases where testing, verification, delivery takes 1 to 3 months), and in every case simply unwanted.

by ozmbie 9y ago

amelius 9y ago

Customers want updates? I want my software to stop changing!

tfigment 9y ago
Depends on the product but indeed I want stability over all else with updates for security. We have a product sold to us 2 years ago and still hasn't passed UAT. It is enterprise and they use agile so after every 3 to 6 weeks we get a new build to verify. There is always something new that fails so we go back to waiting. At this point I wish I could write the thing ourselves as I would have been done 18 months ago.

savrajsingh 9y ago

How about every week? :)

maxxxxx 9y ago

This only works in certain kinds of projects. I often work on projects where you need to spend months figuring out some technologies and see what works best. For a while we tried to deliver "shippable" updates every 3 weeks but this just created a lot of work creating artificial prototypes without any real benefit so we gave up. If you work on some web site where the tech is well understood then shipping something every 2 weeks probably works.

silvestrov 9y ago
> figuring out some technologies That is research, not software development. For software development you know your tools and how to use them, and only what the resulting product should be is slightly unknown.
- maxxxxx 9y ago
  I call myself a developer but I often work on stuff where at the start we don't know whether it will be desktop, web, mobile or whatever. We don't know which database will be best so we try a few. I guess it's research but it feeds straight into development which is done by the same people within the same project.
  - zo1 9y ago
    >"We don't know which database will be best so we try a few." There is but a handful of valid choices for a relational database, and all of them pretty much able to handle every single thing you can throw at it. Or are you just trying out "flavors" of database? In which case you're wasting the client or employer's time/money, in all honesty.
    - maxxxxx 9y ago
      I work in medical devices. We can store data directly on the device, on some other device, the cloud or our data center. All have their advantages and disadvantages regarding security, maintainability, battery consumption and a lot of others. There is no clear answer up front so you have to try a few approaches and see how they go.
- varjag 9y ago
  Both are typically filed under R&D on expenses reports and more often than not done by the same people.

humanrebar 9y ago

> "shippable" It's less vague, more value, and barely more work to replace "shippable" with built (no scare quotes), packaged (no scare quotes) and demoed. The first two can be automated. The third is a matter of getting the right people to show up for a quick meeting. If that's too hard, you can just post a changelog including screenshots, animated gifs, etc. if needed. Notice that I didn't say the product should be shipped. That's varies a lot from domain to domain and project to project. Sometimes even feature to feature.

Clubber 9y ago

>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.

wott 9y ago

You still have a whole variety of environments to discover, I believe :-) In none of the situations I've been working, updates as frequent as 2 weeks have been a request. It would have been either a nightmare to do that (you end up spending 50-80% of your time delivering under pressure), or just impossible (in cases where testing, verification, delivery takes 1 to 3 months), and in every case simply unwanted.