How does your bussiness manages releases?
-
Gabriel Gibaut wrote: But there is no point in time where the programmers can said, "we get to release X" and pat themselves in the back because they solved this and that. They just keep solving projects assigned and when they have 50 assigned and resolve 10, then they may find they got 70 assigned. So they feel that the list never ends and that no matter how hard they try they are always way behind the wheel.And this seems to be resenting they work. (it resented mine) We do things much the same way. Our project, hopefully, will not end. But it is a great deal with how you treat the employees. I am neither manager, nor "officially" project lead, though I did start the project on my own back in 1994. I thank the few people who work on my team and congradulate them on a job well done after every big crunch (we get a few a year). I will even occasionally buy them some goodies to celebrate getting the job done as team (nothing expensive, since it comes out of my personal money, not company). I will probably never be a manager, and I am okay with that; but I try very hard to let the team I work with know that their work is appreciated. I hope I succeed. Our releases are as needed, but often, sometimes one a week, sometimes one or two a month. With about a half dozen customers each wanting customizations it is an endless supply of bugs/features. So sometimes you just have to stop things long enough to say "thank you." _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
But there is a big difference in how things are managed...here there are no crunches, or even informal meetings to celebrate some job getting done as a team. So we programmers end feeling like machines: "I have some tasks, I solve 5 I get 10 more, I solve 10 and I get 20 and so on". And most of them are bug fixes and patches. There is never a break, and we never get some feedback about our work, from a customer or anyone... Gabriel Old C programmers never die. They just cast into void
-
I work for a small company where the concept of release is pretty broad. There is a manager that knows what new developments need to get done, what bugs need to get fixed and the estimated finalization date of all of them. But there is no point in time where the programmers can said, "we get to release X" and pat themselves in the back because they solved this and that. They just keep solving projects assigned and when they have 50 assigned and resolve 10, then they may find they got 70 assigned. So they feel that the list never ends and that no matter how hard they try they are always way behind the wheel.And this seems to be resenting they work. (it resented mine) So my question is? How do you organize your releases? How do you deal with a situation like this? I´m leaving this organization and one of the causes is this and the manager asked for some input, so maybe i can shed some light. Thanks Gabriel Old C programmers never die. They just cast into void
Gabriel Gibaut wrote: So my question is? How do you organize your releases? How do you deal with a situation like this? I´m leaving this organization and one of the causes is this and the manager asked for some input, so maybe i can shed some light. Simple - you define a release as having functionality x,y,z. Then you do no new work until x/y/z all works as expected, at least in your eyes. There will always be bug reports from the field, especially if you're so small you don't have a proper testing division. Christian Graus - Microsoft MVP - C++
-
I work for a small company where the concept of release is pretty broad. There is a manager that knows what new developments need to get done, what bugs need to get fixed and the estimated finalization date of all of them. But there is no point in time where the programmers can said, "we get to release X" and pat themselves in the back because they solved this and that. They just keep solving projects assigned and when they have 50 assigned and resolve 10, then they may find they got 70 assigned. So they feel that the list never ends and that no matter how hard they try they are always way behind the wheel.And this seems to be resenting they work. (it resented mine) So my question is? How do you organize your releases? How do you deal with a situation like this? I´m leaving this organization and one of the causes is this and the manager asked for some input, so maybe i can shed some light. Thanks Gabriel Old C programmers never die. They just cast into void
A proper manager sets goals and milestones, then manages to them. If there are 50 problems to be fixed at a certain point in time, they are documented, metrics for achieving the fixes defined, a schedule for completion set, a budget allocated, and a release point established. Subsequent problems are assigned to a future release point, accumulated until a reasonable cutoff date, then the process is repeated for the next release. Anything less is incompetent management, allowing feature creep to manage the project, rather than the manager. Denying the staff definite goals and endpoints for their efforts will eventually demotivate them to the point of burnout. I pity you, if you remain there. Your professional life will die a painful, slow, pathetic death. You will take to wearing suspenders and a beard, drinking too much, and boring your younger colleagues with tales of the "good old days." Your children, if you ever breed, will put you in a cheap nursing home with no outgoing telephone service, serving cold pizza three times a day. You will end your days working crossword puzzles in the back of the few technical magazines you can still get delivered for free, and will eventually do yourself in with a stubby pencil. Get your boss' resume, send it to head hunter, and get him a better job. Maybe you'll do better next time. Do it now - your life depends on it! "...putting all your eggs in one basket along with your bowling ball and gym clothes only gets you scrambled eggs and an extra laundry day... " - Jeffry J. Brickley
-
A proper manager sets goals and milestones, then manages to them. If there are 50 problems to be fixed at a certain point in time, they are documented, metrics for achieving the fixes defined, a schedule for completion set, a budget allocated, and a release point established. Subsequent problems are assigned to a future release point, accumulated until a reasonable cutoff date, then the process is repeated for the next release. Anything less is incompetent management, allowing feature creep to manage the project, rather than the manager. Denying the staff definite goals and endpoints for their efforts will eventually demotivate them to the point of burnout. I pity you, if you remain there. Your professional life will die a painful, slow, pathetic death. You will take to wearing suspenders and a beard, drinking too much, and boring your younger colleagues with tales of the "good old days." Your children, if you ever breed, will put you in a cheap nursing home with no outgoing telephone service, serving cold pizza three times a day. You will end your days working crossword puzzles in the back of the few technical magazines you can still get delivered for free, and will eventually do yourself in with a stubby pencil. Get your boss' resume, send it to head hunter, and get him a better job. Maybe you'll do better next time. Do it now - your life depends on it! "...putting all your eggs in one basket along with your bowling ball and gym clothes only gets you scrambled eggs and an extra laundry day... " - Jeffry J. Brickley
Roger Wright wrote: "...putting all your eggs in one basket along with your bowling ball and gym clothes only gets you scrambled eggs and an extra laundry day... " - Jeffry J. Brickley :-O _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Roger Wright wrote: "...putting all your eggs in one basket along with your bowling ball and gym clothes only gets you scrambled eggs and an extra laundry day... " - Jeffry J. Brickley :-O _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
I consider that bit of wisdom quite quotable... Thanks!:-D "...putting all your eggs in one basket along with your bowling ball and gym clothes only gets you scrambled eggs and an extra laundry day... " - Jeffry J. Brickley
-
I consider that bit of wisdom quite quotable... Thanks!:-D "...putting all your eggs in one basket along with your bowling ball and gym clothes only gets you scrambled eggs and an extra laundry day... " - Jeffry J. Brickley
Roger Wright wrote: I consider that bit of wisdom quite quotable... Thanks! You are quite welcome... I am famous.... I'm buying the next round... what's everyone having? ;) _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Roger Wright wrote: I consider that bit of wisdom quite quotable... Thanks! You are quite welcome... I am famous.... I'm buying the next round... what's everyone having? ;) _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
I've already had 5 beers and 4 scotch & waters. I think I'll have a nap now, and one more workday until the three-day weekend. Have a great one, and "goodnight!":-D "...putting all your eggs in one basket along with your bowling ball and gym clothes only gets you scrambled eggs and an extra laundry day... " - Jeffry J. Brickley
-
But there is a big difference in how things are managed...here there are no crunches, or even informal meetings to celebrate some job getting done as a team. So we programmers end feeling like machines: "I have some tasks, I solve 5 I get 10 more, I solve 10 and I get 20 and so on". And most of them are bug fixes and patches. There is never a break, and we never get some feedback about our work, from a customer or anyone... Gabriel Old C programmers never die. They just cast into void
That's not good. As developers we largely only see the problems - the bug reports, compromises and inadequacies in the code, etc. That's a distorted picture, which without balance can demotivate even the most enthusiastic developers over time. One way to do this is to give everybody a perspective on how your users interact with your system and what they like about it. If your team get to meet customers occasionally (trade shows are good for this - you also get to see how the competition measures up), that's even better. Customer feedback is not just about bug reports, after all. Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
-
I work for a small company where the concept of release is pretty broad. There is a manager that knows what new developments need to get done, what bugs need to get fixed and the estimated finalization date of all of them. But there is no point in time where the programmers can said, "we get to release X" and pat themselves in the back because they solved this and that. They just keep solving projects assigned and when they have 50 assigned and resolve 10, then they may find they got 70 assigned. So they feel that the list never ends and that no matter how hard they try they are always way behind the wheel.And this seems to be resenting they work. (it resented mine) So my question is? How do you organize your releases? How do you deal with a situation like this? I´m leaving this organization and one of the causes is this and the manager asked for some input, so maybe i can shed some light. Thanks Gabriel Old C programmers never die. They just cast into void
Isnt this also to do with the Developer / programmer question. As a developer you should have some interaction with the customer so you would have some input into when a release is done and whats in it. As a programmer your job is to work on specific code related tasks. wether or not they are related to a specific planned release is really not your concern. Your situation actually sounds like it could be quite an efficient system (providing management know what they are doing). Coding tasks are allocated (presumably with some sort of prioriy or deadline) and management should have in mind a set release plan. If you dont like it perhaps you are a developer trapped in a code monkeys job. I personally really like the time i spend with customers and couldn't do a code monkey job. Jon
-
That's not good. As developers we largely only see the problems - the bug reports, compromises and inadequacies in the code, etc. That's a distorted picture, which without balance can demotivate even the most enthusiastic developers over time. One way to do this is to give everybody a perspective on how your users interact with your system and what they like about it. If your team get to meet customers occasionally (trade shows are good for this - you also get to see how the competition measures up), that's even better. Customer feedback is not just about bug reports, after all. Anna :rose: Riverblade Ltd - Software Consultancy Services Anna's Place | Tears and Laughter "Be yourself - not what others think you should be" - Marcia Graesch "Anna's just a sexy-looking lesbian tart" - A friend, trying to wind me up. It didn't work.
Anna-Jayne Metcalfe wrote: trade shows are good for this - you also get to see how the competition measures up Amen! There was a brief period in our corporate history (mid 90's) during which it became policy that all engineers went to a trade show. It was really cool seeing the competition and talking to our customers. The single event that stands out in my mind was talking to one of our own salesmen. I went to a show in Chicago. On the first day, I walked up to our booth, and one of the local salesmen in front of my product started 'talking me up' about it. I let him rattle on until he said something that wasn't quite true. I said "You know, that's not quite right. It really works this way...". He started trying to correct me, but then dropped his teeth when I told him "I ought to know. I wrote it." At which point, I pulled out my name badge and put it on (big corporate logo, name, and position). To the guy's credit, after I explained what he'd misunderstood, he agreed. After some discussion, we eventually changed that feature to work differently. The original implementation wasn't very intuitive, and it was easy to see why people misunderstood it. Unfortunately that policy of having engineers go to shows fell by the wayside. Someone figured out that we were losing half a man-year of engineering time by sending people to trade shows, not to mention travel expenses and so on. Now, our only contact with customers is when we get sent to trouble sites, or for evaluation visits for custom work. Neither of these settings are particularly fruitful, given that you hear only a single customer's view.
Software Zen:
delete this;