pcplantdb

[Richard Morris <webmaster@pfaf.org>]

I found this linked from slashdot, while its microsoft
I think theres some useful points for us, in terms of the how
do we organise ourselves question.
        Rich

From http://blogs.msdn.com/David_Gristwood/archive/2004/06/24/164849.aspx

21 Rules of Thumb – How Microsoft develops its Software

I will be presenting a session at TechEd in Amsterdam next week on the 
subject of software development – “21 Rules of Thumb – How Microsoft 
develops its Software”. As someone who has been involved with software 
development for over two decades, the whole area of how you actually 
bring together a team and get them to successfully deliver a project on 
time, is one worthy of a lot of attention, if only because it is so hard 
to do. Even before I joined Microsoft, ten years ago, I was interested 
in this topic, having been involved myself in a couple of projects that, 
I shall politely say, were somewhat “less than successful”.



So, just how do you get teams to work together successfully? I’ve 
written a few articles on it, interviewed people at Microsoft about it, 
and witnessed it first hand with teams inside and outside Microsoft. Jim 
McCarthy, who I have met and heard present, whilst at Microsoft, in the 
C++ team, wrote an article entitles “21 Rules of Thumb for Shipping 
Great Software on Time” (which I have enclosed at the end of my blog in 
its original form) and followed it up with a book “Dynamics of Software 
Development”. My session at TechEd is largely based on this article, and 
so if you are inspired by this session, then the best thing you can do 
is buy the book (and no, I don’t get any commission!) and start using 
it. (He also has a newer book “Software for Your Head: Core Protocols 
for Creating and Maintaining Shared Vision” which you may want to look 
at as well)



The other topic I cover in my session is the Microsoft Solutions 
Framework (MSF). If Jim’s contribution is the anecdotes and rules of 
thumb, then this is the more formal documentation from Microsoft. MSF 
has been an ongoing initiative within Microsoft since 1994 to document 
the best practices that the Microsoft product groups, customers and 
partners, have used in the software development process. I was one of 
the first MSF trainers in the UK back then, and have delivered MSF 
training courses and seminars to customers many times over the years.



All the information you need on MSF can be found at 
http://www.microsoft.com/msf , including an MSF 3.0 overview white 
paper, and details of the team and process model, which are at the core 
of MSF. There is also an update on how Visual Studio 2005 Team System, 
which we recently unveiled at TechEd in San Diego, works with MSF.



 Here is Jim's original article:





21 Rules of Thumb for Shipping Great Software on Time



Jim McCarthy, Microsoft Corporation





Shipping great software on time is a difficult but not impossible task. 
Elements you think would count the most count for very little. 
Development methodology, process, technical prowess, excellence of tools 
and depth of project management skills all influence the outcome of a 
software development project; but nothing indicates success as much as 
the manager’s ability to focus on a few critical and conceptually simple 
things. These things can be expressed as rules of thumb.



I enumerate twenty-one of these rules of thumb. Pick a handful (or so), 
apply them, and your project will be more likely to succeed. I lump them 
into three groups: "Shipping," "Great Software," "On Time". Duh. I cover 
them in a different order, because the concepts build a bit.





On Time



1. Don’t know what you don’t know.



It is essential not to profess to know, or seem to know, or accept that 
someone else knows, that which is unknown. Almost without exception, the 
things that end up coming back to haunt you are things you pretended to 
understand but didn’t early on. At virtually every stage of even the 
most successful software projects, there are large numbers of very 
important things that are unknown. It is acceptable, even mandatory, to 
clearly articulate your ignorance, so that no one misunderstands the 
corporate state of unknowingness. If you do not disseminate this "lucid 
ignorance," disaster will surely befall you.



Human nature is such that we dislike not knowing things that are 
important to our well being. Since there is so much we don’t know in a 
software project, the nearly universal tendency among developers and 
their managers is to gloss over or even deny altogether the extent of 
their ignorance. You should reward and treasure those who consistently 
make themselves aware of the list of relevant things that are currently 
unknown. It requires mental and psychological strength to resist the 
normal human cravings for certainty and order. It especially difficult 
to believe in uncertainty when things have a veneer of orderliness, 
which is often the case. Pseudo-order is a maladapted defense against 
uncertainty.



The organization surrounding you will undoubtedly abhor uncertainty, 
would infinitely prefer pseudo-order and will make countless attempts to 
magically convert your ignorance to knowledge. Your job is to make 
uncertainty an unshakable fact, and to coerce the reshaping of the 
surrounding organization to cope with the uncertain situation. The 
organization must learn to thrive in an uncertain environment for its 
own well being.



You should expend a great deal of effort making sure that all the people 
on the project are aware of their ignorance rather than naively 
converting it to falsehoods. Bear down on them until they realize they 
haven’t comprehensively assessed the unknowns. In the successful 
project, this is much easier in the early stages, or during times of 
change. This is no time for niceties. People ultimately prefer success 
even if disillusionment is a prerequisite.







2. Get to a known state and stay there.



The function of QA is to know (and articulate) the quality of the 
product at all times in the development cycle. This should be achieved 
by abbreviated, repeatable tests conducted daily, and full product 
sweeps conducted weekly or biweekly.



It is not properly the job of QA to determine when a product is ready to 
ship; rather, the moment of shipworthiness in a product development 
cycle is evident to everyone involved, and is non controversial. This is 
because shipping has been the goal of the entire effort. Crossing the 
finish line, while it has intangible emotional and definite financial 
rewards, is no surprise when you’ve observed every single painful step 
toward it.



The only reason you’ve been able to make these micro-observations is 
because you got to a known state and stayed there, and your QA is how 
you did it.



Achieving a relatively accurate view into product status is a very 
challenging goal, requiring a highly motivated and competent QA team. It 
is also a pre-requisite for success. Many software development 
organizations have rudimentary or no real QA assets, and there is little 
that can be done for them until they make the appropriate investments in 
creating a modern development organization.



A known state consists of all components having accurate status 
information at a given point in time. You know that it’s accurate 
because the status has been tested by QA.



A developer articulating the status of his/her component is an exercise 
that does produce information, but if it happens to communicate the 
component’s status, it is only coincidental. This is someone else’s job.



Status should consist of a comprehensive listing of tested and missing 
functionality, bug count sorted by severity, bug arrival rate, bug fix 
rate, projected total bug count, and other vital metrics.



3. Remember the triangle.



There are only three things that you are working with as a development 
manager: resources (people and money), features and the schedule. 
Changing one has an impact on at least one other axis, usually two. It 
is a simple enough matter to mentally run through the sides of the 
triangle, or force others to do so, when discussing any part of it. 
Since the people, the product or the schedule is almost always what 
you’re discussing, this means that you must constantly envision the 
triangle. This leads to the most fruitful line of thought.







4. Don’t go dark.



Some features have long development lead times, months or even years. 
Yet slips usually happen a little bit every day, and must be compensated 
for a little every day. This means that the granularity of development 
tasks must be such that deliverables are achieved at intervals 
sufficiently small that slips can be compensated for. A week is a long 
time to go without knowing what is happening. While micromanaging is 
always a danger, and will certainly be an accusation leveled against you 
from time to time, if the goal of the project is to ship great software 
on time, and if everybody accepts that goal as uppermost, they generally 
enjoy the chase. Team interdependency is also a powerful motivational force.







5. Use zero defect (ZD) milestones.



Organize the project around the concept a reaching milestones with zero 
defects. Zero defects does not mean that the product does not have bugs, 
or missing functionality; it means that the product achieves the quality 
level that had been set for that milestone. The product is tested to 
that effect. The essential point of ZD milestones is that nobody makes 
the milestone until everybody does, and nobody leaves it until everybody 
does. This enables the team to discover what aspects of the project are 
in trouble. Load balancing can occur. Awareness of unknowns rises.



At a milestone, the team and its leadership also have the opportunity to 
perceive the whole project status simultaneously, to draw conclusions 
about erroneous practices, to remedy bad design decisions and to 
reorganize for peak performance. Shipping is just the final milestone. 
Though the external organization cares most about shipping, which adds 
special pressure to that milestone, the team develops extraordinary 
focus and introspection about each and every milestone.



6. Beware of a guy in a room.



This is really just a special case of "Don’t go dark." Specialist 
developers who lock themselves away in a room, going dark for long 
stretches, are anathema to shipping great software on time. Without 
regard to their individual brilliance, before investing a developer with 
a significant assignment, it is essential that they understand and agree 
with the type of development program you intend to run. They must be 
capable of performing on a team, making their work visible in modest 
increments and subjecting it to scrutiny as it matures. Some people find 
this intolerable, and though there is a role for people of this 
disposition in the software world, it is not as part of a team devoted 
to shipping great software on time.



There are many pathologies at play here as well as certain healthy 
patterns of creative behavior. One pathology is a type of savior complex 
that cannot be satisfied without blowing every single deadline but the 
last, and then emerging victoriously with a brilliant piece of work five 
minutes late. A more healthy pattern is that of the true innovator who 
is truly designing something great, but who has no personal resources 
left over for anything but the work at hand. Every ounce of 
psychological, emotional and intellectual energy is being consumed in 
the work itself. Teamwork, in this case, is an insignificant factor to a 
person immersed in this sort of creative experience.







But whether or not the cause is healthy or bogus, the results are 
uniformly fatal to the professional development organization. Beware. 
Extricating yourself from this trap is nearly impossible.



7. Never trade a bad date for an equally bad date



Generally, you know you’re going to be late before you know when you’re 
going to be done. Further, everybody on the team and everybody they come 
in contact with knows you’re not going to hit the schedule. The pressure 
to reset the end-date (or the milestone date) is enormous. Even though 
your information is obviously better now than when you originally set 
your goal, it is probably insufficient to make a new schedule. This is 
because with each slip, you and your team are spending your credibility. 
It is essential that after a slip, the next milestone be hit. This is so 
the team believes in their ability to manage the project, and so that 
the reserves of credibility are rebuilt for later consumption.



It is difficult to say precisely and in all cases when you should 
"officially" slip. A good general rule is that the schedule should be 
reset when the total extent of the slip is known for each component, the 
causes of the slip are understood, and remedies are in place. Usually, 
this takes the effort of the entire team and its leadership, and must be 
an explicit, focused activity. After this level of work is achieved, 
create a new, closer and more conservative milestone which the team is 
very likely to hit, and promulgate that. Avoid just sliding the schedule 
out. Your near-in milestone should be extremely realistic, and 
uncertainties about later milestones will remain and should be highlighted.



8. When slipping, don't fall.



Slipping is what happens when information that was unknown becomes less 
unknown. Though slipping is widely perceived to be a "bad" thing, it is 
the symptom of a good thing, as a fever is the sign of the body’s immune 
system at work. Although it is undesirable to have so many unknowns that 
slippage occurs, it is not an unusual situation, and may even be the 
norm. This is because much of contemporary software development is 
essentially experimental, i.e., new platforms, new operating systems, 
new programming technologies often coalesce on new programming projects 
to create a high degree of uncertainty.



In order to avoid calamity, certain measures should be undertaken in 
connection with a slip. Ideally, one or more of the pre-identified 
unknowns caused the slip. It is important that everybody involved 
understand that the risk to the schedule had been known previously. 
Alternatively, it is essential to understand how the unknown/s had come 
to be overlooked. How this gap occurred should become part of the group 
knowledge for future success. Also, determine whether or not people are 
working on the correct things. Often, slips occur because members of the 
team become occupied with features of marginal consequence, or features 
that are not part of the core product message.



If the slip was a surprise, your communications system is broken, and 
dramatic communications efforts are required. Large amounts of detail 
must be brought to the surface for everybody on the team to see. Assess 
the reality of all current near-term estimates. Expose denial. Team 
defensiveness will have to be pushed back for the purposes of group 
learning. Slips reveal your team’s weaknesses, presenting a good 
opportunity for insightful management and mentoring. Make sure that each 
individual who has a role in the slip receives the needed guidance and 
support.



Slips are also an opportunity to re-evaluate the feature content and 
resource loads, generally with an eye toward decreasing the features and 
shoring up weaker areas on the team.



A good slip should be a net positive.



9. Low tech is good.



A smaller effort is almost always more desirable than a larger one. 
Shipping great software on time requires that we value an understood 
solution much higher than one fraught with unknowns. Keep in mind that 
customers would almost always rather see progress than promises.



10. Design time at design time.



The product will ship when the design can be shown to be implemented. 
Developers and their managers often ignore the exigencies of time when 
creating a design. Instead, they should consider the implementation time 
as a critical design element. When evaluating alternative design 
decisions, the one that takes longer to implement is consuming more time 
and should therefore be disadvantaged in comparison to the alternative. 
This must always be weighed. Often, when appropriate design value is 
awarded to timeliness, implementation time can be substantially compressed.



11. If you build it, it will ship.



Conversely, if you don't, it won't. The product should be built every 
day, along with all setup scripts and on-line help, in a public place, 
where QA can conduct appropriate assessment of daily status, and the 
entire team can observe progress or its lack. This is the single biggest 
indicator that a team is functional and a product being developed.







12. Portability is for canoes.



And system software. Even discounting the added development burden, with 
the addition of each additional platform the job of QA increases 
substantially. While clever QA management can minimize the burden 
somewhat, the complexity of multi-platform support is beyond the reach 
of most development organizations. Place your bets. Demand 
multi-platform support from your system software vendor, then build your 
product on the absolute fewest number of platforms possible.







Great Software



13. Enrapture the customers.



Most software is a renewal business. Customers buy multiple releases 
over a relatively long period of time. As a consequence, the market has 
a deep understanding of your software and its flaws, and your 
organization and its flaws. Often, the market has grown uncomfortably 
dependent on software that doesn't meet its needs. In many software 
situations, customers spend hours per/day uncomfortably shoe-horning 
their lives into your product. As a consequence, they crave your 
understanding, and will respond enthusiastically to the least sign of 
it. Normal success, meeting customer expectations, means to improve the 
most outrageous and flagrant violations of their needs from version to 
version. They will likely stay with you if you are faithful about that, 
though they may well be sullen if not mutinous.



Great software, however, requires that you pivot your entire technology 
so that it flows in the direction of their deepest needs. You must 
innovate in ways that clearly affirm their inarticulate desires. 
Surprise them by articulating and resolving in your product concerns and 
fantasies that heretofore had been rumbling about only in their 
pre-conscious. The fantasies of the market are generally centered on 
issues of empowerment, control and security. The market wants to be able 
to do things with its computers that it currently can't. Customers often 
find they can't even publicly admit these needs for fear of computer 
illiteracy. They derive value and security from being able to apply your 
software. To admit that they can't do what they want to do requires a 
sense of security beyond most customers’ reach.



Market understanding is the foundation of great software. To repeatedly 
demonstrate through a series of two or three releases that you genuinely 
understand the market will result in enormous customer loyalty and brand 
equity. You will be viewed as the source of the market's empowerment. 
They will be rapturous.



Gaining this understanding and embodying it in your software requires 
skill, tenacity and creativity. You must recognize the central market 
need and organize all your technology and communications efforts in the 
direction of satisfying that need. While good listening, careful 
observation and concept testing will be required for you to identify the 
correct need, addressing it in your product will have these effects:



1. It will appeal to the customer's sense of security.



2. It will extend the customer's control.



3. It will be such that if all else were dropped from your product, but 
the central need was met in unique ways, the product would be compelling.



4. It will clarify your product messages.



5. It will simplify your product's use.







14. Remember one thing: Unity.



Unity is the master principle of great software. Each element in the 
product is necessary to the value of the whole and all necessary 
elements are there. Since everything you need is there, you aren't 
tempted to go beyond the present experience, and since nothing is there 
that isn't required, your absorption into the world of the product will 
not be disturbed. Unity of purpose and unity in execution should be the 
hallmark of your team. Unity is achieved in a product by following 
certain creative principles (#15-#19, below), whether intuitively or 
consciously.



15. State your theme.



Theme is the dominant idea that constitutes the basis of the design. All 
of the values of the product must stem from the theme. In order for 
people to comprehend the theme, it must be rendered with surpassing 
clarity. Theme is analogous to purpose. The more specific the purpose, 
the greater the effect. Having a theme to the product will require that 
you eliminate or at least minimize orthogonal values. This is painful 
and involves risk.



16. Vary it.



Variation is the theme restated and elaborated in slightly altered and 
embroidered ways. Variation is the means by which we intensify the 
user's comprehension and appreciation of our theme, and leverage his/her 
growing consciousness in new ways.



17. Balance it.



Allocate appropriate emphasis among the various elements of the product. 
If a key component supporting the theme, encountered every time the 
thematic function is enacted, is weak, the theme is weakly stated and 
the product will be justly criticized.



18. Evolve it.



Evolution is when earlier parts determine later parts. Lessons learned 
in one part of the product apply to the others. Things progress in a way 
that is pleasing. Outcomes, if not predictable, are satisfying because 
the product foreshadows them in countless ways.



19. Your product should be a hierarchy.



Hierarchy is when the elements of the product gain attention in 
proportion to their importance. Closely related to the property of 
balance, hierarchy provides a means for establishing and evaluating 
balance. If the theme is the top of the hierarchy, elements at the next 
level have balanced value with respect to each other, all equally 
supporting the thematic function, and so on throughout the rest of the 
hierarchy.



20. Establish a shared vision.



It seems absurd to even have to state this, yet it is perhaps the most 
difficult thing of all to achieve. Everybody on the team must know what 
they are trying to achieve, what the finished product will look like, 
what the basis of the product strategy is, and when they must deliver it 
in order for it to have its intended effect. Contradictory visions must 
be resolved and unified. Harmonious purpose must be achieved, or 
greatness is out of the question and even shipping becomes infinitely 
more complicated.







Shipping



21. Get the team into ship mode.



There is a moment on every development project when it is ideal for a 
team to enter ship-mode. Ship mode is a high performance period 
characterized by efficiency and determination. It is a period of flow. 
Before a team can enter ship mode, several pre-requisites must be satisfied.



1. Shipment must be the next milestone.



2. Everybody (or nearly everybody) must believe that achieving the 
milestone is possible.



3. All members of the team must understand precisely what they must do 
prior to shipping. All unknowns are factored out.



4. Management must lead the team to ship mode by entering ship mode 
first. That is, superfluous management hoo-ha is eliminated, the 
manager’s awareness of detail climbs, fire-drills and other 
de-prioritizing activities are eliminated entirely and tremendous focus 
is brought to bear.



5. The team must desire to ship. Generally, a complete awareness of the 
effect of shipping (or not shipping) will create desire.



The team becomes especially vigilant about thinking things through, and 
looking for traps. Check-ins are made with extra precaution. 
Stabilization of the product is the principle goal. All development is 
complete but for bug fixing.



The endgame, the last stage of shipmode, is different yet again. It is 
conceptually a very simple exercise. There is a list of activities. When 
every activity on the list is complete, you ship. Though the list might 
have hundreds or thousands of items, it is still just a list. There is 
no time for any effort that does not contribute toward completing the 
items on the list. Everybody is expected to complete their items as 
promised. As unanticipated items arise, after appropriate resistance, 
they are put on the list.



A daily meeting should be established, with final decision-makers in 
attendance. Agenda is ad hoc, assembled at the beginning of each 
meeting. No item is postponed that can be handled now. The team is aware 
that all issues can be brought to this meeting for expeditious remedy. 
Management is involved, leading the team toward their goal.



The goal is an acceptable quality level at ship time. Only showstopper 
bugs should be addressed at all. Showstoppers are bugs that will either 
effect more than a handful of users or will cause unacceptably serious 
errors. Cosmetic changes, performance enhancements, new functions are 
not appropriate changes. The purpose of beta feedback during this period 
is to prove there are no showstoppers, provide advance warning of 
unanticipated market reaction and provide input to the next release.



Understand the range of quality that is acceptable to your customers. 
How many low priority bugs did your product ship with last time? Was it 
a problem? Are the customers better off with this product including this 
bug? Since destabilizing the software is more of a problem than most 
bugs, be very careful about which bugs you fix. This is why we have 
"ReadMe’s" and bug lists.



Shipmode is basically a succession of daily milestones climaxing with 
the product’s shipment.



Many thanks to the staff and management of the Visual C++ Business Unit 
at Microsoft, from whom I learned and plagiarized these ideas.

--
Plants for a Future: 7000 useful plants
Web:   http://www.pfaf.org/ same as http://www.comp.leeds.ac.uk/pfaf/
Post:  1 Lerryn View, Lerryn, Lostwithiel, Cornwall, PL22 0QJ
Tel:     01208 872 963 / 0845 458 4719  
Email: webmaster@pfaf.org
PFAF electronic mailing list http://groups.yahoo.com/group/pfaf