As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
What kind of software development (projects) can kanban be used for and what are the requirements to implement it? I was reading a lot about kanban and how great it is. But now i have to write a paper about it that focuses of the requirements for kanban, and especially for what kind of projects kanban doesen't fit. I couldn't figure it out yet.
KarlM gave a good overview.
I think Kanban can be used in any project, because it takes your existing process and visualizes it, introduces WIP (multitasking) limits, and uses pull to maximize flow and minimize lead time. My team recently migrated to Scrum and it's been a very smooth transition so far.
Kanban is especially good for situations in which a standard iteration doesn't make sense.
For example, you might not have frequent releases. Maybe you want to decouple one or more of your planning, demo, retrospective, or release schedules.
Good examples:
Maintenance project. Even though you might want to have 2-week (or whatever) meetings to discuss priority, retrospectives, etc., you're probably not going to demo or release every 2 weeks, and it's not likely you'll be able to commit to everything in the next 2 weeks anyway. Situations like this are so dynamic that the priorities shift every day, as new feedback comes from customers. Scrum or other iterative processes don't make sense in this case.
There is a real need for stories that are longer than your iteration length. Kanban, like Scrum, thrives with small stories (better flow, slack, etc.), BUT, unlike Scrum, it DOES at least allow large stories if really necessary.
Extremely fast-paced development. Continuous deployment. Iterations no longer make sense, because maybe you're responding to change lighting-quick, and maybe releasing multiple times a day!
See code.flickr.com:
Flickr was last deployed 4 hours ago, including 8 changes by 2 people.
In the last week there were 85 deploys of 588 changes by 19 people.
Do you think Flickr is doing 2-week iterations, or even 1-day iterations? I doubt it. Looks like they're in super-speed dynamic flow mode... Maybe Kanban, but definitely looks like they're in the Lean umbrella. (Kanban falls under the umbrella of Lean thinking, and continuous deployment was made popular by last year's book by Eric Ries, "The Lean Startup".)
It might not fit in the following environments:
Organizational culture can't get away from up-front planning, overwork/commitment, push instead of pull, fixing all of schedule, scope, and cost, etc. Kanban will start to provoke continuous improvement in an organization, and many are simply opposed to anything but the traditional overengineering, overdocumented, siloed, non-Lean, non-Agile approach that they know and love, which is waterfall. Some government contracts might also fall under this category, although I believe at least DoD is trying to advance Agile in its projects now. But some companies, if you tell them they need to do LESS (i.e., limit work in progress, have a clearer vision, get less stuff done faster, but therefore more stuff done overall), will have a heart attack. Many (most?) companies are addicted to overwork, and think SLACK (which is a fundamental Lean principle) is a 4-letter word. Unfortunately, queuing theory and theory of constraints is hard to get through some people's heads. :) So Kanban might not fit in those kinds of places. ;)
The requirements are, that everyone on the project agrees to use the principles and practices:
Principles
1. Start with what you do now
2. Agree to pursue incremental, evolutionary change
3. Initially, respect current processes, roles, responsibilities and job titles
4. Encourage acts of leaderships at all levels
Practices
1. Visualise what you do / knowledge discovery
2. Limit work in progress
3. Measure and manage flow
4. Make policies explicit
5. Develop feedback mechanisms
6. Improve collaboratively using models and the scientific method
If they don't agree to do that, they can't use kanban. Pretty clear.
Kanban is a tool for visualizing and improving existing processes. If there's a scenario in which it won't work, that scenario would probably have one or both of two properties.
1) There is no existing process or the existing process is such a disaster that it is not working at all and/or is constantly changing in a chaotic manner.
2) There is no will or opportunity to improve.
Lacking the second is not a deal-breaker. Kanban could still help with communication and coordination, and increasing clarity might lead to an increased desire to improve or help establish trust necessary to empower improvement experiments. That would be an example of a low-maturity Kanban implementation leading to a higher level of team maturity.
Kanban is a simple process tool. Applied well, it is good for any project, not just software - any.
In my opinion Kanban can be implement in any kind of organization and in any industry.
But...
the team must be ready for a change
the change must has an evolutionary character
the organization must be focused on cooperation instead of performing routine work.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
We are starting to use Kanban and my boss just asked me a question, as one of two people with prior Kanban experience within the group, that I don't really know how to answer.
My previous experience and training with Kanban had developers pulling stories in from the backlog by priority, in our case that was the topmost card. However, my boss would like certain stories to go to the developers that have domain knowledge for particular areas. For example, let's say Joe has the most experience in working with Contracts and a contract story comes onto the board. He would like Joe to be the one to work on that particular story.
This, to me, feels a little "off" and could lead to some developers having significant extra work due to having worked in any given area of functionality. My previous experience with Kanban worked under the assumption that any developer should be able to pick up the next card and figure out what to do and that this practice would eventually eliminate any single functionality area experts and level out developer expertise over time. However, I can also see how using subject matter experts can help move a story through the process faster.
What is the most "Kanban" way of handling priority vs. expertise when it comes to pulling in the next story?
Every system I've ever worked with allows a little bit of developer-level of prioritization. If the next card has the absolute (top-down driven) priority, then you have to pick that card. Mostly, though, I tend to work in places where "these next 6 cards are up, pick the one you like". This gives the developer a little bit of room for type of work he or she prefers. Plus, it gives the developers a greater sense of ownership since they did get to pick (to some extent) the work they were doing.
Regarding your example, it's a little off base. In an ideal world any developer should be able to pick up any card. In reality, this isn't always true. If I give this project to Jim, it might take 2 days. If I give it to not-Jim, it make take all week. This is a sign! What information sharing is missing? How do you get the other developers to understand the Contracts component as well as Jim?
If the priority is a little bit gray, this stuff tends to work itself out. All the other developers know that Jim can handle the Contracts stuff. However, if Jim has no capacity, then someone else must take up the challenge. Kanban is supposed to alert you to blocked stories.
Kanban is great for visualizing work flow, limiting WIP, and exposing bottle necks.
Henrik Kniberg has a great book, 'Lean from the Trenches'. He talks through many techniques he has used in real world examples. He described one approach to having avatars (that represent developers) that can be placed over task to show who is working on what.
One idea for your situation, would be to use this avatar approach to pre-assigning who should work on a task in the buffer leading into development.
If those pre-assigned tasks are not causing bottlenecks and flow is natural, everything is good. If they are causing bottlenecks early in your flow, you have a problem, but now you have an easy way to visualize and see that it is the pre-assigning that is causing your bottle neck!
A Kanban system shall display the real process. If the manager is assigning stories to developer then the system should reflect that. This can be done in several ways, you could have a specific item for developer X or you can write the developers name on the card. Another option is to have one swim-lane for each developer.
However, all of this is probably not good from a "global" perspective. You should share your Kanban data with your boss. What are your lead-times, what is your throughput etc? Then you should invite the boss to the process improvment meeting. How are we going to improve our figures? Hopefully he sees that Joe probably will be a bottleneck if he is assigning tasks directly to him. Teach him Littles Law, teach him about bottlenecks and Lean in general.
Don't forget to make your policies explicit, that is, it should be written on the wall how your prioritzation policy looks like. Good luck!
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 5 years ago.
Improve this question
We are currently utilising an agile environment in work. One of my tasks involve setting up a release timetable. A part of this is providing a time frame of how long a project would take to go from a development environment, to staging and then live.
I have conflicting thoughts regarding whether such a timetable needs to be done.
For a start, we are quickly moving into a Continuous Integration / Constant Delivery environment where an application is tested amongst all environments when a change is made to the code base. Therefore, there is no time frame, but things should be "just" deployable. (Well, we always need a little bit of contingency as the best laid plans can always go awry)
Can anyone steer my in the right direction on what would be the best way to handle such time tables and timeframes if needed in Release Management in an Agile Product Development Environment.
Regards,
Steve
Can anyone steer my in the right direction on what would be the best way to handle such time tables and timeframes if needed in Release Management in an Agile Product Development Environment.
First of all the Scrum Framework guidelines never guides you to not have a Release Plan or Time table ever. What is leading you to have conflicting thoughts? I would like to know the source which is leading you to this conflict.
Best way to create a Release Plan is like this (this may take a week or so depending on the size of your project):
Get the Stakeholders in a room and get a EPIC user story written on the board using their guidance. The EPIC user story should include the end product vision. (ignore if already done)
List out the type of users.(ignore if already done)
Break the Epic user story into smaller and smaller chunks of user stories till they are small enough to be doable in sprints.(ignore if already done)
Ask the Product Owner(s) of the Scrum Team(s) to prioritize the stories in the uncommitted backlog list(s) Also do some form of effort estimation fairly quickly and do not waste a lot of time estimating.
Get the target end date or Go Live date of the project from Stakeholders.
Divide the time frame from now until the end date into Releases. Ask the stakeholders which features need to be delivered by when and include the appropriate user stories in them, and call them Releases. You can also give those Releases themes if needed.
The Release Plan now is conceptualized.
After this draw it on a white board or put it in a visible and transparent location where everyone can see it - add user story cards to the appropriate release.
Now your initial release plan should be ready
Ideas for implementation:
Form a Scrum Team specifically for Operations Activities. They could follow Scrum or Kanban would be better.
As and when Development teams get "shippable products" put in the shelf, the Operations Kanaban Team can do the deployment and release branching etc tasks as per the Release Plan.
So this way the development Teams don't really focus on the Release plan or work, just the Operations Team does that. The Development Team just focussed on the Sprint Work, it would be the Product Owners headache to make sure the right user stories are in the right Release and in the right order. The direction would be given by the Stakeholders.
To be honest you really don't have to do anything yourself, it's all in the stakeholders and POs hand, I don't know where is is the fuss??
I hope you get the picture.
I usually maintain a release plan for the management that is mainly based on a combination of the estimated & prioritized user stories (I group them to match a main new feature of the product) and velocity.
With a well maintained product backlog it's pretty easy to do your release plan. I usually plan three to four releases a year.
What I like with Scrum is that I can potentially release after each iterations.
If you want to master your release management, you will need more information that few answers of practionners. I highly suggest you this book.
If you currently utilising and agile environment you should check Agile estimating and Planning book for some suggestions. This book also contains small chapter about Release planning.
Some release planning should be always done. Release is a target wich usually covers 3-12 months of development = set of iterations. It something which describes target criteria for project to success. It is usually described as combination of expected features and some date. Features in this case are usually not directly user stories but epics or whole themes because you don't know all user stories several months ahead. Personally, I think release is something that says when the project based on vision can be delivered. It takes high level expectations and constraints from the vision and converts them to some estimation. You can also divide project to several releases.
But remember that three forces works in agile as well. There is direct relation among Feature set, Release date and Resources (+ sometimes also mentioned fourth force: Quality). Pushing one of these forces always move others. It is usually modelled as equilateral triangle (or square).
There are different approaches to plan a release. One is mentioned in the book. It is based on user stories estimation, iteration length selection and velocity estimation but I'm little bit sceptic to this approach because you don't have simple user stories for whole release and estimating epics and themes is inaccurate. On the other hand high level feature definition is exactly what you need for three forces. If you don't have enough time you will implement only basic features from all themes. If you have more time you will implement more advanced features. This is task for product owner to correctly set business priority when dividing epics and themes into small user stories.
The most important part in agile is that you will know more quite soon. After each iteration you will have better knowledge of your velocity and you will also reestimate some planned user stories. For this reason I think the real estimate (accurate) and realease date should be planned after few iterations. As I was told on one training effort should not be estimated, effort should be measured. If anybody complains about it show him Waterfall and ask him when will he get relatively accurate estimate? Hint: Hardly before end of analysis wich should be say after 30% of the project.
It is also important what type of projects do you want to implement using agile / scrum and how long will project be. Some projects are strictly budget or date driven others can be more feature driven. This can affect your release planning. For short projects you usually have small user stories and you can provide much more accurate estimate at the beginning.
This is a very loaded question, and depends on your company to be sure. I first have to ask, why are you using 3 environments and continuous integration (your reason matters)? Are you performing automated tests at all? How are your code branches setup? Do you release for some functionality, or just routine maintenance fixes?
Answering these will give you an idea of why you need a release, and how you should go about it.
For example, if you only have a staging environment for the purpose of integration and perform automated tests, then can't having a separate code branch in which continuous integration tests run be sufficient?
If staging is to perform some sort of user acceptance, does your company have a dedicated testing team or are they members of the agile teams?
As you correctly stated, if the code is always integrated and tested, then why would you need a timetable and moving from environment to environment unless you were unsure about the actual "done" condition of the features? By that, I mean that it's not that you're unsure that the feature was coded correctly, but are you worried it will introduce other bugs? Will it integrate well with code already in production? Address the concerns at the root of the problem. Don't just do it because you think you're supposed to have X environments or testing should be in another group. Maybe the solutions to those problems may be to adjust the definition of "done" accordingly.
As you can see there are many, many factors that will make your organization unique. There is no one right way to answer this, just tradeoffs that you are willing to accept.
I find that having multiple environments with teams of people working at the various layers tends to be anti-agile and counterproductive. The best bet is to analyze your concerns, and try to find ways to solve them (such as expanding the definition of "done", or breaking up the various organizations and putting them on the teams, eliminating as many environments as possible and simplifying the process, etc). That may not be possible in your organization, so you may have to live with tradeoffs.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
This is not a programming question per se, but here it goes. I am a senior CS undergrad, and I started an internship this summer for a mid-sized software company. I've done a few freelancing jobs before, but it's the first time I've been officially (more or less) employed as a software developer.
I've been asked to code an internal website from scratch to be used by separate teams in the company, and I've been given a lot of flexibility in designing it. And therein lies the problem: we've had several meetings and design reviews and everyone seems to have an idea on a new feature, and even conflicting ideas on how things should work.
So far my initial prototype has survived all of this, which is something I was told not to expect - but I knew I had a solid design. While I am not behind schedule, the work is progressing significantly slower than I had predicted. A lot of this has to do with loose specs and constant features requests and changes.
I am to deploy an alpha in a couple of weeks, which I thought wouldn't be a problem, but the way things are going I am not sure how that's going to work out.
Does anyone have any ideas?
Thanks in advance
You are asking a timeless question about (software) project management. There are careers made writing books on the subject.
I agree generally with rockinthesixstring on this.
If you don't have an effective project manager who can filter the customters' requests and manage their expectations, and say "no", then that will have to be part of your job.
Sometimes there is an art to not saying "no". Sometimes you can say it more like "As you see in the schedule, version 1.1 is going alpha next week. The feature list for version 1.2 is already set. I'll add your new feature to the top of the list for 1.3. But if you like, I can call a meeting with the other teams to see if we can reprioritize the 1.2 features."
As to conflicting ideas, if there is no other "decider", than that becomes part of your job as well.
Understand that not everyone will get their way.
Without an approach that addresses these sorts of issues you simply won't succeed by any measure.
I'd start by locking into the features that have been agreed upon and place all feature requests into some sort of project planning software (OnTime Perhaps). Then roll out the Alpha release with the agreed upon specs before moving onto the "we'd like" and the "bells and whistles".
You need to prioritize and triage feature requests, possibly even some of the ones you have already agreed too.
It sounds like product ownership is not clear (as can be expected with internal projects with multiple teams). You should probably run some form of planning game. If you have multiple stakeholders, you might give them each 50 points to vote on all the features in an iteration.
You, as developer, decide how large each feature is. The features with most points/size get into the iteration. If some teams are more important, give them more points. You should also spend some points yourself.
I would like to express my approval of James McLeod's post. The only justification anybody needs for wanting a feature is "user x might try to...". The difficulty is resolving contradictions between their opinions and somebody else's. The feature with a higher 'priority' as assigned by your project management process is the one that gets implemented, at the expense of its competitors if necessary. Ask the people suggesting features to go away and put something down on paper explaining the reasoning behind the feature and the circumstances they think might preclude its inclusion. Letting everybody else see what limitations they think their approach has could help break a decision deadlock. The feature whose case is stated more thoroughly 'wins'.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Joel Test is a good and famous list checking some requisites every software company should concern about.
They are:
Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?
My current company hits 0 (I said ZERO) points when I arrived there some month ago. Now we 'proudly' hits 3 - source control, one step build and daily builds. But I'm trying to do more (bug database, wiki, quiet conditions, better interviews...)!
What about your company? How many hits? List what you will do to achive more!
My current project: 1 Y, 2 N, 3 N, 4 Y, 5 N, 6 N, 7 N, 8 N, 9 N, 10 Y, 11 N, 12 N
Total score: 3
Guess what, it sucks. The dev team has been pushing hard for 2, 3, and 5, but it never quite gets approved by management. The operational software is so buggy that hack fixes take all the time and no one is allowed to do these "low priority" type activities.
A funny thing is that this project is in a CMMI level 5 company. Goes to show what that is worth.
Do you use source control?
Of course, I simply cannot understand how companies cannot see the necessity for a decent source control system. We're using SVN. Total: 1 point.
Can you make a build in one step?
Our build process takes at least 5 steps and although we discussed a lot of times ways to make the magical 1-step-build happen, we did not find the time to implement that scenario yet. Total: 1 point.
Do you make daily builds?
Yes. As stated before, they're not created automatically, but we have daily builds incorporated into a code-review step we do every day. Total: 2 points.
Do you have a bug database?
Yes, Mantis is used by our company for this purpose. Total: 3 points.
Do you fix bugs before writing new code?
Unfortunately not. New features seem to be more important than bugfixes. Up until the time, when they definately need to be fixed. Which is often way too late. Total: 3 points.
Do you have an up-to-date schedule?
We update the schedule all the time, using burndown-charts to estimate the time we're finished. Total: 4 points.
Do you have a spec?
We have some specs, but I wouldn't call our projects spec-complete. There is much room for improvements here at our company. Total: 4 points.
Do programmers have quiet working conditions?
Yes, our company building resides in a quiet neighbourhood, with no more than 2 or 3 developers in the same room. Total: 5 points.
Do you use the best tools money can buy?
Nope. Total: 5 points.
Do you have testers?
We have only recently implemented an entire QA-department consisting of three testers. Total: 6 points.
Do new candidates write code during their interview?
We do not have too much fluctuation in our team, but the interviews contains a couple of coding-relevant questions where the candidates have to write some sample classes etc. Total: 7 points.
Do you do hallway usability testing?
No, sadly not, but it's a great idea. Total: 7 points
All-in-all I think there's a lot of room for improvement, but 7 points might not be the worst score compared to other companies we're working with.
Right now, we hit number 5 sometimes if we know about the bug and 8 99% of the time time.
Tomorrow, I'll be meeting to push for 1, 4, 5, 6, and 7. I think the only thing you can do is pick one or two and go after those. Set something up, start using them and show everyone else how much easier/better your life is with them.
One (1). we have source control. but it's a small start - up company, so I still have high hopes.
Current Company across most projects, some are worse(much worse!)
1:Y, 2:Y, 3:Y, 4:Y, 5:N, 6:N, 7:Usually, 8:N, 9:N, 10:N, 11:N, 12:N
For me the big issues in my current Company are 10 and 11.
We don't have a dedicated test resource even though we have a development resource of 100+ developers, not one professional tester! Guess what? Testing aint't good, I surprised at the quality of applications we produce, a testiment to the quality of some of our development teams.
Our interveiew process sucks big style. One developer that we hired recently only had a background in C and emdedded code for satelight receivers. Bearing in mind we're microsoft/.NET/VB6/SQL Server. He had no experience what so ever with databases of any description or WinForms development.
When I quizzed how he got hired I was told by the technical lead who was on the interview panel that personnel had banned him from asking TECHNICAL questions because when the guy had been invited to the interview he wasn't told it was going to be a technical interview!
I have mixed feelings about #11. On the one hand, I think a few casual interview white board questions can be very misleading. Candidates don't always expect it, they are nervous and asked to code in front of an audience. Gah! On the other hand, I feel like you could get a feel for how someone would fit in your organization with a short computer quiz.
If you use a temp service with temp to hire, does that count if you do code reviews on their early work? Then the job becomes the quiz.
The problem with the Joel test is that even hitting 12 doesn't mean that you're working for a good company. Although if you're at zero you're probably not.
I currently have a client that is running a seven which means that in theory they're not doing too bad. The fact is they're still pretty badly screwed up because of other issues (poor architecture, lack of management support, etc.)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does your work environment use Harvest SCM? I've used this now at two different locations and find it appalling. In one situation I wrote a conversion script so I could use CVS locally and then daily import changes to the Harvest system while I was sleeping. The corp was fanatic about using Harvest, despite 80% of the programmers crying for something different. It was needlessly complicated, slow and heavy. It is now a job requirement for me that Harvest is not in use where I work.
Has anyone else used Harvest before? What's your experience? As bad as mine? Did you employ other, different workarounds? Why is this product still purchased today?
I had the benefit of using Harvest at a bank and you'll never find a more wretched hive of scum and villainy, backwards triple-forking undocumented check-in gauntlets that require 15 steps to make one simple change. Nevermind that they weren't even using branching. This is an evil tool don't let it get you in its clutches.
Chances are, your company has some sort of contract with CA - are you using a lot of other CA software in-house?
Edit: Guess so!
OK I'm going to answer this in a couple of episodes because its late here and Harvest is a big topic.
Firstly CA Harvest (which is what version 7 of the product is called, version 5 is CCC which I cant recall the expansion, version 12 is called CA SCM) is a lot more than just a SCM tool - in the same way ClearCase is a lot more than an SCM tool. SVN, CVS, git, hg are all base-standard SCM and little more.
What you get with Harvest is SCM + Policy. It gives you a place to store and version your code and wrap it all in a policy of how that code matures though your organization from dev to prod. Do you have a policy in your organization that a Lead Developer needs to sign off on the code before its released to QA ? Harvest allows you define the signoff as a policy, and enforces it - you cant migrate the code from the "Dev" state to the "QA" state until one of the people in the project designated as a Lead Dev does exactly that. Do you have a policy that any SQL code needs signoff by a DBA before it progresses ? Harvest allows you to define that policy, and enforces it - so you might need both Lead Dev and DBA signoff before code migrates.
Harvest is by no means a tool for most software organizations - it is typically used in the finance industry, or in business' where a very strong regulatory framework governs what they can do. Banks need to comply with Sarbannes-Oxley, which has very strong auditing requirements. Harvest provides the ability to define all kinds of controls and process around how changes to the Banks assets move through their lifecycle. I know large public transport organizations that are responsible for the safety and punctuality of millions of people every day, that need the tightly defined control mechanisms that a tool like Harvest provides. I also have seen Harvest used in environments where 1000's of developers use it everyday - yes, I'm not exaggerating, literally 1000's of devs in one organization, writing code for a worldwide retailer, pushing IT solutions out their door everyday to the stores around the world.
Harvest is not perfect, thought version 12 is much better. It has too many "that's just stupid"-moments, it does per-file versioning ala CVS, and CVS-like branching and directory versioning (or lack thereof), with all the fun we've come to know and fear. Once you know it and accept it though, its isn't inherently slower than any other SCM I've used. It just has a bigger job to do than just version your code.
Another big win, and its even bigger with version 12, is its integration with other CA tool (and ability to integrate with non-CA tools, but not many at the moment) - defect tracking with Quality Centre, trouble ticketing with Unicentre Service Desk, software deployment to the desktop with SDM. You can define bridges between these apps that result in a lot tighter integration of these concerns, with the usually positive effects on accuracy and timeliness.
If your dealing with getting software out to a worldwide enterprise, with thousands of desktops and servers, mainfame/midrange/middleware systems, iron-clad change control processes, complexity, regulations, contracts, auditors, just a whole bunch of complexity, Harvest is just one tool in a whole suite of tools your going to need. If you just want a simple SCM for a team of 10 devs supporting a few hundred customers, its not a great way to go.
I'll try to add something about how Harvest actually works next time - repositories, projects, views, packages, forms, processes etc. That might help explain why some organizations use it, and why its not for everyone.
I used Harvest during a short gig in the banking industry a few years ago. I agree that it was practically unusable, but the people in charge of QA seemed to love it.
I worked for a company that had two choices; ClearCase or Harvest. Subversion hadn't ever been considered, and the reason was that ClearCase (IBM) and Harvest (CA) both had longstanding mainframe contracts already.
We've used Harvest for about ten years (2000-2010) and even though we are now looking at replacing it I believe it has served us very well.
Harvest (let's stick with that name even though it's no longer it's official name), was the first major tool we implemented to support us in R&D and at the time none uf us knew much about the many aspects of application lifecycle (versioning of code, branching, automated testing, regression testing, quality assurance, deployment to numerous runtime environments and production, rollback, ememrgency fixes, maintenance updates etc.); today we know a lot more and our development processes serve us very well (not that there is not room for many improvements).
We do not have a very hierarchical organisation (we don't have a lot of inspectors that need to approve changes) but it's very helpful to have support for "checkpoints" - points in the development process where something need to happen (e.g. functional testing or integration testing).
The drawback (for us) with Harvest in regards to usability has been "what a programmer need to do to change x lines of code". Today (out there) there are a lot of easier and more efficient ways than Harvest to get write access to source code files, make your updates and then return the files again / move them to another aspect of the development process (testing,deployment etc.). Another drawback is the price tag; it's expensive.
Gain we've had with Harvest:
It support workflow and therefore we've been able to have a single system to manage code versioning, workflow and process automation. If possible it's easier to maintain and improve a single system than many.
In addition to providing cmd line access to internal processes (making it possible to script special solutions when so required by your processes) Harvest also is easily configured by graphic interface.
It has the concept of "Package" which makes it easy to attach plenty of meta data to code changes and to handle the changes independently of other changes (versioning on file level rather than change sets containing the complete code mass). This is helpful to handle indpendent emergency and maintenance changes.
If a developer is only a programmer and only think on the coding aspect of software development then I imagen he/she would might get very frustrated with Harvest.
If a developer is a developer and understand that software development is a lot more than coding and that the coding is only the very begining of a the lifecycle of software then I belive he would see a lot of benefits with Harvest.
I have been using HARVEST for the last 4 years and i love it. The kind of support it gives you to control the code movement is really fantastic. We use HARVEST to deploy applications on to Websphere. It also do an amazing work in deploying the plugins into the web server along with the application. When you want to have a process in place for moving the code in a big enterprise environment, i don't think any other tool can even come closer to HARVEST.