I am happy to be going to a Certified Scrum Product Owner Course this week in Boston. Having done the scrum thing for a number of years now, I am looking forward to speaking with and thanking the 2 people giving the course Ken Schwaber and Mike Cohn.

Ken Schwaber is one of the folks to really started scrum. Without Ken’s writings and efforts - many more of my projects would have been less successful. Scrum has been a key part of my software belief system for some ~4 years now.

Mike Cohn on the other hand has had a profound impact on how I have been doing “requirements”, software planning and estimation. I look at Mike’s work as a sort of 2nd generation of stuff on top of scrum. Mike’s work in using user stories as the product backlog has been instrumental in how I view “requirements”/ feature management - product backlog development. This set of work has built upon the initial “scrum stuff” in a way that has really helped deliver software.

This particular course is focused on the product owner role. I have been spending lots of time “getting together meaningful product backlogs” for all of the teams moving to scrum at my current firm. It is an interesting effort and challenge. I am also trying to coordinated stuff between multiple product backlogs, deal with lots of “technical focused teams”, “infrastructure teams” etc. In a big firm - there is a lot going on! It seems this course is right in the space I need some extra guidance. I think I am aware of all of the writing, newsgroups etc - and these resources have been extremely valueable in going about my business. I have all of the “textbook answers” - now - where the rubber meets the road in daily life - any extra guidance would be great.

-Chris

Arguments - YUK! Whenever you work with lots of smart people - as I always hope to - there are bound to be debates, stronger debates - and yes - even arguments. When people are working hard, involved, impassioned about their work - their careers - the things that they are interested in; communication can get hard. I think that software people tend to be bright and highly logical. This is a blessing and a curse. Technical and analytical skills are extremely important. The other key part of ANY work is the inter-personal part of it. The technical part is what they will hopefully do - the inter-personal part is HOW they will do it. Communication is the heart of software work.

I DO also think that there are better software people than others  -we pick the ones we *want* via the interview process. We also are put into groups of people we did not interview. This is good too as it helps you to see all kinds of people - the ones you would have *picked* via an interview and the ones that you would not have. I think that you can find people that are bright and have very different view points that you - but there will always be some common ground with these people - else you would not think they were so bright. One of my ‘things’ that I believe -

“As long as you are in your zone of comfort - you are not growing”

I think/ hope/ have heard that one of my *skills* is being able to talk with/ deal with other software people. I have had to run teams for some years now and I think THAT is much more about managing the brilliant people you hire than managing the work they do. We hope to hire bright people that will do great work - and we hope to be able to get all the brilliant people to actually work together to get said work done.

This is fine - but. With all of these people involved - the differences of opinion, differences in experiences, differences in background, preferences etc will all contribute to the inevitable debates. The debates will eventually come down to matters of opinion that will need to get *picked*. When work needs to be done, decisions need to be made. People have different opinions - how do you choose? More importantly - the point of this posting - how do you convince people of your point of view? How do you convince people that your view is *better* or at least better suited to the work at hand?

When you are the *boss* it is easy - you take in the input from all your smart people - you think - and you make a judgment call. When you are NOT the boss - you have to be more compelling I think that considering the goals of the decision maker is the 1st and most important think to think about here. If you are NOT the decision maker- you MUST consider the end state that the actual decision maker(s) have in mind. No matter how *good* your arguments are - if they matter not to the decision maker - your words will not matter. During the course of your debate you must watch out for…. the evil inside all of us technical people….

Intellectual Snobbery

This is what I am talking about here…. I am always trying to be as respectful as possible when I have a difference of opinion from another person - usually these are software people. As I mentioned earlier - I have often been put in leadership roles for software people and I have been told that I am good with people and personalities. I am always trying to put the intellectual snob inside me back into his dark box…. yet I am still debating my beliefs strongly. I DO BELIEVE that healthy debate is the road to better solutions. Put your ideas to the trial by fire. If your ideas are *better* - the fire will prove it. The folks on the other side of the debate must be open to doing the same.

Be respectful - yet do stand your ground. Hopefully - the people that employ you think that you have some value. Hopefully - you do. Hopefully - you will be able to relay your views to others in a way that is compelling, open and un-intimidating. Do this - and you may win your debate. I would also have a read of some of the ‘conventional writing’ on how to win an argument - you can find this 99 places on the web - but for convenience - I will repost here

 38 Ways to Win an Argument

1. Carry your opponent’s proposition beyond its natural limits; exaggerate it.
   The more general your opponent’s statement becomes, the more objections you can find against it.
   The more restricted and narrow your own propositions remain, the easier they are to defend.
2. Use different meanings of your opponent’s words to refute his argument.
   Example: Person A says, “You do not understand the mysteries of Kant’s philosophy.”
   Person B replies, “Of, if it’s mysteries you’re talking about, I’ll have nothing to do with them.”
3. Ignore your opponent’s proposition, which was intended to refer to some particular thing.
   Rather, understand it in some quite different sense, and then refute it.
   Attack something different than what was asserted.
4. Hide your conclusion from your opponent until the end.
   Mingle your premises here and there in your talk.
   Get your opponent to agree to them in no definite order.
   By this circuitous route you conceal your goal until you have reached all the admissions necessary to reach your goal.
5. Use your opponent’s beliefs against him.
   If your opponent refuses to accept your premises, use his own premises to your advantage.
   Example, if the opponent is a member of an organization or a religious sect to which you do not belong, you may employ the declared opinions of this group against the opponent.
6. Confuse the issue by changing your opponent’s words or what he or she seeks to prove.
   Example: Call something by a different name: “good repute” instead of “honor,” “virtue” instead of “virginity,” “red-blooded” instead of “vertebrates”.
7. State your proposition and show the truth of it by asking the opponent many questions.
   By asking many wide-reaching questions at once, you may hide what you want to get admitted.
   Then you quickly propound the argument resulting from the proponent’s admissions.
8. Make your opponent angry.
   An angry person is less capable of using judgment or perceiving where his or her advantage lies.
9. Use your opponent’s answers to your question to reach different or even opposite conclusions.
10. If you opponent answers all your questions negatively and refuses to grant you any points, ask him or her to concede the opposite of your premises.
    This may confuse the opponent as to which point you actually seek him to concede.
11. If the opponent grants you the truth of some of your premises, refrain from asking him or her to agree to your conclusion.
    Later, introduce your conclusions as a settled and admitted fact.
    Your opponent and others in attendance may come to believe that your conclusion was admitted.
12. If the argument turns upon general ideas with no particular names, you must use language or a metaphor that is favorable to your proposition.
    Example: What an impartial person would call “public worship” or a “system of religion” is described by an adherent as “piety” or “godliness” and by an opponent as “bigotry” or “superstition.”
    In other words, inset what you intend to prove into the definition of the idea.
13. To make your opponent accept a proposition , you must give him an opposite, counter-proposition as well.
    If the contrast is glaring, the opponent will accept your proposition to avoid being paradoxical.
    Example: If you want him to admit that a boy must to everything that his father tells him to do, ask him, “whether in all things we must obey or disobey our parents.”
    Or , if a thing is said to occur “often” you are to understand few or many times, the opponent will say “many.”
    It is as though you were to put gray next to black and call it white; or gray next to white and call it black.
14. Try to bluff your opponent.
    If he or she has answered several of your question without the answers turning out in favor of your conclusion, advance your conclusion triumphantly, even if it does not follow.
    If your opponent is shy or stupid, and you yourself possess a great deal of impudence and a good voice, the technique may succeed.
15. If you wish to advance a proposition that is difficult to prove, put it aside for the moment.
    Instead, submit for your opponent’s acceptance or rejection some true proposition, as though you wished to draw your proof from it.
    Should the opponent reject it because he suspects a trick, you can obtain your triumph by showing how absurd the opponent is to reject an obviously true proposition.
    Should the opponent accept it, you now have reason on your side for the moment.
    You can either try to prove your original proposition, as in #14, maintain that your original proposition is proved by what your opponent accepted.
    For this an extreme degree of impudence is required, but experience shows cases of it succeeding.
16. When your opponent puts forth a proposition, find it inconsistent with his or her other statements, beliefs, actions or lack of action.
    Example: Should your opponent defend suicide, you may at once exclaim, “Why don’t you hang yourself?”
    Should the opponent maintain that his city is an unpleasant place to live, you may say, “Why don’t you leave on the first plane?”
17. If your opponent presses you with a counter-proof, you will often be able to save yourself by advancing some subtle distinction.
    Try to find a second meaning or an ambiguous sense for your opponent’s idea.
18. If your opponent has taken up a line of argument that will end in your defeat, you must not allow him to carry it to its conclusion.
    Interrupt the dispute, break it off altogether, or lead the opponent to a different subject.
19. Should your opponent expressly challenge you to produce any objection to some definite point in his argument, and you have nothing to say, try to make the argument less specific.
    Example: If you are asked why a particular hypothesis cannot be accepted, you may speak of the fallibility of human knowledge, and give various illustrations of it.
20. If your opponent has admitted to all or most of your premises, do not ask him or her directly to accept your conclusion.
    Rather, draw the conclusion yourself as if it too had been admitted.
21. When your opponent uses an argument that is superficial and you see the falsehood, you can refute it by setting forth its superficial character.
    But it is better to meet the opponent with acounter-argument that is just as superficial, and so dispose of him.
    For it is with victory that you are concerned, not with truth.
    Example: If the opponent appeals to prejudice, emotion or attacks you personally, return the attack in the same manner.
22. If your opponent asks you to admit something from which the point in dispute will immediately follow, you must refuse to do so, declaring that it begs the question.
23. Contradiction and contention irritate a person into exaggerating their statements.
    By contradicting your opponent you may drive him into extending the statement beyond its natural limit.
    When you then contradict the exaggerated form of it, you look as though you had refuted the original statement.
    Contrarily, if your opponent tries to extend your own statement further than your intended, redefine your statement’s limits and say, “That is what I said, no more.”
24. State a false syllogism.
    Your opponent makes a proposition, and by false inference and distortion of his ideas you force from the proposition other propositions that are not intended and that appear absurd.
    It then appears that opponent’s proposition gave rise to these inconsistencies, and so appears to be indirectly refuted.
25. If your opponent is making a generalization, find an instance to the contrary.
    Only one valid contradiction is needed to overthrow the opponent’s proposition.
    Example: “All ruminants are horned,” is a generalization that may be upset by the single instance of the camel.
26. A brilliant move is to turn the tables and use your opponent’s arguments against himself.
    Example: Your opponent declares: “so and so is a child, you must make an allowance for him.”
    You retort, “Just because he is a child, I must correct him; otherwise he will persist in his bad habits.”
27. Should your opponent suprise you by becoming particularly angry at an argument, you must urge it with all the more zeal.
    No only will this make your opponent angry, but it will appear that you have put your finger on the weak side of his case, and your opponent is more open to attack on this point than you expected.
28. When the audience consists of individuals (or a person) who is not an expert on a subject, you make an invalid objection to your opponent who seems to be defeated in the eyes of the audience.
    This strategy is particularly effective if your objection makes your opponent look ridiculous or if the audience laughs.
    If your opponent must make a long, winded and complicated explanation to correct you, the audience will not be disposed to listen to him.
29. If you find that you are being beaten, you can create a diversion–that is, you can suddenly begin to talk of something else, as though it had a bearing on the matter in dispute.
    This may be done without presumption if the diversion has some general bearing on the matter.
30. Make an appeal to authority rather than reason.
    If your opponent respects an authority or an expert, quote that authority to further your case.
    If needed, quote what the authority said in some other sense or circumstance.
    Authorities that your opponent fails to understand are those which he generally admires the most.
    You may also, should it be necessary, not only twist your authorities, but actually falsify them, or quote something that you have entirely invented yourself.
31. If you know that you have no reply to the arguments that your opponent advances, you by a find stroke of irony declare yourself to be an incompetent judge.
    Example: “What you say passes my poor powers of comprehension; it may well be all very true, but I can’t understand it, and I refrain from any expression of opinion on it.”
    In this way you insinuate to the audience, with whom you are in good repute, that what your opponent says is nonsense.
    This technique may be used only when you are quite sure that the audience thinks much better of you than your opponent.
32. A quick way of getting rid of an opponent’s assertion, or of throwing suspicion on it, is by putting it into some odious category.
    Example: You can say, “That is fascism” or “Atheism” or “Superstition.”
    In making an objection of this kind you take for granted
    1)That the assertion or question is identical with, or at least contained in, the category cited;
    and
    2)The system referred to has been entirely refuted by the current audience.
33. You admit your opponent’s premises but deny the conclusion.
    Example: “That’s all very well in theory, but it won’t work in practice.”
34. When you state a question or an argument, and your opponent gives you no direct answer, or evades it with a counter question, or tries to change the subject, it is sure sign you have touched a weak spot, sometimes without intending to do so.
    You have, as it were, reduced your opponent to silence.
    You must, therefore, urge the point all the more, and not let your opponent evade it, even when you do not know where the weakness that you have hit upon really lies.
35. Instead of working on an opponent’s intellect or the rigor of his arguments, work on his motive.
    If you success in making your opponent’s opinion, should it prove true, seem distinctly prejudicial to his own interest, he will drop it immediately.
    Example: A clergyman is defending some philosophical dogma.
    You show him that his proposition contradicts a fundamental doctrine of his church.
    He will abandon the argument.
36. You may also puzzle and bewilder your opponent by mere bombast.
    If your opponent is weak or does not wish to appear as if he has no idea what your are talking about, you can easily impose upon him some argument that sounds very deep or learned, or that sounds indisputable.
37. Should your opponent be in the right but, luckily for you, choose a faulty proof, you can easily refute it and then claim that you have refuted the whole position.
    This is the way in which bad advocates lose good cases.
    If no accurate proof occurs to your opponent, you have won the day.
38. Become personal, insulting and rude as soon as you perceive that your opponent has the upper hand.
    In becoming personal you leave the subject altogether, and turn your attack on the person by remarks of an offensive and spiteful character.
    This is a very popular technique, because it takes so little skill to put it into effect. (this is wha trolls like to do)

Taken from Arthur Schopenhauer’s Art of Controversy.

-Chris

Thoughtworks has some ineteresting metrics posted. It seems that they have tasked Forrester Research with quantifying the advantage that ‘their’ agile approach provided their clients. Here is a noteworthy metric excerpt (again, wish we had an xhtml web where I could xlink/ point to this):

Client: Four Fortune 500 Companies
• Improved time to benefit by 69%
• Reduced cost by 57%
• Reduced effort by 62%
• Reduced critical defects by nearly 80%
• Reduced overall defects by more than 60%

Wow. Those are some nice #s. There are links through to some underlying white papers. Being someone that appreciates a good quantification of work being done - this stuff is great.

Here is another interesting excerpt:

“The quality of the ThoughtWorks staff and their ability to handle difficult projects drove
efficiency within the organization, reducing the potential for defects and rework down the
road that can be associated with complex projects.”

I can certainly say that hiring the best is one of the biggest - if not THE biggest element to a winning software project. I think if you combine this notion with an agile process - you really can realize some substantial benefits when running your software projects. I think this is also just what Finetix - my illustrious employer is trying to do; hire the best and brightest and run the projects with an agile approach. Furthermore - they are focused on the financial markets projects - thus winning an edge in specialization over companies like Thoughtworks. While I DO believe and have seen how an agile approach is key to winning software projects - having serious software developers on the team is just as pivotal. Teams of ALL junior developers can realize benefits by follwing an agile approach - but teams with leadership and excellent developers will realize much more substantial benefits.

-Chris

I finally got to reading through many folks blogs this evening. Here are several interesting posts that I eventually drilled through to:

Is Static Typing a Form of Bad Coupling? - More static/ dynamic language stuff

Finlabs - REAL COOL Algorithmic Trading
The 48 Laws of Power

Development Abstraction - go Joel - this is a great article. As Jeremy put it - I had almost given up on Joel - but this IS a great article - I particularly like this:

Management, in a software company, is primarily responsible for creating abstractions for programmers. We build the yacht, we service the yacht, we are the yacht, but we don’t steer the yacht. Everything we do comes down to providing a non-leaky abstraction for the programmers so that they can create great code and that code can get into the hands of customers who benefit from it.

That is just great. I call this idea “Building Boxes”. We try to - in essence, build boxes for the development teams. We build non-leaky abstractions - and they fill up the boxes. I talk about this all the time - well said Joel!

Go Obie - A web-based IDE for Ruby on Rails

Oh yes - SharpRobo - I am a FIT fan - so this ROCKS -

SharpRobo is a Functional Testing and Recording tool for WinForm applications written in .NET supported language. It supports all the standard WinForm controls. SharpRobo records the tests in FIT format which can be played back using Fit (File or Directory Runner).

More cool stuff via Obie - ActiveMessaging - for Ruby.

Lots of interesting stuff in the world as always

-Chris

I am leaving the project that I am leading currently in a few weeks. Today I began handing off the lead to one of the developers on the project. The task of getting the entire team ‘on the beat’ of the project and keeping them there is key for this person to be able to maintain. One of the other developers was asking me today what he could read/ do to ‘totally revamp and update his code style’. In trying to introduce agile practices to a group - the group has a lot to change.

Some of the stuff that we introduced:

• Mock objects (Rhino Mocks)
• Unit testing (NUnit)
• SpringFramework.net
• log4net

Design Patterns including
• Model/ View/ Presenter based architecture
• Strategy

I sent him some of the books, articles etc. that I usually recommend. This chat however got me to thinking - what does it take to become a great developer? There are really 2 transitions that I was thinking about; the transition from a mid-level to a senior developer, and the transition from being a seasoned developer to a world class developer. In the past I have said that the central thing that I am looking for in a developer is someone who is effectively a ‘Good abstract problem solver’. I still think this holds true.

That being said - there are some foundations that I typically look for in a developer - particular mostly to C# and Java developers, but much is also applicable to other development.

Principals

• Inversion of control - see Pico Container, Spring, Martin Fowler, Object Mentor
• Open Closed Prinicipal - see Object Mentor
• Seperation of interface from implmentation - see Object Mentor

Design

• Model domain in software - see Domain Driven Design
• Learn the ‘classical design patterns’ - see GoF book and language specific variants

Code level

• Design by contract
• Assertions
• Guard clauses
• Intention revealing interfaces - see Domain Driven Design
• Effective class composition - single purpose classes and methods
• Learn the Refactoring Patterns - see Martin Fowler

Language Level

• Understand the runtime you are working in
• garbage collection
• how the heap/ stack work
• Threading - deep understanding of concurrency issues
• Be able to program in at least a few different languages

Enterprise

• Understand Databases
• Understand messaging systems
• Understand XML
• Understand heterogenous as many system interoperation mechanisms as possible
• Understand web services
• Understand security concerns

What does it take to be great? A thirst to learn. A thirst to experiment. Coding is what makes you learn. Working with smart people will help you learn. Doing ‘pet projects’ will help you learn. Stretch your ara of comfort all the time. If you think C is hard - do a pet project in it. If you are intimidated by C#, Java, Ruby, Web Services, ANYTHING - just try it - you will see how much more alike they all are then you think. You will also learn to love the differences and functions of all.

I will continue to update this as I need to run

-Chris

It was only a matter of time. Ruby for .net CLR. This will be of marginal importance in the grand scheme I imagine, but ruby is lovely and so is .net.

Most ruby work will ultimately be on *nix machines, so I do not really see the value - aside from the fun/ cool factor. But it does have that

IronPython and Boo are 2 existing dynamically typed languages for the .net run-time. We shall see if adding a 3rd helps.

read more | digg story

UPDATED ** see RubyCLR for a MUCH more complete implementation of Ruby for the .net CLR. Great work!

Eclipse has great integration with subversion. I have been using subversion for my personal sorce control for a few weeks now. It is working out great. I have been a strong perforce fan, but it is only free for 2 users - ~$750/ user for ‘real’ life w/ perforce. SourceSafe is the devil. ClearCase is the devil. CVS I have had issues with enough. Subversion it is…

Just a few niceties:
In the main workspace area - you can browse the structure of your current workspace file and get a nice diff against the repository file. This is great to have IN the IDE. Subversion is great - you normally do it from the command line - but having the high intagration with the IDE is really great - down to the diff.

It is also nice and easy to simply browse a repository and see what is there.

All in all - this is a great TOTALLY FREE solution for source control - and it is integrated right into the IDE. I am continually impressed by how far they have taken Eclipse. I will go into the latest edition of Ruby Eclipse next….

-Chris

I have been a using fan of DevMetrics for some time now (since it came out I believe). That being said - we have been using CruiseControl to do daily and checkin builds. We have been chatting about using NAnt tasks to keep historical copies of the DevMetrics reports so we could watch the codebase over time…..

LO AND BEHOLD :

FishEye

For example:

Spring.net in FishEye action.

and:The ‘real’ spring framework (lol) in FishEye action.

Unfortunately they are ‘working on’ support for Perforce and ClearCase… Sooner than later we hope!

Filter by user, show for directory, show diffs, etc, etc…

-Chris

Oh how I echo my colleague’s thoughts!!!

Marc

We are surely suffering!!! - Oh how I long for my friend Perforce!!!

An article in this month’s Software Development Magazine has gotten me thinking about what it means to service clients effectively. At the end of the day - that is the end game - to service a client in a way that will make them want to let you service them again.

From the Agile Project Leadership Network

Core Principles (on the Project Leadership front)

In order to consistently deliver successful results, great project leaders embrace the following practices:

·             Relentlessly Focus on Value. Focus efforts on generating organizational value rather than managing tasks.
·             Be Situational Specific. Use situationally specific strategies, not a one-size-fits-all approach.
·             Manage Uncertainty. Manage uncertainty through client focused collaborative exploration and proaction.
·             Continuously Align to Changing Situations. Choose strategies for leading within a dynamic environment.
·             Lead with Courage. Confront reality with conviction and a dedication to purpose.
·             Build Strategies that Leverage People. Challenge team members with opportunities to grow professionally.
·             Design Strategies Based on Teamwork. Develop and sustain a collaborative team environment.
·             Communication Through Immediate and Direct Feedback. Maintain control through feedback, not prescriptive plans.

From the Declaration of Interdependence

·             We increase return on investment by making continuous flow of value our focus.
·             We deliver reliable results by engaging customers in frequent interactions and shared ownership.
·             We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
·             We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
·             We boost performance through group accountability for results and shared responsibility for team effectiveness.
·             We improve effectiveness and reliability through situationally specific strategies, processes and practices.

Both of these were quoted in this month’s Software Development Magazine and it got me to thinking. What are the real core things that we are trying to achieve for clients? How do we do these things? What is a reduced - short list of our goals for clients and the means to do it?

• Focus on increasing ROI/ Value for the client - this must be the topmost item. If this is not achieved, all is lost. As an organization employing an agency - you will never do so again with the specific vendor. As a vendor, you will never get back into that client and word will spread that you cannot provide value.
• Exercise situational specificity - We can improve effectiveness in general by being agile with processes and practices - within bounds. Processes and practices can change and be adapted to the specific client’s need. This is somewhat of a slippery slope- altering process and practice too much can become - chaotic. That being said, organizations are all different. Situations vary. Circumstances happen. I think that certain things are like religion however… Sometimes people get caught up in religion and basically lose the ideas that are presented by the religion. At the end of this road - you have people rigidly following some religion construct - and missing the things that the originator(s) of the religion intended. Process and practices I believe can be the same - people get so accustomed to the process that they become it’s slave. This is of course the worst case scenario, but I believe that to some extent - this is partially the case in many places. We must simply be able to understand what we are trying to accomplish with our agile methods - and utilize the tools that are presented by the many frameworks for agility (XP, Scrum, Crystal, etc) and be flexible with our clients.
• Manage and expect uncertainty - THINGS CHANGE. Difficult software issues come up that could not have been foreseen. Resources come and go. New products come out. Requirements change. Organizations have re-orgs. Project owners change. There are so many possible points of uncertainty that it is irresponsible to NOT expect uncertainty. This uncertainty is to some degree manageable as long as it is expected and not ignored.
• Teamwork/ Leverage People/ Group Accountability - People, People, People - individually and collectively. Teams are amazing. Teams - the whole exceeds the sum of the parts. That being said; teams can also have the ‘Babe Ruth’. Teams can certainly have people that can hit home runs in their areas, the best teams certainly have these superstars. Superstars - together in a supportive - interdependent group of other team players is just plain powerful. When people feel supported - they feel empowered. When people are smart and empowered, they will be immensely creative and yes - innovative. As long as the team is coordinated - the team players will be able to bring home a project that all players are proud of. This makes people want to come to work. People that want to come to work - do great work. At the same time - the client will actually get a piece of software that is actually maybe innovative! The likelihood of this situation winning is huge, compared to a situation when the stars are not allowed to shine, and there is no (or even weak) teamwork.
• Continual feedback with client - “client focused collaborative…”, “engaging customers in frequent interactions…” This point is crucial. The need to have continual visibility with the client and to have frequent releases is just key. This is an excellent risk management tool for software projects. Clients will have changes - when there is an environment when feedback is EXPECTED - you will get good feedback. If feedback is expected on a monthly basis, then clients will be more open to allow those requests to wait till a ‘comfortable juncture’ - it will never be > 1 month away. The feedback loop can effect process and practice, it can also effect the requirements, it can also give the client more actual value when they are amidst the project. The feedback process allows the real opportunity to increase the value of the software to the client.

Whatever the ‘method’ being applied - learn the things that the agile camps are trying to sell - these items listed above!!!! Accomplish these goals with your clients. Vary as needed - but the processes and methods that are out there HAVE already made solutions to many of these issues. Do not just pick and choose pieces from the agile camp - take an actual method - craft it to your way of doing business and just be flexible enough to not let the process run you - but make the process help you to increase the value to the client, manage the risk/ uncertainty and just plain deliver excellent software that people are proud to have been a part of.

Enough of my Babel….
-CD