Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I was recently working with a team to develop an online system. We had worked for several months and were making good progress when the project got canned. We all felt strongly that the projects completion was important and that it would have great outcomes on our consumers productivity. After being frustrated for a while I thought I should ask some people with more experience.
What is the best way to deal with the frustration of a canned project and move forward so that it doesn't hold future possibilities back?
On a well designed project, some of the code you developed can be reused in future projects, making it worthwhile. Even if you can't use any of it however, you and your team probably gained valuable experience that will help in the future as well. Think of it as an expensive team exercise.
Don't put your heart and soul into someone else's project?
I do a lot of work for different people and while some projects are more interesting than others they're not my projects so I wouldn't be too broken up if they got canned. I've got my own stuff I'm working on. No one can terminate those projects but me.
Grieve. Such a loss will produce a grief reaction. Not one as strong as though you had lost a loved one, but it's a grief reaction nonetheless, complete with all those stages of grief.
Failure is the best (and sometimes only) way to learn new things, even if the failure is not your fault. There are many different angles by which you can salvage useful information from this:
Code that is reusable
New technologies or skills garnered from the project
Lessons about project management based on how the failure was handled (maybe the project should have been canceled much sooner, before the team bought into it)
Non-technical ideas that you can reuse in other projects for the company or even in your own endeavors.
I highly recommend doing a postmortem, but don't dwell. Most projects get canned at some point in their cycle and if you let it affect your morale, it becomes a downward spiral from which it's hard to recover. You may become oversensitive to even slight requirements changes.
Attack every project as though it were your own. By this I don't mean invest all of your emotions (as stated here already by Spencer Ruport). But write all your code and organize all your code in a manner that you can easily pull out tools that you might need in the future. You never know if you will need it...but odds are you will. If you write an account manager app...do it in a modular reuseable fashion. If you write an image uploader...write it in a way that it can be ported to any other project you have. Write helper functions around all of your major features to make it more user friendly down the road.
This of course requires some planning prior to losing the gig! No worries. It rarely is because of you that you (the whole team) loses the gig. Some financial decision or business decision is usually at play. In this case most likely the economy is what killed you. In the case that you don't have any physical benefits to the failed project...look at it as a learning experience. Inevitably...no matter how good you are...you probably had something that you did that you don't or no longer agree with. Learn from that. You most likely also did something very cool that you loved. BLOG ABOUT IT! This serves two purposes..you just created something tangible from the project...and you put it somewhere that you won't forget about it.
Sucks all the way around. But at least there is a great market out there right now! Contact me directly if you want my headhunter list (80 technical recruiters in CA and the US).
Two things:
Your Investment in the Project & Code: The fact your team had such strong feelings for the project & were so frustrated on it being canned is a good sign - it means you are a true developer/programmer and are not just doing a half-job for full-pay. So to deal with the project being canned: know you & your team are committed to your work & while that project may not have panned out, you guys sound like a real credit to that project & any other you may work on. It sounds like you just need to find a project/opportunity that has the legs.
My Experience: Projects get canned for all sorts of reasons - budget, lack of confidence from stakeholders, too late to market, changed scope etc. I would enquiry/investigate why your project was canned. If it is budget or lack of stakeholder confidence then it is really good news. It means an opportunity has just presented itself to you & your team. Consider pursuing it!
Either way your team will have grown from the experience: both technically & from a business perspective.
cash the paycheck - that always helps ;-)
ask if you can have the rights to the canned project, since they don't want it, then open-source or commercialize it yourself if you think it's worthy
it's good to care about your work; it's not so good to obsess over it.
there will be other projects even better than that one in the future; they might also get canned, for any number of reasons both rational and irrational
Good example: I once worked with a lady who spent 2 years on a document-imaging project that was canned a few days before it was supposed to go live; it was canned because the new manager did not like the old manager, and the project was his "pet". This lady's reaction: "I'm looking forward to learning something new!"
This can be used to bring your team closer together, if you have the right sort of people. There is nothing quite like working hard on something you believe in and then having it canned. It can depress, but it can also motivate people to want to prove next time that they can do the job, that they had the right idea.
It helps to galvanize the team; we were there, we worked hard, and it was taken from us.
Of course, it's better not to be in that situation to start with, but when you find yourself there use it to build the team.
Sunk cost cannot be used as a reason for the continuance of a project. If the leaders have made a business decision then I'm sure that it is well motivated, however upsetting.
I'd console yourself in that big swings should be celebrated in business, big companies do not win every bid and complete every project they start. So console yourself in having lost once, maybe you might be able to change the way things were done, or focus more on the project stakeholders as well to make sure they understand why your project is worth completing compared to the other projects and business initiatives at the company.
I'll finish with my favourite saying:
"Good judgement comes from experience. Experience comes from bad judgement."
Learn from it!
Watch a Rocky movie (the last one was good) and have a few beers. There's no way not to put yourself into a project, there's no way to not feel bad about a project being terminated or failing, there's no way not to feel negative about the company. What makes a good programmer better is taking all the emotions, anger, etc. and being able to release it and move on with the same focus and dedication that was there with the first project. All part of life and all part of working in IT.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I realize that this is a subjective question, so I've marked it as a community wiki. I think that it is pretty specific to programming teams, though, so I've posted it here as opposed to somewhere else.
I'm leading a small game development team (four people) as a side project. We are a disjoint team, with everyone in different places, but we do have some of the mainstays of an organized team.
Source Control
Continuous Integration
Bug Tracking
Document Workspace
Regular Meetings
Calendar / Schedule
How do you keep your small, disjoint teams on-track? I tend to agree with Joel's opinion about when and how to micromanage and know that my team is motivated, but it can be easy to fall off-course when everyone isn't connected in a physical way and doesn't see what other people on the team are doing. Suggestions, feedback, or criticisms are welcome!
Edit: I'm managing the team; I'm not looking for automated tools or anything to do my job for me, just ideas for approach or process that might help everyone feel more "connected" and involved.
You need a Team Leader with specific skills.
Motivator: You have to keep your team Motivated. This is really hard to do, and requires a special personality. Without this skill, small teams like yours are hopeless.
1a. Request thoughtful answers to a controversial question and then after 7 minutes accept one of few answers and go on to something else. This shows that you take the long view and is highly motivating to your contributors
Intelligence: For small projects like this, it's best if the Team Leader knows something about everything. If he knows something about everything, everyone is going to follow him.
Objective: Remaining objective is very key.
Organized: You have to be the most organized out of everyone, because when things get chaotic, people run. And I would say in small projects, this is the skill that most Team Leaders lack.
I have been part of several small projects. I would guess that 90% of them fail. I would say it's primarily due to the Team Leader lacking in certain skills.
BTW. Good Luck. I couldn't be a Team leader. :)
Be a Leader: How to Change People Without Giving Offense or Arousing Resentment from "How To Win Friends and Influence People":
Begin with praise and honest appreciation.
Call attention to other people's mistakes indirectly.
Talk about your own mistakes first.
Ask questions instead of directly giving orders.
Let the other person save face.
Praise every improvement.
Give them a fine reputation to live up to.
Encourage them by making their faults seem easy to correct.
Make the other person happy about doing what you suggest.
Those are my suggestions for some helpful tactics, even if they are rather old as the book was written in 1936.
This is an interesting article about that very topic: Gaming the System.
A manager. Someone has to keep track of where folks are at and how their progress fits in the scope and time-line of the entire project. There isn't really a good way to automate this. It must be done by a human.
Edit When I worked for a game industry company, we always had to meet certain milestones to get payments from the publisher. As the manager you can break down each persons tasks into milestones as well. This way you can track the progress of each developer without bothering those who are on track with their features. It also makes it easier for the developer to know what their deadlines are in nice bite size pieces. If they are consultants, you can even pay them upon meeting their milestones. Money is great motivator ;) Another great motivator is to make all milestones open to the whole team. So if one person falls behind, others can jump in and help her meet it.
I've worked in large and small game development teams for many years and I think the most important thing you can keep in mind to hit milestones and stay on track is discipline.
Game Development seems to suffer immensely from the desire to add more and more features or focus too much energy in something that's just not that much of the final experience. Your best tool for keeping the team on track is the word "No"
So far I've been on the development end of this equation, and by personal preference rejected attempts to place me in a managerial position. Techniques I have observed are:
Set very, perhaps impossibly short deadlines. Developers will be so rushed to achieve the goals that they won't have time for any distractions. They won't have time for refactoring, cleaning up code, indenting, code review or anything else either, but as long as their code compiles they can reach the milestone and worry about debugging it later.
Have a technical project lead so dedicated to the project he'll crack the whip on all others until they produce maximum (visible) output. Also, he'll work lots of overtime and encourage others to do the same.
Weekly meetings, all hands. Some of the information exchanged about what other folks are doing and what they've learned can actually be useful.
Provide standardized equipment, software and development environments. They may be awkward to work with and developers will hate it, but at least they won't end up playing with their configuration when they could be coding.
Have a business-savvy administrative project lead who can keep customers off the developers' backs and filter requirements for them. Anytime a customer "helps" it delays progress by many hours.
Daily standup meetings done properly help a whole lot. If you keep it to:
1 what did you do yesterday?
2 what are you doing today?
3 what problems are you having?
it should remain quick and helpful. Keep in mind #3 is just to state it not to solve it. That is done after the meeting and is facilitated by the development manager or project manager.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I've been making small scale projects for a while now. I haven't started a large project, yet, because I haven't come across anything which I needed and wasn't already accomplished by some other FOSS. Until now. I want to make a program which will allow users to interactively learn secondary languages (I'm kind of want to make it as close to Rosetta Stone as I can).
Right now I'm the only developer since I'm not sure if I'm biting of more than I can chew and don't want to waste any contributors time.
So far I've been planning how the project is going to work and setting up tools to make the project start smoothly and for it to be readily accessible for when other users are ready to contribute to it. I've set up a SourceForge account, a git repository, as well as a document which lists all the features and what the program is going to accomplish.
A basic break down is that the suite is going to be written in java, and the suite will have the ability to support many languages via their locale. The courses for learning the languages will be written in jython. Course-makers will have the ability to use pre-made jython courses to teach their course, or make their own original ones. I'm hoping this will allow for the software to teach copious languages via many mother tongues.
I'm also planning on having a repository of "released courses" which are ones which I (or people who better comprehend the language) think are top-notch courses. This will hopefully make the program seem more professional and secure to the users while allowing third party participation.
With this in mind:
Are there any fatal flaws or suggestions about my project you would like to make?
Is there anything I'm missing about making a big project in general?
Thank you for your time and effort,
Joseph Pond
You will always be biting off more than you can chew if you don't believe other people should consider your project worth their time. This is much more of a leadership point than a programming point. But seriously, work it out: is this idea something that you believe can happen even knowing that you are currently unprepared for many of the challenges that you are about to face? You've given us a rough outline. You'll be giving others a more thorough explanation, and it will soon become obvious that you've overlooked some stuff. Nobody can keep that from happening to you. Having said that, if you think that you have a good grasp of the requirements of most of the components and you believe you can thoroughly describe the requirements to others with appropriate skills, I'd say go for it.
P.S. -- If you have any mock-ups, that would make it seem like a sweet deal from a prospective developer's perspective. It sounds like the selling point is the extensibility of easily designing new courses. If that's so, give an idea of the basic structure of the Jython. When my supervisor gives me a task that I understand thoroughly, I'd rather he didn't show me how to get started or what design or implementation to use. When I have no idea what he's talking about, the roughest of sketches gives me days of a head start.
Are you also the only analyst, translator, technical writer, and tester? This sounds like a large undertaking for one person. Do you have a deadline? In my opinion you will need at least another developer and tester. Even more if you have tight deadlines.
Just find the right person who really agrees with your idea and will take the ownership.
I had been involved in several projects but I dropped out some and only worked on the one I really interested in. So, look at it in the reverse side, looking for a contributor is not easy and must find the person has the things I mentioned about. Then, you can talk about keep contact,, system... project manage..etc. If you can't find the right person, even you have a good system, you are just wasting your time and going nowhere.
Okay, a couple things. First, it's better never to do a big project. Do lots of small projects instead. If it works out that what you get at the end is a big thing, that's good.
Second, a lot of times what works best for this of thing is to think about how you can make something to make it all easier. in this case, you have two issues: making something that does the various operations needed to display and give feedback (I'm working through a Rosetta Stone course myself, they're pretty cool.)
You're really thinking about a course authoring system; you can't write all the materials for all the languages, so you have to make it easy to do the authoring.
This sounds like a job for a DSL, a domain specific language.
And it sounds like a really cool idea.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
Skunk Works Project: A project carried out by one part of a company without the knowledge of the remainder of the company.
Looking for stories about any skunk works projects you've worked on or initiated:
Was it successful?
Were you found out?
Were you punished or rewarded?
How did you fund it?
How did you staff it?
How long did it take to finish, compared to above-ground projects?
What was the cost, compared to above-ground projects?
Was it formally adopted?
Excellent question. Very important question.
Geoffrey Moore (Inside the Tornado, Crossing the Chasm, etc.) has written that, as he lectured around the world, he had one question he would ask every client (including those like GE, Motorola, etc.)
The question was:
"Can you give me even one example of a truly ground-breaking, paradigm shifting innovation that has ever come out of your company's research or product development process?"
At least at the point where I read the quote, not one example had been identified. And in most cases, such products or services had been conceived, designed, and largely developed by small groups of people who at best were ignored, but were often actively opposed by R&D.
Not sure if this qualifies as a "skunk works" project, but here's a great story from This American Life. It's Act Two of this March 2005 episode.
Amy O'Leary tells the story of a
software writer at Apple Computer
whose job contract ends, but he
refuses to go away. He continues to
show up at work every day, sneaking in
the front door, hiding out in empty
offices, and putting in long hours on
a project the company cancelled. There
were no meetings, no office politics,
no managers interfering with his work.
Soon, he had written a perfect piece
of software. His final problem is
figuring out how to secretly install
it in Apple's new computers without
anyone noticing. (12 minutes)
Great listening for anyone, but especially programmers in this case.
I have actually done a number of these "Secret" project type situations. Were they are not fully supported when started, and kept very secret. I'll discuss on of these along the lines of your questions.
Was it successful?
Yes, the system developed was put into place 3 years ago, and has been functioning ever since.
Were you found out?
Yes, it was discovered, and it was part of the overall plan.
Were you punished or rewarded?
With a working prototype we were rewarded, given the extra resources needed, and eventually the system was put into place for the entire company to use.
How did you fund it?
It was a development activity that was simply completed in down-time and personal time by various people.
How did you staff it?
See the above.
How long did it take to finish, compared to above-ground projects?
We did the entire thing in about 4 months, with dedicated resources a single person could have done it in about 2 months, or a team in about 3-4 weeks.
What was the cost compared to above-ground projects?
No cost, using down-time that was already "wasted" to be put to effective use. All existing infrastructure for the final incarnation was already there.
Was it formally adopted?
Yes, it is a solid part of the business plan now, and has been for over 3 years.
We are currently in this situation, although, admittedly, the project will not have high visibility aspects - even though everyone will be eventually using it.
As part of a preparation to rebuild most of our enterprise applications, we have started developing an application framework that will be the basis for all of the replacement applications. We already have "bench projects" and "proof of concept" time that everyone is aware that we use to evaluate concepts. How it is different this time, though, is that we are actively developing a full project.
Was it successful? - We have not rolled out the full framework yet, but since it is modular, have been rolling out pieces in the legacy applications. Most of these are focused on stability and reporting/logging concerns. So far, they have exceeded expectations, allowing us to react to issues more rapidly, as well as eliminating some previously recurring ones.
Were you found out? - Well, this project has become one of the worst kept secrets I have ever seen. While there are quite a few people who have heard the name of the project thrown around a bit, I don't think anyone outside of a few of my developers and the testing team really know what it is about.
Were you punished or rewarded? - We haven't considered either side of this, yet. Unless the framework would cause negative effects, I doubt we would be punished for it. However, even if it is a success, the reward will be that no one notices anything other than improved applications.
How did you fund it? - Like mentioned before, bench time between other projects and inclusion in "proof of concept" work. I have also been putting some of my own personal time into it on my commute, since it will lay the groundwork for how all of my developers interact with the applications in the future.
How did you staff it? - I started with a series of small proof of concepts within the legacy codebase as part of "maintaining" the applications. Going in and fixing a defect often involved analytical steps on what could be done to prevent things from happening or improve the experience in the future. These were eventually extracted and refactored in their own assemblies, which became the beginning of the framework. We are now placing "covert" projects into our iterations that help flesh out these ideas through my developers, and we are now extracting and refactoring their efforts based upon the success of the implementation.
How long did it take to finish, compared to above-ground projects? - Yet to be determined. Since this is not an official project, so far it has really cost nothing. Bench time and "proof of concept" work is standard inclusion. The fact that we are essentially creating something from this time instead of throwing it away is gravy.
What was the cost, compared to above-ground projects? - Once again, yet to be determined. I imagine that the up-front cost will be relatively small compared to larger projects. Considering that this is a framework to contain commonly used extensions and improve the ability and quality of the developer to work efficiently, it will probably pay for itself before it is finished due to time-saving, improved practices, and reduction in defects.
Was it formally adopted? - The developers have embraced the concept. My immediate management is chomping at the bit. My management peers are excited, if not a little confused on what it will do. The measurement will be the success of the applications that are built off of the framework - which is some ways away still.
I built a tool to validate schema changes to the target DB at work. prior to my tool we did it all by hand with fugly scripts that DBA's at client sites had to run. my tool started tracking the structure of the database to know if certain things would work out. I got frustrated with having to hand check all this stuff or suffer from the errors inevtiable in doing things by hand so I built my validator and here is its story...
Was it successful?
Yes
Were you found out?
yes. Part of the aspect of a skunk works project is that it has to surface eventually.
Were you punished or rewarded?
Punished initially - why not work on mainstream activities. But rewarded once the benefit was made evident and product errors were reduced. Then it was heralded- everyone loves a winner.
How did you fund it?
For the love of coding it up and making my life easier - so no direct funds needed. Unless was part of managements plan to have a secret project i cannot see how this would be otherwise.
How did you staff it?
I coded alone as a lone developer on a grassy knoll with my laptop.
How long did it take to finish, compared to above-ground projects?
Not comparable. my skunksworks effort was maybe a year of tinkering. If we had set out to do it directly i cant imagine it would have taken less than 2 months directly but I do not know since thats not how it morphed. Downtime to think and plan may have made it faster in the end compared direct planning upfront.
What was the cost, compared to above-ground projects?
Undetermined - As I mentioned, given that I had down time to think and plan it was able to evovle in the direction I wanted without schedule/result pressures. In a shorter or more resource involved project we probably would have made some mistakes in rushin to get to some M1, M2 etc. Besides if it didnt work out, its would have been as if it had never happened as I could have folded up the tents and gone quietly into the night.
Was it formally adopted?
My project is a key part of the product build at my work so I would say its entrenched.
Hmm... I did one of these today actually.
We've got no real backup system in place. At present I get the highly enjoyable task of backing up 100GB of SVN repositories using svn hotcopy and .tar.gz files, while trying to juggle them across two or three NFS shares with limited disk space to get to the server with the backup disk. That's in the best case - i.e. when I can be bothered to babysit the process for 2 hours.
Since that's bound to end in catastrophe sooner or later I did a git svn clone on the largest one straight onto the backup server, then cloned that to my own machine and kicked out the svn working copy I was using. I've gained about 1GB of free space on my machine, given the most important backups some redundancy, and reduced a 15 minute svn st to a 30 second git status. And will I get complained at for it? Probably...
Generally the answers here have been success stories, so I thought I'd share my recent experience sitting just outside such a project that did not go so well.
How did you fund it?
How did you staff it?
The project started when my manager identified a potential employee, lets call him Fred, who had a pet project in our field. We don't pay well, and they they agreed that Fred would be hired and would work almost full time on the project, which they would eventually introduce to the business.
So Fred's started work on the project, known only to Fred's team but not to management or other parts of the business. Fred is a developer, and the work was more-or-less pure development, plus contributions to an underlying open-source project.
Was it successful?
Not really. Fred was working on it alone, and I think would have spent 12-18 months on it. Progress reports to the team consisted of describing whatever bug he was fixing that week. Occasional attempts were made to interest one or two higher-ups in the organization, but they never really went anywhere. Fred was supposed to put together a plan to finish and roll out the project so it could be introduced to the organization, but there always seemed to be some reason it was never done.
Were you found out?
Word slowly filtered out as Fred an the manager tried to interest more people in what they were doing.
Eventually we got restructured, and our new director wanted to know what everyone was working on, and the project was revealed to him. However, it was apparently not explained very well, since the new director wound up asking me (and others in our team I am sure) what exactly Fred's project was?
Were you punished or rewarded?
Eventually the new director froze all funding for the project and Fred was reassigned to work on other projects. That's the current status as far as I know.
How long did it take to finish, compared to above-ground projects?
Was it formally adopted?
It was not finished and it was not adopted.
What was the cost, compared to above-ground projects?
The ostensible cost was Fred's time.
However, there were other costs.
First, Fred and his project became a it of a joke in our team, and later in the teams we work with. What was he doing? Why was he doing it? Why was there no progress? Fred's reputation suffered. "Fred's project" became an in-joke for a project that was going nowhere.
Second, the eventual revelation of such a long-running but hidden project reflected poorly on our manager, and by extension on our whole team.
Third, resentment grew. Why was this guy working on his pet project when there was so much real work to be done? We are a small but busy team and we could have used a developer on any number of other projects.
In the end, I think this project has had consequences for our team's standing and dynamic. I occasionally talk it over with team members, when we're away from the office. Initially (and at the time) we were very critical of Fred, who can be an irritating guy, and who does not take criticism well, and who promised something he couldn't deliver. More recently, we've been critical of our boss. This was not a good way to run a project, and it was obvious from very early on that Fred did not have the skillset to do this work on his own and he would not seek or take advice. It was unfair to Fred that he was put in that position and left in it for so long. Lately I have wondered if I should have raised my concerns more forcefully. Though we did push Fred and our manager on what the project was and where it was going, we did not take it any further than our team. Having said that, I cannot imagine a good outcome even if we had.
Finally, I'd like to say that Fred is a smart guy and the project was not a bad one. It could have been successful (some parts have since come out in competing projects -- inferior competitors that actually delivered).
If this project had been done above board, and Fred had been working with a decent project manager and had a good communicator on the team, it could well have found a champion and delivered something great. Either that or it could have been killed a lot sooner.
I did one of these. It's actually how I ended up programming.
I was responsible for maintaining a legacy, er... "database". I won't go into gory details but it was the usual evil application. The company pretty much ran on it, it would sometimes go down for days. At the time the IS director (a friend) was actively looking for replacements, talking to large consulting organizations, etc.etc. but management was committted/emotionally invested in the existing system. I volunteered (to the IS director) to try to rewrite is (well, more like he asked if anyone was interested in trying to deal with this mess and I volunteered because I was bored). We had no real programmers on staff, and I'd only written a few small ad-hoc things. I had no idea how little I knew.
Finished the thing in about 8 months or maybe a year (this was a while ago, don't remember exactly).
Was it successful?
yes, worked as advertised.
Were you found out?
It initially started as a sort of super-secret, cloak and dagger thing. Kind of silly in retrospect, but it made it more fun. About halfway through it just started to become more obvious that that was what I was doing, and as it turned out the idea was supported. Writing this thing eventually became my job.
Were you punished or rewarded?
Rewarded
How did you fund it? / How did you staff it?
The success of it was pretty much due to the support of my boss, who made sure I had the time and resources I needed to do it.
Was it formally adopted?
Yes, we eventually ran the company on it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
We have a project coming up where the PM is insistent that the team should "eat their own dog food"?
At what point is it realistic to do this?
e.g. assume we have to write an editor. We can't use this editor at the beginning to actually code because it doesn't exist. We have to use another editor.
For a while during the project, using a buggy editor is going to slow the project down and will be counter productive.
So at what point do we switch?
Update: After some discussion within the team, the points we will stress during development are:
Implement smallest subset possible to start off with
Identify critical features asap
Only switch some of the developers to use the new product to minimise risk
Some of you should be using it as soon as you possibly can. The first version should be stripped-down, with only the most essential features that you need in order to use it as an (in this case) editor. Once you start using it you'll find out in a hurry which features are important.
<rant>
don't produce dog food, then you don't have to eat dog food.
what is the origin of this sick and stupid phrase anyway? dogs don't produce their own food (with one vulgar exception)...
</rant>
ask the PM what is more important: using the product under development to do development, or producing quality code on time? if there's a conflict, which is more important?
the common-sense answer is: use the thing you are building when it is better than the tools you have.
You don't have to switch to using the development editor exclusively. Start using it until it impacts your production, make a list of the things that are problematic, fix them, repeat until you are able to productively use it most/all of the time.
For a while during the project, using
a buggy editor is going to slow the
project down and will be counter
productive.
Sounds like you have your answer. The time to switch is when your project isn't going to impede on productivity.
This is one of those "it depends" questions. Some guidance:
What are the risks of using the project before it's fully baked? Are they acceptable?
Will the project progress faster or slower, and is this an issue?
Will the quality of the end product improve from a business point of view?
Will you end up with features that make the programmers more productive but aren't useful to the customers?
Conversely, will critical features be deferred because the developers aren't "interested" in them?
Will the "taste of the dog food" motivate your developers?
Perhaps the most helpful guide is what I call "Headrick's Rule," after the coworker who first explained it to me:
If you need someone to accomplish something, make it painful for him not to accomplish it!
The flip side, of course, is to make it pleasurable to get the project done as quickly and as well as possible. Personally, I enjoy building and using tools, so I'd serve the dog food as quickly as prudence permits. But my coworker was a sadist and would have answered, "as soon as it compiles!"
Good luck with your project!
Depending on how the development in being done you can switch earlier or later. If you are using a TDD methodology or where finding and fixing bugs is higher on the list I would start whenever you have enough features you feel would help your day to day life. This could be really early in the development if you have prioritized your features effectively.
Otherwise I would wait until you get to some of the later stages, pre alpha or pre beta. This means that you are not feeling too much pain early in the development.
As mentioned by other, if you can change your development efforts to try to make the product usable earlier do it! I would recommend to have people start using the product in earnest as early as possible to help evaluate the various features and get your initial users emotionally attached to the product. A developer who cares will often put in that extra effort to make the project just that much better.
It's about finding what your "critical mass" of features are. If it's just a matter of bugs and not features, switch now. Fix your bugs. If you are going to need to do feature development before your tool becomes useful, finish those critical features, and then switch over.
And I sincerely hope you're not writing an editor! ;-)
I guess the correct answer is as soon as you can. Of course using a buggy version is going to slow you down at first but then you will perform the QA as you are developing so in the long run you will save time.
I'll suggest that some of your team switch and not the whole team to prevent a big hold if there's a blocker in the application.
When the dog food becomes appetizing AND as soon as possible. I guess this is another way of saying that you should deliver value early and often. And, by the way, never deliver known buggy software. Fewer features without bugs is better than more features with bugs.
its all about size, scalability and scope. If the product would provide valuable success from the "dog food" approach then ASAP would be the correct answer. The end user experience dictates the end result of using the product.
Don't start using it until it reaches an "Alpha" stage. It should have all primary features complete and no known critical bugs. Then you can start using it.
It's also important to have the target users try it out, not just developers (unless it is a developer tool).
You want to have enough development time left to fit in as many "Wouldn't it be great if it did this?" features as possible.
The question is meaningless when applied to software the development team won't use itself, so the developers should use it as soon as feasible. "Feasible" means that it will work reasonably well, and won't break things too badly.
When developing a text editor, the developers should use it early, since mistakes aren't going to be crucial. When developing a version control system, the developers should use it only once it's been shown to be sound. It was something of a big deal when the Subversion team switched away from their CVS servers.
One idea would be to have earlier and later adopters among the team, as the later adopters are likely to spot things the earlier ones have become blind to.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
There are numerous Agile software development methods. Which ones have you used in practice to deliver a successful project, and how did the method contribute to that success?
I've been involved with quite a few organisations which claimed to work in an 'agile' way, and their processed usually seemed to be base on XP (extreme programming), but none of them ever followed anywhere near all the practices.
That said, I can probably comment on a few of the XP practices
Unit testing seems to prove very useful if it's done from the start of a project, but it seems very difficult to come into an existing code-base and start trying to add unit tests. If you get the opportunity to start from scratch, test driven development is a real help.
Continuous integration seems to be a really good thing (or rather, the lack of it is really bad). That said, the organisations I've seen have usually been so small as to make any other approach seem foolish.
User story cards are nice in that it's great to have a physical object to throw around for prioritisation, but they're not nearly detailed enough unless your developer really knows the domain, or you've got an onsite customer (which I've never actually seen).
Standup meetings tend to be really useful for new team members to get to know everyone, and what they work on. The old hands very quickly slack off, and just say things like 'I'm still working on X', which they've been doing for the past week - It takes a strong leader to force them to delve into details.
Refactoring is now a really misused term, but when you've got sufficient unit tests, it's really useful to conceptually separate the activity of 'changing the design of the existing code without changing the functionality' from 'adding new functionality'
Scrum because it shows where the slackers are. It also identifies much faster that the business unit usually doesn't have a clue what they really want delivered
Scrum.
The daily standup meeting is a great way to make sure things stay on track and progress is being made. I also think it's key to get the product/market folks involved in the process in a real, meaningful way. It'll create a more collaborative environment and removes a lot of the adversarial garbage that comes up when the product team and the dev teams are separate "silos".
Having regular retrospectives is a great way to help a team become more effective/agile.
More than adhering to a specific flavor of Agile this practice can help a team identify what is working well and adapt to a changing environment.
Just make sure the person running the retrospective knows what he/she is doing otherwise it can degenerate into a complaining session.
There are a number of exercises you can take a team through to help them reflect and extract value from the retrospective. I suggest listening to the interview with Linda Rising on Software Engineering Radio for a good introduction.
Do a Google search for "Heartbeat retrospectives" for more information.
I've been working with a team using XP and Scrum practices sprinkled with some lean. It's been very productive.
Daily Standup- helps us keep complete track of what and where everyone is working on.
Pair Programming- has improved our code base and helped remove "silly" bugs being introduced into the system.
iterative development- using 1 week iterations has helped up improve our velocity by setting more direct goals which has also helped us size requirements
TDD- has helped me change my way of programming, now I don't write any code that doesn't fix a broken test and I don't write any test that doesn't have a clearly defined requirement. We've also been using executable requirements which has really helped devs and BAs reach requirements understandings.
kanban boards- show in real time where we are. We have one for the Milestone as well as the current iteration. At a glance you can see what is left to do and what's being done and what's done and accepted. If you don't report in your daily standup something pertaining to what's on the board you have explaining to do.
co-located team- everyone is up to speed and on page with what everyone else is doing. communication is just-in-time, very productive, I don't miss my cube at all.