pushbomb

Hi! I’m Damon, a dedicated Agile evangelists and practitioner that has implemented an Agile Method into a successful company that is C#/.NET focused (with the help of my incredibly talented team). We are agilefactor (http://www.agilefactor.com/) and combine the following:

1) A unique Agile processes which includes a dramatic Risk Management infrastructure.

This is best described in the book ‘Waltzing with Bears: Managing Risk on Software Projects’. This is a Jolt 2004 winner and a leap forward for our industry. Probably the most significant book since ‘Design Patterns’ from the GoF in my opinion. There are many amazing books in between and after but I am talking about a fundamental leap forward. If I.T. managers globally would read this then the terrible statistics we face in our industry would improve dramatically, I have no doubt.

For example, we do not discuss dates that occur in the future without a corresponding ‘confidence percentile’, ever, because we cannot predict the future!

We can only try to manage the possibilities of what may happen. Of course we are iteration driven, so if Iteration 9 is looking bad because we slipped on some features in Iteration 7 asnd 8 (our iterations are always fixed – typically 2 or 3 weeks) then we may say to the client: “Iteration 9 is looking like a 60% confidence. We have your stated goal in mind of 80%. We recommend we drop a few features or look at adding an additional developer if the situation doesn’t improve”.

Of course we do not make the foolish assumption that you can add staff and have linear productivity forever (see the classic ‘The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition’). We have a proprietary algorithm which estimates the effect of adding incremental resource X given existing staff Y. You are linear to a point, then each person is less then 100%, then they actually start to take productivity away. This is different on every project and we correct the variables from past history and as we move through iterations on a specific projecy (which is why metrics are critical). We have found a wide range of statistics given the existing team, scope of the project, political climate, etc. I have never seen two spreadsheets look the same here, although they all start from our common model (which is also evolving and improving constantly).

The idea of a binary success/fail for future release (or other) events on a project plan is just plain broken.

I use the Data Center analogy. One of my first questions to a client is ‘How much risk are you willing to assume’. They often say none. I say ‘ok we need 30 people and it will take 3 years to eliminate ALL risk of anything that could possibly happen in the future’. Of course they do not want to pay for that and I lighten the shock and say “we are not building a life-critical system where people may die, we are not NASA. Our budget makes a 100% success an impossibility”.

I use the Data Center analogy as most people get it. 24/7 99.9% uptime is incredibly hard and expensive. To make a long story short most customers accept between 80-90% (10-20% Risk), so they are accepting risk from the start, and explicitly. We avoid fixed cost projects and when we accept them we have an incredibly stringent ‘change order’ process, for even the most trivial items. Clients are almost always better off working on a T&M basis, but if a Fixed Cost project is demanded we make the necessary adjustments. But we do not do ‘up front’ requirements elaboration beyond just identifying the requirement, its priority and perhaps a few sentences. So a fixed price engagement is in many ways almost impossible (and is a bad idea in general for Agile projects in my humble opinion).

For the exact same project, where assume the date is fixed, the team size is much different for the 90% confidence over the 80%. Our methoid is about attempting to stack the deck in the clients favor for whatever the future may bring. We cannot predict it but we can plan for it. Studies show that the unplanned events are what get you most of the time, or even planned events that you though were gone but really were still there. You can have the best Project Plan in the world and it really is not going to help guarantee you the version of the future you want.

Only a borderline obsession with managing risk will get you to a desired end state. That is why we have had a 100% success rate using our Agile method (and I have only covered the tip of the iceberg).

Just look at the Standish group statistics. The custom software development world has failed miserably (see http://www.agilefactor.com/stats.aspx) or look at the studies themselves here (http://www.standishgroup.com/). We have an agenda to change that (as do all the other Agile methods). It is incredible to me how many companies put their hand into fire, get burned and do it again and again. And when you present a solution they instinctively fall back into what is familiar and proven to fail.

We also add core metrics to our process which helps immensely in our ability to succeed.

These are automatically produced deliverables (as we use an automated SDLC tool) in the process as we usually work with the world’s largest financial institutions. Their audit and compliance needs to see these. We also leverage a Web based full SDLC tool for managing iterations, user stories/use cases, defects, etc. This is how we can easily produce metrics and continually improve. The work from Version One is fantastic here. They are also a Jolt 2004 winner.

2)We focus on C# and the .NET platform.

In this economy you can simply do much more with less when using .NET. Higher quality, productivity and overall total cost of ownership are dramtically less with an Enterprise C#/.NET solution. I like J2EE, it just costs far more in people, hardware, support, etc. At Columbia University where I lectured on .NET and am working on a Masters in Computer Science we did amazing things in a short amount of time. The web site has my lecture if you are interested.

Our team represents the ‘best of the best’

Studies show a 28x increase in overall productivity from the ‘best’ people (see: Facts and Fallacies of Software Engineering”, by Robert L. Glass). It is one of the best deals going in business. That is why it is incredibly hard to get in. But once you are in, you are part of a family. Only one in 100 makes it to agilefactor (counting all interactions, including a resume submission). I want the 28x improvement individual and I will turn down business if I cannot find enough of them. I am willing to pay above market for it as well. But so few people can answer all the questions from Software Engineering, Object Oriented Design, Agile concepts, .NET Internals, C#, etc. Like ‘what is the difference between an Interface and an Abstract Class in C#’. Or ‘how can you do in .NET to add some control to the garbage collection process in your classes, specifically around supressing the finalizer and dealing with cases where people forget to use the pattern. What keyword automatically handles this for you (which is not availble in VB.NET).

3) We are software engineer’s, not coders.

See the work by Steve McConnell in his fantastic book: “Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers”. I highly recommend you read this rather philosophical offering.

4) We use a UML extensively.

We love the tool called “Sparx EA” which is inexpensive and amazing in its robustness and execution. See: http://www.sparxsystems.com.au/ . I cannot recommend this highly enough, especially if you are a Visual Studio 2003 user as it has full integration (with their MDG Link for Visual Studio.NET). We also follow Agile Modeling and are very much into the work of Scott Ambler. His latest book is great “The Object Primer”. I use it to teach introductory courses.

5) We have tight and mutually beneficial relationships with our partners and customers.

These include Sparx, Intrinsyc (their JA.NET product is fantastic), Microsoft, the ‘Agile Alliance’ and the fantastic work done by Ken Schwaber (http://www.agilealliance.com/), one of the nicest guys, and a professional I hope will write the intro to my book. We follow the Agile Manifesto in all areas.

5) I could go on and on but I am working on the book: “agilefactor” which details this in all the minute detail required to help you execute these ideas. I wanted to keep this short but I guess I had a lot to say.

In 6-12 months when people list Agile methods (like XP, SCRUM, Crystal, Evo) I have no doubt that ‘agilefactor’ will be part of that list. It is just too successful and evolutionary in its offerings. I need to get this book out and I am so busy.

As for me, being CEO and Chief Technologist I read obsessively (at least one technical book a week) and am currently consulting for one of the world’s largest financial firms as a senior .NET architect. I’ve been doing a lot of complex Multithreading, .NET Remoting Servers (usually as Windows Services), and other innovative tasks that are so fun! I’ll be posting on those topics, as well as some of the cool things I’ve done lately (a Typed Dataset generator that use the Annotations feature in the XSD as an add-in to VS 2003, using the fantastic work over on www.gotdotnet.com of the new Database Abstraction Layer (DAAB) which lets you change databases fairly easily (you still need to rewrite your stored proces and any SQL that is DB specific. Look for more on that as well.

Kind Regards (if you are still with me )…

Damon