“The 3rd Annual ‘State of Agile Development’ survey was conducted and sponsored by VersionOne. This global survey ran in June and July of 2008 and received 2,319 completed surveys with 3,061 total respondents from 80 countries.“
http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf
All the performance and capacity planning resources for SharePoint 2007 you’ll ever need:
http://technet.microsoft.com/en-us/office/sharepointserver/bb736741.aspx
It’s great that people are starting to realize that trying to accurately define and detail all requirements up front is inefficient and causes more harm than good. However, I’ve come across a fair share of individuals in the past who simply cannot imagine why writing a detailed functional or technical specification in the beginning of a project is bad. “But we need the functional spec so that we know what we’re building,” they say. “How will we be able to accurately measure progress? How can we build a project plan without all the requirements? There is NO room for scope change in this project – we need to get all the requirements now so that the customer can’t change their mind.”
Welcome to Agile, I say.
In the sensible world of Agile, we have learned from and corrected our mistakes. We no longer attempt to predict up front how a system will function or what will be in it, and we don’t put the customer in a position to speculate about everything they might ever need. We now realize that, no matter what we do to try to prevent it, the requirements of a software project will always change. We view this as a good thing. We embrace change and adapt constantly, thereby delivering what the customer really wants and not what they thought they wanted. This makes customers happy.
With Agile, we are able to release working software quickly and often. We are therefore able to deliver business value early and on a regular basis, which means a lot to many customers; they can see what they are paying for. Working software is the only true measure of progress in an Agile project. We have learned that progress cannot be accurately measured by intangible artifacts such as documentation, progress status reports, timesheets etc.
In Agile, we build the system with flexibility in mind. We know that the design will probably change, that already-developed components may be rearchitected, and that new features can be expected. We build a design that will last forever. Because we do not speculate requirements in the beginning of a project, and because we no longer do a Big Design Up Front, we are not bound to technical decisions made early on with inaccurate information: our design is adaptable.
In Agile, our project managers are happy. They can better predict, and they have more control. Progress measurement in an Agile project is accurate and realistic, allowing management to make better informed decisions about resourcing, budgeting, scheduling, etc. Because Agile methods give us more control over the software process, there is less uncertainty, and project stakeholders have less to worry about.
Agile helps us find and fix bugs faster. We do not allow errors to accumulate; they are tested and fixed without delay, which saves cost.
The Agile approach values planning. One would agree that planning is absolutely essential to the success of any software project – Agile embraces this idea by planning constantly, throughout the process. An Agile project requires more planning than other up-front development models such as Waterfall, and this ensures a better end result.
In summary, we realize that by going Agile, projects cost less to build, deliver more value to the customer and quicker, are easier to manage and control, are of higher quality, and are designed in such a way that allow future requirements to be delivered with less overhead.
“Asked for the chief reasons project success rates have improved, Standish Chairman Jim Johnson says, “The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.”
The Standish Group has studied over 40,000 projects in 10 years to reach the findings.”
“Plan to throw one away. You will do that, anyway. Your only choice is whether to try to sell the throwaway to customers.” - Frederick P. Brooks
I found some great quotes on the topic of Waterfall software development in this interesting article…
“As IT professionals we need to start pushing back when the business asks us to do fixed-price development. The ethical approach is to educate them in the options they have available to them, to the trade-offs involved, then give them a choice. Regardless of the choice as professionals we need to respect the decisions of our stakeholders even if they still choose to go with fixed-price. However, my experience is that when stakeholders understand that they have choices, and the implications of those choices, then they often choose to abandon fixed-price approaches. Many people claim that it isn’t possible for their organizations to work this way, but I’ve been successful in turning business people away from fixed price even when I was told it couldn’t be done. This is a battle worth fighting.“
Well, the short answer is no.
A colleague of mine recently ran some tests to see whether one could successfully host SharePoint 2007 on Windows Server 2008 Core Edition. Here’s what he said:
“I have done some research lately on the different configurations for MOSS on Windows 2008 and was very interested to see if MOSS can be run on Windows 2008 Core edition.
Now for those who don’t know what Windows 2008 Core edition is, it is an installation that contains the core components of Windows 2008 with no GUI. So, it is command line driven. The reasoning for wanting to use this is that, without all the extra fluffiness of Windows 2008 GUI, the operating system delivers its platform applications at a much higher speed.
But ALAS after some research it’s shown that MOSS 2007 is not supported on Windows 2008 Server Core Edition.“
SharePoint 2007 is supported on the following Windows 2008 Servers:
Couldn’t have said it better myself 
“…the iterative development process reflects what most of us actually experience as the reality of software development, that requirements cannot be frozen and new requirements are frequently discovered once programming is under way. Instead of trying to impose artificial deadlines and milestones on a project, as is common in traditional models of software development, the team can tailor the development process to conform to the situation as it actually exists, and therefore increase the chances for success.“
In a large farm topology of SharePoint 2003, your setup will be as follows:
In search the job / indexing server does the crawling and once the index is built it is propagated (copied) to the search servers. The users access the search servers when they perform a search which allows the indexing server to work without interruption.
In my experience the propagation of these indexes fail from time to time and when this occurs the following errors will be written to the event log:
“Description:
Index propagation to search server <MyServer (IP 0.0.0.0)> was not accepted.
Context: http://myservername Application, MyCatalogue Catalog
Details:
The content index server cannot update or access its database because sessions are unavailable. Increase the system resource usage setting for the search service. If the problem persists, stop and restart the search service. (0×80041184)”
“Description:
The content index cannot be loaded.
Context: http://myservername Application, MyCatalogue Catalog
Details:
(0×80041184 – The content index server cannot update or access its database because sessions are unavailable. Increase the system resource usage setting for the search service. If the problem persists, stop and restart the search service. )”
“Description:
The property store was not initialized.
Context: http://myservernameApplication, MyCatalogue Catalog
Details:
The content index server cannot update or access its database because sessions are unavailable. Increase the system resource usage setting for the search service. If the problem persists, stop and restart the search service. (0×80041184)”
“Description:
Index propagation to search server <MyServer (IP 0.0.0.0)> was stopped. The server is reverting back to using the previous index.
Context: http://myservername Application, MyCatalogue Catalog”
If this occurs your users will not be able to search at all. You have a couple of options to resolve the problem. Here are three options:
Option 1 (Easy):
Forcing the propogation should solve the problem for now. If this does not work, try option 2 below:
Option 2 (Easy):
Restarting the service is the quick fix, but in the past clients have noted that this is a temporary fix as they need to do this constantly. The next option has, in my experience, solved the problem:
Option 3 (Trickier):
The steps above have effectively removed the server, SearchServ1, from the topology, but not the farm.
The steps above have now removed SearchServ1 from the topology.
While SearchServ1 is restarting complete the above mentioned steps for SearchServ2. This will effectively mean that your topology will only have 2 x web front-ends and 1 x job / indexing server in it.
When SearchServ1 is rebooted, complete the following steps to add it back to the farm and into the topology:
While readding SearchServ1 to the farm and search topologies, SearchServ2 has successfully restarted. Now complete the above mentioned steps on SearchServ2.
In summary the following steps have been completed on SearchServ1 and SearchServ2
Now that the search servers have been “refreshed” you can reinitialise the propagation by either forcing it or waiting for it to happen after the next index. In certain instances it is also a good idea to switch the server’s content index resource usage to dedicated. This will limit the timeouts and should limit the occurrences of the propagation failure. To update the content index resource usage, simply click on the server name from within the “Manage Search Settings” page.
The above mentioned steps have worked in my experience, how have you been able to “tame the beast” that is SharePoint 2003 Search?
