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 5 years ago.
Improve this question
Right now, our teams are using a combination of a bulletin board and an excel spreadsheet to keep track of tasks and to draw a burndown chart. Backlogs are keep on index cards in envelopes.
This works well when the stakeholders are in the same location. However, we will soon have Scrum teams in two geographically distant locations and I am looking for best practices on how we can leverage Sharepoint to help us communicate around Scrum artifacts (backlog, burndown chart, velocity, etc.).
How did you leverage Sharepoint for that purpose, what are the best practices and the potential pitfalls?
We actually use Sharepoint for our Agile development and have found it works pretty well for project management/collaboration.
There are 2 things we do which I found particularly useful, metrics tracking and automated testing. We use the document library and infopath to add all of our stories for the project to the site. The infopath form should contain all the information you need for a story: points, estimated time, developer, tester, story tasks, test cases.
For metrics, we create web parts for: burn down charts, velocity, points per iteration, etc.
This is especially nice for Managers or customers to see that progress being made on the project and will help them make decisions regarding features vs. release time.
For testing we have a simple SEND-RECV-ASSERT language which runs the tests nightly by scraping the XML for automated tests. The we have a little Green/Red webpart on the main page which tells you the stat of the tests.
This can be done pretty simply with some XML parsing since the backend of the document library is XML. (We currently use some simple ActiveX and javascript)
The metrics are pretty easy to set up (just some xml parsing and html charting). The automated testing takes some time to set up a test runner, but once its in place, and easy enough, you can even have customers/managers write acceptance tests! Agile! :)
If you have SharePoint in house already,along with a user base that is comfortable using it I think it would be fairly easy to get started with using it for SCRUM. I would start with the following:
A site collection to hold 1 scrum site per project
A scrum site should contain:
Document library for the electronic files (add columns for categorization as appropriate)
List of team members
Discussion board
The site can be built from a Wiki site template if its necessary.
Once you get the scrum site "feeling right" save it as a template so its easy to spin up a new one.
This solution may not be designed for SCRUM to the nth degree, but it should be enough to get you started. It seems a lot easier than having the entire team learn a new tool when it sounds like you are undergoing some other pretty radical changes.
my $0.02
jt
You really should consider something like Trello, VersionOne, Rally, or even Basecamp for this. They all have hosted solutions and offer free community versions that you can try out to get started. My experience with SharePoint is that it takes a lot of resources to maintain. If you were using Team System and had a lot of the stuff pre-built for you, that might be different -- although I have Team System and still choose to use a Wiki for my project management tasks. If you already have an investment in SharePoint as an intranet and all of the support staff, then it might be a viable solution in that case, too.
SharePoint is not the tool I would think of first for agile development. YMMV.
You need to try and keep the tool from getting in the way of working. In an ideal world the team will all be sat in a single room with big white boards, however often this is not the case and teams are distributed, or theres a push for some form of backup for the post-its.
I'm a big SharePoint fan and where you have this in house already, your already doing collaboration and team work on the platform. Adding another tool, with unique login's can work but the team need to really want to use them.
I've tried getting SharePoint out of the box to do what I wanted but it fell short. I've tried using Version One (on a number of occasions over many years, with many teams) but I find the tool is too much, there are too many otpions and things that need to be done that it gets in the way - it is a long way from the Whiteboard.
So I decided to develop what I needed for my projects. I needed a simple tool, and using the 37signals (creators of basecamp) approach I needed something with less features than the competition.
21Scrum is a simple scrum tool built on SharePoint that uses the platform, add the things that you need (white board, burndown charts) and leave you to get on with the project.
Perhaps this may be the best option for people who already have and use SharePoint - at least thats the goal.
We've setup a SharePoint workspace with lists for Release/Sprint planning, Product Backlog and Sprint Backlog.
Central element is this Task Board for SharePoint - we can drag & drop stories and tasks - even if we are not at the same location.
http://www.youtube.com/watch?v=XW89M0C3N7Q
A burndown report visualises the progress automatically.
Works great!
AFAIK, Sharepoint is ASP.net with free goodies. It is not designed for agile project management.. so you'd have to roll your own site.
IMHO instead of trying to bend the job to the tool you have.. switching to a better tool for the job would be a better option. Check this thread out to see if there is something more lightweight that fits your bill.
Also personally I'm a big fan of not digitizing the development activities.. So I'd use a spreadsheet for the backlog and post its and Big Visible charts. Use a digicam to persist diagram/design discussion snapshots (google whiteboard photo for tools) or for reports. I find that most of the "project management" tools are just excuses for generating instant status updates.. it gets in the way of software development (which is the main goal) and inhibits social interaction way too often.
(disclaimer: absolutely 0 experience with sharepoint.. except what I've read in the last 2 days so may be totally off track)
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I'm looking for the "best" agile-friendly feature and defect tracking software. Currently, we are using fogbugz, but this is not terribly useful for teams following an agile methodology as far as I can tell. There are better tools for this, such as Greenhopper for JIRA. I've used JIRA before, but I'm wondering if there are any other tools that are better.
I'll relate my experience, hoping it will be helpful.
We started piloting Scrum using cards on a wall. We figured we would switch to a tool once we started doing it for real. We set up our defect tracker (Redmine) with User Story and Tasks, and have a way to create a burndown in each project. What we found, however, is that you don't really get the transparency of a physical information radiator. People walk by the card wall and can see the team progress. Very few will check the web site as often as they inspect the card wall. So currently, we do the card wall for the current Sprint and track the Sprint in Redmine, which gives us historical information.
As we scaled up to more teams than we have wall space for, we realized we're going to need a tool that can work like a card wall and be a 'real' agile tracker. So we looked at several tools, and our short list included Version One, Rally, and Mingle. Either of these products might be best for you, but ultimately we chose Mingle for various reasons.
The one thing I worry about is the loss of the card walls. It's hard to explain the transformative value that these public information radiators have had. The teams get lots of visibility from the Product Owners as well as management and other stakeholders. I worry that the visibility will be lost if we switch to using solely the tool. I may have to build dashboards that go up on wall-mounted monitors, acting as a high-tech version of the card walls. One thing we did do was procure some touchscreen whiteboards that will allow teams in standups to move virtual cards in a familiar way, using the tool's drag-and-drop card wall interface. I'm hoping this will allow us to retain the team communication and interaction benefits we've seen when gathered around a card wall.
Anyway, good luck with your quest!
We are using PivotalTracker (http://pivotaltracker.com) in our projects. It is a lightweight and easy to use tool. It works in the cloud, so creating an account and setting up a project is a matter of minutes. User story and bug entering is quite easy. The tool supports a standard workflow of tasks consisting of Not Started, Started, Finished, Delivered, Accepted and Rejected states.
I haven't tried fogbugz yet but I used JIRA, Greenhopper and VersionOne before PivotalTracker. The downside of all these tools against PivotalTracker is that using them brings you too much overhead. You have to setup and maintain them. You have to configure them. And because they are harder to use, they require more time for daily usage. I have seen that developers hesitate to use these tools because they create too much friction. IMO PivotalTracker is the best tool in this respect.
The downside of PivotalTracker is that it gives only a few configuration options. It doesn't allow you to customize workflows. It doesn't have much user authorization options. But in our case it suits very good to our needs.
This might be a non-answer to some extent, but I hope it will still be informative and add value.
I've been on multiple teams using various tools including physical boards and Greenhopper. Other agile teams in my department have used and evaluated various other options. If you are talking about finding the most efficient way to manage the team within a sprint (as opposed to release planning, backlog grooming, etc) I've come to the following conclusion:
Nothing is going to be a great fit unless you wrote the tool yourself or use a speadsheet. Yes, a spreadsheet. It's the most flexible option I've come across. We use a fancy one with burndown charts and such, but it works great.
Any tool you find now which may be a perfect fit will eventually end up not doing something you want. Here is an example from my own recent experience:
We were working to bring down the length of time it takes to report status during out daily scrum meeting. The challenge was that developers have a tendency to go into a detailed explanation of issues they've encountered while working on a task. We try to postpone those discussions until after the scrum meeting. It was hard to do until we started simply highlighting any items in the spreadsheet we need to discuss further. This let us move on with the meeting but not lose track of issues that need to be discussed. It was effortless to introduce this into our process precisely because we were using a flexible tool like a spreadsheet. The tool didn't stand in the way of improving our process.
As for defect tacking, most of the teams in my department use JIRA.
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
What is your experience from real-life, who should be responsible for a choice of agile planning tools to be used by the agile/scrum team?
Team should decide whether a tool is to be used; but I think suggestion most commonly comes from the Scrum Master as (s)he is most likely to have experience using tools. Any team member can suggest tools of course.
Anyway, my feeling is that given Scrum philosophy, the whole team needs to agree on this in my opinion. Usually things start with "let's try this, see if it works", and is refined along the way, just like anything else in Scrum. It should not be top-down enforcement, same way as using Scrum methodology should be team decision, not handed down from top.
Great question. There is a lot of value to embracing the self organization of agile and allow the teams to choose their tools. However, there are usually constraints imposed by the business. For instance, the business may not be able to support/want each scrum team rolling its own scm solution. The more established the business, the more constraints and push back. Even established businesses can change. Don't be afraid to question a constraint if the team can justify the change.
Agile planning tools will follow these same rules. The business may have a full software life cycle management solution in place. This solution may or may not have an agile module. However the business may have reasons (regulated industries for example) to require that design inputs / outputs are documented in the life cycle management software solution they have. The business usually needs to balance keeping the teams happy / productive with staying in business.
I don't think there will be a black or white solution (unless you are one of the first devs at a start up). Agile teams will need to embrace the open communication. If the tools are impediments the business needs to know.
I'm going to make simple answer, because I actually think this is a simple question.
The WHOLE team is responsible of that.
Let me explain a little bit.
We first have to accept that every context is different, so this is not a biblical answer.
Let's say you start your project. I always love starting my projects/products with nothing.
NOTHING. Sometimes, just a task board, with todo, in process, done.
That's it. And I fill the todo column.
And that's all my point: I build my agile process incrementally and iteratively.
Why should I have to create a Burndown Chart? Because literacy tells me so?
Hell no, because, maybe, eventually, at some point, I might need to have some visibility for my planning.
Same with everything. And never forget, Agile tools serve as a support for the process.
So, you're a PO, and you're tired of the simple todo list, and fell the need to do a Backlog?
2 Solutions:
-- you're already in a highly mature team, you just have to tell everybody during stand up meeting that you're taking the lead on it. Eventually it'll need a retrospective to accept that.
-- you're migrating from a V, W or whatever product management model. Then, wait the retrospective and ask everybody and explain your pain. Give solution (here the backlog), and ask for a shot.
So, you're a scrum master, and you find a "systemic bug" in your process, let's take the classic one: Too many bugs. Then take the lead to promote TDD, or systematic testing.
So, you're tech lead and feel... Well, you understood me.
My point is: never over tool your process at the beginning. Build the process slowly, add tools slowly, when you need them. And by doing so, don't worry, people will take reponsability to create the tool and add it to the process, to lobby it to the rest of the team.
Hope this helps.
What is your experience from real-life, who should be responsible for a choice of agile planning tools to be used by the agile/scrum team?
Well my experience from real life is that, certain "Agile Planning Tools" tools were handed to the Scrum Teams before they even started their Sprints, fortunately the Teams liked it, but we were free to inspect and adapt to using something else if it did not work out for us.
I think it should be in the Teams power to use, accept or reject a tool in a completely transparent way. They could very well take suggestions from the Scrum Master or an Agile Coach because (s)he may have more knowledge in the Agile Tools area. Secondly, the Team should be courageous enough to have a collective discussion and decide on using a tool based on the Agile Coach's suggestions, and see how it works for them, and adapt and adjust from using it if it does not work for them (productivity-wise)
The bigger question which you did not ask is, how do you manage the differing tool set chaos when the company scales into having multiple Scrum Teams who use their own Agile Planning tools?.
Well, I think realistically, in a scaling agile software company, a little bit of uniformity in tool usage across Scrum Teams can be beneficial and productive but that may be directed by the self organised enterprise project Team instead of each Team having their own tools. Off course there can be exceptions, where certain teams are working on completely different features and they need a totally different tool set, but the benefit of using common Agile tools will help scaling projects view their Teams progress without much of change in gear.
The above can be done by having a Technical, Infrastructure and Process Tools Story which not many companies use or create. This EPIC story can be the starting point for discussion of what Agile tools and other tools can be used, to have a little uniformity within the project. While deriving the EPIC story the whole project team could be involved around project kick off, if it is too big then 1 - 2 members can represent each of the Teams. The story could be broken down exactly like business user stories, and modified accordingly and calibrated, estimated and prioritized through out the project from an infrastructure and tools stand point. Let me know if you want me to go in more detail about this.
Ideally the scrum master, but they may inherit some legacy which needs some evolution.
If the organisation is new to Scrum, then an experienced Scrum Master should be able to advise the best tools for the maturity of the team.
Typically, if a team already has some tools, a scrum master can adapt what is already there, regardless of the organisational choice. Some of the best boards are on Excel Spreadsheets and work just as well as a purpose built system. Every technology creates 'constraint'. So, it is up to the scrum master to support the business in ensuring the tools are fit for purpose and delivering the value the team needs.
Typical mistake I experienced as a coach was decision made by managers or even senior management according some study done by 'specialist' or even external consultant. Those people are many times not aware about what, how and who will yse the tool. In this case I see dissapointed people once they should use chosen tool.
You have to consider who is going to use the tool for most of the day. Team members are better target community. Tool must support ScrumMaster role due to daily work she needs to done. Include experienced product owners into selection of the tool as tools have different support for planning that is necessary to be usable.
Consider your organization (complexity of products, projects, number of locations)
The responsibility (and authority) of choosing a planning tool should be with the team. Often the surrounding organization will have a stake in terms of licensing costs and consistency across teams. Depending on how autonomous your teams are it should be OK for them to chose their own tool, though.
Within the team, the product owner usually has the highest stake in the decision, since he will be the one who is going to use it the most for continuous refinement and prioritizing. The rest of the team often only interacts with the planning tool during refinement and planning sessions once or twice each sprint. So he is usually the one driving the decision-making, but should definitely involve the team.
If the chosen tool also includes a board that the team uses daily to track their work, they will want to have more of a say in the choice.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
We have been looking to implement Agile methodology within our geographically distributed development team, so i need suggestions on any free on-line application that you have used and find useful.
Right now we are using paper cards and wall to manage this :), but we want to shift to an on-line version preferably free.
I have used TargetProcess at my previous job!
My Core requirements are:
Business Analyst can add user stories
We can assign, prioritize different user stories to developers.
QA team can add test cases around different user stories.
Project Manager can track the time of all the resources and can pull reports for upper management
I've been using Pivotal Tracker which is a free agile project management tool and covers the following agile concepts:
Velocity tracking and emergent iterations
Story-based iterative planning
Real-time collaboration
Would certainly recommend you try this before paying for an alternative.
Also, as mentioned, Basecamp is a great tool for maintaining documentation, to-do lists and the rest. There is a barely promoted free option for single project use that you will find on the signup page below the Max and Premium options.
Possibly not an agile tool as such (depends on your definition) but the free Team City continuous integration and build server is the kind of software that you don't believe you could live without once you've used it. Basically a commit to SVN by any developer triggers a build to your staging server about 30 seconds later meaning the latest build is very agile!
Timetracking: slimtimer.com.
This is one of the best time trackers I've seen (and I've seen many)
Mercurial code hosting: list available here.
I've only used the service provided by sourceforge.net and was satisfied with it.
Web conferencing, desktop and whiteboard sharing: Dimdim.
I haven't had much luck with it, but I believe it might perform much better on a Windows machine.
All sorts of version control, wiki, RSS feeds: sourceforge.net.
It's only for FOSS projects, though, but it really ofers a lot of services.
Other than that, basecamp should fit right in an agile process (although I haven't used it much) with a reasonable price ($50/month...)
Try using http://www.icescrum.org/en/. This is open source tool and free platform for Agile developments. You can read its feature on Features tab on website.
Also, Visit http://www.openlogic.com/wazi/bid/188152/Comparing-Open-Source-Agile-Project-Management-Tools. This article compares the most compelling open source options.
At work we use a product called Skinnyboard. It has a ton of great features, like:
Support for Sprints and Product Backlogs
Sprint tracking via stories/tasks
Individual task history
Sprint/Product Backlog burndown, to see projected finish dates, etc.
It's free to try, which gives you (I believe) one board. After that you have to pay though, but it's a great product and definitely worth it.
It's simple, visually appealing, and only has what you need. In my opinion, it's like the Basecamp of SCRUM tools.
They say it better than I ever could,
AgileFant is an open source tool
for managing agile software
development activities, such as:
projects, products, releases,
iterations and backlogs. It brings
together the perspectives of long-term
product and release planning and
project portfolio management.
Another one that's recently sparked some interest and seems potentially useful (I'm in beta, easy to get in afaik) is Flowdock which is basically a mish-mash of email alerts, RSS feeds, ticketing systems and plain ol' realtime chat with status messages et al. Think of it as Google Wave that doesn't suck and check out the intro video from the front page.
Try out Flying Donut. It is a new online product inspired by scrum. You may host public or private projects.
Disclaimer: I have been using it for many months, since I helped building it, and I love it.
My company is in need of a task management system to handle scenarios as simple as "Purchase a computer for X" to "Relocate a person to another country". The simple scenarios are a single tasks handled by a single person, whereas bigger tasks can be broken down into multiple sub tasks delegated to multiple people during the workflow. Additionally the clients and vendors need their own views into the process.
We are evaluating different solutions from a custom application built on Workflow Foundation to SharePoint to BPM products like Metastorm and BPM.Net.
Here's my current understanding of these solutions:
Workflow Foundation - Low level workflow designer and/or library with no host environment. It seems we would have to reinvent some wheels if we went this route such as fault tolerance and document management. Some of the answers on stack also cause concerns such as the lack of versioning and a complete overhaul for VS10/.NET 4.0
SharePoint - Built for document management and collaboration but trying to create advanced workflows and tasking on top of that seems like a hack. Plus all workflows have to be tied to either documents or lists. I cant envision how a list (or list of lists) can address this issue.
BPM products - Mature workflow engine at a seemingly high price. BPM.Net is the only solution for which I could find some level of technical detail but im still not sure how different developing against this product would be from developing against Workflow Foundation.
Are there any workflow engines dedicated to solving all the workflow pains that can be easily deployed with their own hosting environment and initiated through a webservice?
Are there any other options I am missing?
Thanks in advance.
****Edit**
To answer the questions below the workflow needs are pretty light. Basic routing of tasks to approvers and subcontractors.
Whats driving us too look deeper than PM software is the nature of the business not the need for advanced workflow. We are basically in the business of procuring goods and services through subcontractors for our clients which can also include full employee relocation. The interface of the package should reflect this by being customer branded as well as intuitive for this line of business.
Basically if im moving my family to the other side of the world Im not sure i'd want to interface with Jira or Sharepoint or any other PM software to facilitate this.
If you are on Microsoft stack I would definitely recommend SharePoint for this scenario. As it seems to be very simple you can go with Windows SharePoint Services edition because it is free and it has everything you need.
You are right when you say that ShartePoint workflow are bit limited. IMHO the best way to overcome that limitation is to purchase Nintex workflow to create your workflows. It is cost effective solution that can help you design workflows you need.
You can find workflow samples inside the product (as workflow templates) and on the web site.
Nothing you mentioned has much to do with workflow. You're just doing project management. If that's the case, a simple bug tracker (like FogBugz! ;) would work - but if you're going to show it externally, it may not be the most professional presentation.
The closest off the shelf solution I can think of would be Project Server - though, depending on the number of projects and project managers, the desktop Project with a sync to a webserver for client views may be enough.
If that's overkill - because your projects don't require a lot of resource scheduling, Gantt charts, or other PM artifacts - you can take something like Trac and replace "bug" with "task". ;) (Seriously though, that'd probably get you 90% of the way there.....)
Have you looked at RT? I believe it can handle all your requirements, including that it's designed to let customers interact with the system by email, rather than having to log into the website. If you've emailed IT support desks then you've probably interacted with it without knowing... You can also completely customise the web interface and allow customer access.
Can't vouch for the quality as I haven't used it, but I did watch an online-demo video of Intalio, which has BPM and workflow capabilities.
We use Basecamp to control this sort of "task management" stuff. I'm not sure if it fits your needs totally, as it's a little light on the document management side, but it has a web service (REST) API, customer / vendor facing components, and basic interaction / chat capabilities.
The best part about it is that the API is simple enough where you can offload a lot of the "management" for it to admin support personnel, like assistants and interns, by providing custom scripts. If you've got people who aren't programmers using it you'll probably have better luck with it than even something like Trac or FogBugz.
I have/am going through a similar process. We wanted a lightweight workflow for internal use by our sales team. Most of the third party apps we looked at ,K2 and Skelta BPM.Net in particular, looked way over the top for what we needed. I'm now 2 months into working with Windows Workflow Foundation 3.0 and I have to say it isn't the most pleasant coding experience I've had.
If your workflows will truely be simple then it is pretty easy to build a workflow and hook it up to some web pages for the UI. But if you need to be able to change it on the fly, or do versioning (ie the user says we want another step added, then its a whole lot of hacking to get it to work - and it only works if you limit your workflow to being really simple), then you are in for a fair bit of work. And forget about it if you use an Oracle database.
The next version of windows workflow will have it's own runtime environment, code name dublin, with will provide a WCF interface into the workflows.
If your timeframe allows you could use that.
For information on Dublin and the next version of WF see:
http://www.microsoft.com/net/dublin.aspx
My vote is for FogBugz. Unless I am missing something in your requirements, why would you want to reinvent the wheel by using a code based workflow solution where you have to code up the flows yourself when you can use a perfectly good project dependency solution like FB or even MS Project Server - which lets you create nice dependencies for resources and people.
Check FileNet
FileNet is expensive but makes a good job with content and process management, but I guess is not what you are looking for.
We use Captaris Workflow, it is pretty good but it may be expensive for your needs.
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 9 years ago.
Improve this question
Have any of you ever tried to run from sharepoint? I've worked with sharepoint enough to know that it is not something that interests me. My interests are more along the lines of APIs / backend / distributed development. Have any of you found ways, as consultants, to move away from sharepoint and keep learning other things of interest? I'm currently in a position where sharepoint is in huge demand and I can't quite find a way to simply step aside from it. any suggestions ?
If I infer correctly that you work for a consulting firm then find out what other kinds of things your firm works on. Learn those technologies better that the people who currently work on them for your firm, involve yourself in those projects, even if just in a hallway conversation manner, and come up with better (faster, cheaper) solutions for the problems your firm is solving.
Your options are really seem to be 3-fold
convince your boss your talents
would be better used elsewhere
convince your co-workers they want
you on those other teams
convince your company's clients that
they want you, specifically.
Learn Java, or Ruby.
The Microsoft sales model of "attach" whereby they sell a solution comprised of multiple technologies and then sell the next solution on the basis of "well you have already invested in SharePoint so you already have the skills in place and the infrastructure for this new bit of technology we have" is here to stay... it's very successful.
SharePoint is cloud computing for business who have MS shops... you avoid it by not doing C#. If you're doing C# then given enough time, your apps will need to run in the corporate cloud and you should be looking after your career by embracing it.
Just my 2p. Sorry if it's not quite the answer you wanted.
I know exactly what you mean. I think you don't mind the idea behind a product like SharePoint, but really hate the way its been implemented and how problematic it is. I know its a nightmare to work with.
As a C# developer, I cringe when I hear the SharePoint word, SharePoint is Lord Voldemort. But unfortunately it comes with the job of being a senior C# / Microsoft developer.
I say unfortunately because its likely if you're working in a corporate structure sooner or later you will end up having SharePoint in your solution. Not because its good, but because as others have said - MS use SharePoint as a Trojan horse to get and keep business.
There might be some hope with the new version of SharePoint coming out (2010). Maybe this will finally include a better programming / implementation model.
Otherwise either work for smaller companies (usually less pay, but not always), or try to play down your skills as a MOSS developer if possible. Never actively market them unless your salary depends on it. Remove the skill from your skill matrix, and turn down jobs that completely focus on MOSS. Some MOSS integration here and there you can live with. An entire solution focused on MOSS will drive you insane.
If all else fails, learn other non Microsoft languages, and within a year or 2, SharePoint will be but a faded memory.
I know lots of developers who are thinking about quitting IT because of SharePoint. I would say don't let it be the end of your career.
And finally bitch and moan, and inform managers on a weekly / daily basis, as to why you are battling in SharePoint. Let them know, and constantly remind them how bad a technology it is.
When life deals you lemons. Make Lemonade.
Seriously, if you are seeing SharePoint in such high demand, maybe working with the beast is the best idea. SharePoint is really just middle-ware. SharePoint can simply be a distribution point for your solutions (i.e., a user interface such as a web application can be hosted on SharePoint through a Web Content part). If you look at it, SharePoint may even prove useful as a document respository or small scale data store, in the form of lists.
Maybe you should turn down SharePoint contracts and accept contracts that interest you.
Depending on the market you are in you can simply tell your boss at the consulting company you work for that your not interested in doing Sharepoint projects anymore and that you'll be forced to look elsewhere if they continue putting you on Sharepoint projects. That would work around West Michigan where the developer demand is high and the supply is sub-par.
I'm, on the other hand, just starting to use SharePoint to enreach my currently boring C#-only projects. I'm starting to use it as a front-end to the distributed and complicated systems: simple configuration and customization, reporting, management, system control - looks like all this is available in this package it it's easy to make is usable by non-techies and by beginners.
I personally don't want to work with SharePoint anymore. I've worked on developing a solution for it and even went full charge with a web integration of it. I hated it.
First you have to master the awful programming model then handle all the deployments and it's not even the beginning. If you are developing a product for SharePoint, you have to debug the software itself which is a feat on it's own.
My solution to this is to be very upfront about it. I don't mind doing knowledge transfer and helping out people but I don't want to be developing/deploying SharePoint applications.
My boss get it, my friends get it.
Our latest joke come from someone who said a few months ago that it was "easy and fast to deploy application with SharePoint". The joke? "Did he just put easy/fast in the same sentence as SharePoint?"
So unless you salary would be lower because of it... downplay your skills on it and be upfront to your boss. :)
Have you ever looked at Alfresco (http://alfresco.com)?
It serves many of the same purposes as SharePoint, but does it from an Open Source J2EE application. It will leverage your existing collaboration / content management experience and expose you to a whole bunch of open source technologies.
Full disclosure: I work for Alfresco.
I've already given this suggestion to another guy...Running from SharePoint won't be difficult because technologies are similar to each other according to their structure. SharePoint is not the worst technology to be used, although it is limited in some way... Fortunately, software sphere is too wide to be afraid of not finding anything you can be interested in.