It's Been A Circus

Sorry for the delay guys!

Lately it has been a circus around here. Lots of new projects and learning going on these days. Who's in a recession? Not the tech industry!

So I've been working on Facebook Apps, MOSS customizations, writing tons of Silverlight widgets, reams of XAML and buckets of boatloads of WPF.

I'll bring you up to date on the latest shenanigans once things calm down a bit. Feel free to post questions if you want to spur my creative juices!

Leadership and Agile

This week I had several opportunities to speak with people about Agile.

As I listened to yet another discussion about Agile there were several things about the conversation that just really stuck out to me. It started with one strong idea of which I just couldn't seem to let go:

Agile is great under the umbrella of strong leadership. If the direction, metrics or criteria for success aren't well understood and broadly accepted across the organization, then returns on investment and efficiencies will likely not be realized.

In high-performing companies the gestalt is achieved when the employees are empowered to self-direction and a feeling of ownership. Even in these companies, that sense of empowerment and value is only powerful as the individual choices and decisions can be aligned to the bigger vision of the organization as a whole. When the vision or mandates of the organization aren't clearly articulated or fail to be fully accepted within the ranks, then organizations experience churn and confusion. Without alignment to a bigger mission, the agendas from the various levels of management tend to begin conflicting and drifting as individual interpretations of value and success criteria are formed. This churn due to conflicting expectations makes it easier for issues to hide and for misalignment to go unchecked for increasing periods of time.

Even in cases where misalignment is uncovered, the process needed to achieve consensus can then take longer and without strong leadership won't necessarily drive the business impact needed for growth or even sustainment.

This then is the crux. Leadership is essential for achieving business value. You can use Agile processes to seek business value, but without strong leadership you will find the criteria for success shifting too often and hiding behind the easy process of consensus building.

To bring this back to the Agile conversations, I was feeling frustration with the reactive nature of those who ascribe to the Agile approaches. They espouse this easy-going attitude of reaction in which direction, strategy, and even the definition of business value are left completely to the client. This zen-like state in which the Agile practitioner responds fluidly to the changing and ethereal nature of the client demands is unnatural and impractical. Business value is unlocked by making the hard choices, by understanding the elements of the business value and capability chain better than everyone else and leveraging that unfair advantage.

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself.
Therefore, all progress depends on the unreasonable man.
-- George Bernard Shaw

Simply put, it is called work because it IS hard. It's painful and requires discipline. If you are choosing to avoid the hard choices you are inevitably giving up the business advantages, wasting opportunities, and releasing accountability. Live in a reactive mode long enough and you remove the incentive to estimate well, to live up to commitments, and to deliver beyond expectations.

As everyone in technology knows, regardless of how long a task should take, it always takes at least as long as the plan said it should. We don't finish early, we just fill up the extra time with more stuff and junk. We test a little more, refine a little more, increase scope if necessary. If you aren't pushing the boundary and requiring unreasonable attainment, then you'll never get it either.

When it comes to Agile, I embrace the incremental nature. I covet the consensus of reactive expectations. I do not respect the reduced commitment to discipline, the minimization of leadership, or the dismissal of accountability afforded a facilitator. As Harry would say, "If you are going to come, come correct." Harry can be very wise.

Offshoring for Rank and File

I've been doing offshore work as long as the next guy, if the next guy has been doing it for almost a decade. There are successes and failures and lots of learning along the way. It's hardly the only thing I've done, but it's a good share of the pot.

Recently, I was asked to speak with some gents about how their offshore effort was going. Which is usually code for "We don't think it's going well". And by all accounts from the team, it wasn't going all that well. It helps when everyone at least starts from the level of dissatisfaction.

Whenever we start to talk about the concept of managing work efforts in more than one location, everyone spits out the same mantras. Communicate, be sensitive to cultural differences, etc. The thing is there aren't all that many that have moved past the theory into practical application. I should say demonstrably successful application. A big part of this shortcoming, from my perspective, has been that while we can have concepts in our heads like cultural differences, and detailed communication plans, we miss what can be the subtle point of these guidelines.

Let's borrow from a recent experience at Big Redmond Software Company. Companies (like Microsoft or Google) don't really run tight ships. Not in the way the unfamiliar would think. At the foundation, they expect individuals to be very self-sufficient and to work with minimal communication. Contributors are expected to bridge gaps in their own style. These companies are impactful because they have leveraged the ability to walk down the hall and say "Build this" while pointing to the contents of a Visio diagram or the corner of a whiteboard. The resources are expected to be accountable for the applicability and context of their solutions, not just the code or outputs they produce. The business value driving the work should naturally be taken into account by the self-reliant resources who are tasked with unlocking that capability.

When you start moving that work to different geographies and timezones, suddenly that level of communication isn't enough. The expectation on all parties is to minimize communication since that is a cost both parties share. But how they each tend to approach that goal is often different. Remember that the sender is expecting to point and grunt and have accountability and context magically shift. They'll be available for questions, they expect to review the progress and deliverables and throw stones along the way. But if it takes more than [insert arbitrary threshold here] energy and time commitment, then it just isn't working out. It would have been easier to do it myself in house.

Meanwhile, the receiver of the work has an expectation that the work will be fully-formed, coherent, and that they will not have significant decision-making requirements. Give me enough information up-front to be self-sufficient and yardstick with which to measure success. I'll come back when the output meets the success criteria. My accountability only extends to the output according to the specifications and acceptance criteria. If those have been ill-defined, that is the senders responsibility.

Obviously, I over simplify a little and as always YMMV. But in practice, understanding the different accountability and communication expectations we place on resources on different sides of a pond (or client-facing fence) will help you be more successful at leveraging offshore resources.

How "Open" Can It Be?

Something that has bothered me from the beginning of the Open Source movement (and I use the word very loosely) is the seeming hypocrisy of these commercial companies that have huge revenue streams based around the idea of Open Source software.

Not to go off on a rant here, but how open can they really be when they've got hundreds of people paying money for them to support their specific releases? To my mind the idea of Open Source was always that the source could and would be extended by the community at large. However if you are going to start asking people to pay for the specific versions of extensions that you are providing, you've essentially closed the system. At this point, it seems to me you aren't an Open Source contributor any more. You are someone who took an Open Source offering, tweaked it, and are now asking people to pay for your tweaks, thereby closing it. If you did this once, perhaps a point could be argued, but when you've been building on YOUR specific tweaks for release after release, and your support policies are version specific, then you are just like any other software company. Okay, perhaps there is a little more transparency into the code, but still.

” SANTA CLARA, CA January 16, 2008 Sun Microsystems, Inc. (NASDAQ: JAVA) today announced it has entered into a definitive agreement to acquire MySQL AB, an open source icon and developer of one of the world's fastest growing open source databases for approximately $1 billion in total consideration. The acquisition accelerates Sun's position in enterprise IT to now include the $15 billion database market. Today's announcement reaffirms Sun's position as the leading provider of platforms for the Web economy and its role as the largest commercial open source contributor.”
From: http://www.sun.com/aboutsun/pr/2008-01/sunflash.20080116.1.xml

Exactly how open to the inputs of Joe developer are they really going to be when they have to sustain a $15 billion dollar Support industry around these products. Do they really expect us to believe they are going to leave the evolution of these products to the average engineer? The community at large? Hell no. They have product teams and planners and release strategists just like every one else. They just don't have the huge upfront investment in research and development, they essentially jumpstarted their code from the masses. And they won't have a huge testing effort, they'll just rest on the backs of the industry at large. Which makes for good stability.

I hate to see such blatant parasitical behavior cowering behind the beauty that could be Open Source. Greedy bastards.

Running The Gauntlet

This week I had the chance to discuss using Team Foundation Server in a large team setting specifically as concerns Build and Deployment.

As I was organizing my thoughts to answer a question about check-in policies, merging and branching, and so forth and I kept coming back to my guiding principles:

• The Build is the build. There is only one Build.
  
• Build anywhere you like, as much as you like, but it only counts if it is in the Build.
  
• If it doesn't work in the Build, it doesn't work.
  

Now I am certainly familiar with having to manage simultaneous release schedules, juggling branches, and so forth, but that doesn't mean I like it. I absolutely support the mainline concept. Much like the Highlander, when it comes to the build, there can be only one.

We could argue that there are many techniques to allow these fancy behaviors but that doesn't make it okay. Just because you can do something, doesn't mean you should. Experience tells us that if you have a big team, you can't afford to have anyone interrupt the flow of the system. This includes breaking the build, causing failures of critical tests, etc. When more people or organizations are involved, the cost increases.

In the agile communities there is a push towards Continuous Integration (CI) which is really an attempt to implement the Only One Build concept as an ideal. When you can do it, you should. When the amount of code grows or the number of loose connections increases this can be cost-prohibitive, primarily in time. Compiling 1.8 million lines of code is going to take a little while regardless of how big the build machine might be. And when it comes to running Build Verification Tests, these problems are compounded. Especially if you are using disparate services that are loosely coupled.

The idea behind CI is to bring compilation and integration issues to the attention of the team as soon as possible thereby minimizing distribution. Going beyond that are tools that would actually test code entering the system before check-ins occur and reject or accept them based on the results. With TFS policies this is fairly straightforward to set up and an open source effort has begun to bring this to life. You can find out more about this effort at http://www.opengauntlet.org/.

If you prefer to wait until this functionality is built-in, you'll be glad to know that the next product release most likely will include a similar feature with a working title of "Gated Checkin".

I Need A New Phone

My friend has a cool Nokia with a 3 or 4 megapixel camera and it just puts my Dash to shame. Which means that now I'm in the market for a new phone.

Here are some things I care about in weighted order of importance:

1. 3+ megapixels
2. autofocus
3. windows mobile 5+
4. works on t-mobile
72. standard headphone jack
74. sd card slot
81. flash
89. gps

So any ideas?

Right now I am considering the HTC Touch Cruise and the HTC TyTN II. But I'd love to find some more options to choose from. Surely there are other choices?

Outlook 2007 on Vista accessing Exchange using HTTP over RPC

If that title didn't mean anything to you, ignore this post. (Well, you can click an advert on the right first! ;-)

Just recently I've updated my laptop to the latest Windows operating system release named Vista. Since I'm out in the field, I don't have a nice persistent connection to my corporate network and Exchange mailbox. After installing Office 2007 (which I'd been using for some time and can say is quite good!) I needed to get my email configured again. So I point and clicked everything as it was configured before. Alas, no joy.

After researching a bit online including a very poorly worded and far too succinct KB article (found here), I got it running again. I've listed the important steps below, skip them at your peril.

1. Open regedit or your other favorite registry editing tool.
   If this is unfamiliar go get your geeky computer friend to help. You can really screw things up playing in the registry, so only do this if you know what you are about.
   
   
2. Locate the following subkey:
   HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\RPC
   You might not have the RPC portion of the key. I didn't. Just create it if missing.
   
   
3. Add a new DWORD value named DefConnectOpts with a value of 0.
   You have to get the name correct, and make sure the value is set to zero.
   
   
4. Restart your machine.
   This is usually the first step I skip. You can't do it this time. It won't take effect until restart. There probably is a service or .dll that can just be unloaded, but what a hassle. Keep it simple and just reboot.
   
   
5. Delete the profile you had, and recreate it with valid settings.
   At this point it should let you login to your Exchange server via RPC over HTTP. If it didn't you probably skipped a step or hit that special "you're screwed" portion of code. Call your techie friend.
   
   

My default Vista install did not have the RPC portion of the above key. So, I just created the key, then added the new value. I first deleted the old profile, then rebooted the computer. I created a new profile and it worked. Your mileage may vary.

3 Pass Coding

Back in the day at Microsoft we used to look for and train developers who were 1 pass coders. In today's world everyone is a 3 pass coder and they are starting to drag me down with them.

Let me explain the difference between a 1 pass and a 3 pass coder.

When you are writing code there are several layers (or aspects) of design and implementation activity that have to be balanced. Firstly, you have the very simple, but often disputed, question of whether the code will meet a functional objective. This is often referred to Working. If the code won't perform the purpose the code is intended for it Doesn't Work and the rest of its qualities aren't relevant. Assuming that it can be made to fulfill its intended purpose (i.e. it Works), then the other two aspects suddenly become important.

The next most tangible aspect of coding is the speed at which the code will execute or process units of work, transactions, operations, etc. Regardless of the velocity or metrics implied, the measure of this aspect of coding is generally called Performance. Making something Work is the first step which is immediately followed by does it Work Fast.

Lastly you have a host of intangibles of varying degrees of importance. There can be many tangible expressions of these intangible attributes used by different people at different times. The number of comments, the readability of the control flow, the robustness of the error and state management, and the lack of logic or bounding bugs; are all examples and all of which are related. We put these closely-coupled items in a big bucket called Quality. This may also referred to as Maintainability, Elegance, etc. If you can make it Work, and make it Work Fast, can you make it Work Correctly?

Now when someone starts out coding, they generally are capable of keeping only one layer in their mind at a time. They start by making the code Work. They just want to see it do what they think it should do. Of course, once it does that, then they immediately concern themselves with making it Work Fast. It is about this time that consumers of their code start exercising the possibilities and uncovering flaws and boundaries of the code. So a review of code usually focused on specific bugs or concerns is undertaken until eventually it is determined the code must Work Correctly. This lifecycle usually involves 3 distinct reviews or Passes on the code. It is written, then reviewed for performance or capacity, then again for bugs and boundaries.

On the other hand, a 1 Pass coder will have such a clear picture in mind of the code, the control of flow, the logic loops, the impediments and enhancements to speed, the boundary conditions and bug potentials, that the exercise is compressed into a single Pass of coding. All the work is done upfront in the design and in the construction of each line so that intangibles are caught during the initial pass.

At least that's how we used to do it. It's how I used to do it.

Now engineers are so woefully under-skilled. They aren't forced to learn logic or bit math. They didn't take any classes on algorithm design or perform exercises on bug potentials. They just want to see it Work and then have testers tell them what else needs fixing. If you want it to Work Fast they just buy bigger boxes or more of them. The days of discipline are gone.

When I have to oversee their work or explain an implementation I find myself being forced to speak in terms of what it takes to make it Work because the other layers trip them up. If I show them tight, elegant code with robust error and state management and efficient control of flow, they can't read or follow it. When I assign bugs they want to debug and watch the code execute because they can't find the bugs by reading the code. I have to worry about losing my own skills just working alongside them.

Yesterday for a personal coding project I came across a bug running the program and my first thought was to set a breakpoint and see what happened. I wanted to slap myself out of the chair! I'm better than that. I can READ and understand code. Which doesn't mean I don't take advantage of the debugger, but it shouldn't be my first thought. I'm a 1 Pass coder and I intend to stay that way.

Eventual Correctness

Have you ever heard the term Directional Correctness or perhaps Directionally Correct? In the software business it is often used for when the concepts, functionality or usefulness of a thing is understood or apparent, even when there are details or bugs that prohibit full acceptance.

If you are building a form for the user to input data, having all the form elements and the submit button without any formatting, style, or validation would be considered Directionally Correct.

The process of building something new is often littered with the broken attempts and failed assertions. This is actually one of the driving motivations between Test Driven Development. Good designers use iterative processes to arrive at a great solution, it doesn't just magically appear. Great designers help those around them iterate also.

Have you ever looked back at the end of the day and realized you worked on the same design element the entire day? Have you ever had a user or consumer completely yank the carpet out from under you and realize that all the progress you made wasn't progress at all? A key reason this occurs is because we get too focused on the details too soon in the game. After all, the greatest engineers are perfectionists. It isn't done until it's Right. And that is what trips us up.

As engineers and designers we should foster or sense of elegance and perfection. Just not right away. We need to evolve our solutions, not magically produce them instantly. Produce something ambiguous and generic but somewhat functional. Or at least demonstrative of functionality. Get the users and consumers hand-waving in the general direction. Once you've achieved some agreement on the direction you are taking, then you can start hammering in nails and confirming details.

Besides being able to verify your work with consumers, it is important to delay details for your own benefit as well. The old Forest vs. Trees problems can impact even the most seasoned woodsman. As you implement your vision the details will reveal themselves. The gaps and holes will become obvious and you can address them with precision and prejudice. If you focus on details only after you have verified your directional correctness, they won't move or shift so you can be certain your specific solutions will serve.

It can be hard to iterate, especially with our innate desire for perfection. Iteration is like delayed gratification. You can make it perfect, it will be amazing and elegant. . .eventually.

Absorbing Change

Embracing change is something at which I am usually very adept.

Some might even say that is because I am responsible for most of the change that I see around me. At least on projects. But that isn't fair. I recognize as well as anyone the necessity to stabilize from time to time. To slow the pace at which change is being identified and absorbed into an organization. Many of the processes and much of the effort I exert is designed specifically to assist with the absorption of change; controlling the velocity that change impacts ongoing efforts.

Don't worry about design, if you listen to your code a good design will appear...Listen to the technical people. If they are complaining about the difficulty of making changes, then take such complaints seriously and give them time to fix things.
-- Martin Fowler

Sometimes large changes are required. It is natural for individual contributors to get invested in their work and become very attached to their specific deliverables or designs. To my mind, being flexible is a critical component of competence. Without adaptability, your useful as a contributor is minimized and in some cases suspect.

Going beyond the ability to handle change as someone customer-facing is the capability to influence both the speed at which change is introduced to the delivery organization and the expectations of the customers creating that change.

To be a good lead, protect the pace of change you expect from your people. To be a good consultant, manage expectations with your clients about the changes they want to introduce.

Dead Man Walking

Most software projects fail. The statistics are varied but a pretty fair sweeping generalization of all the research would indicate that most software projects fail.

If most of them fail, then it is logical to surmise that at any point you care to examine them, the majority will be dying. Sure, they might hang on. They might be fighting horribly and even look like they have a chance to succeed. But most of them fail. They die.

If you were out hiking in the woods and came upon a man mauled by a bear and he was shouting incomprehensibly and swearing like a sailor what would be your reaction? A helpful or trained person might run over and assess the situation. They would question and listen, they might possibly poke or prod. The answers might be meaningful or simply swearing or more realistically just Pain, Pain, Pain! The conversation would get more succinct, more direct. Answer me or I can't help you! Neither would stop to criticize poor grammar or discuss the appropriateness of language. They would listen to the content and contribute to the sharing of information. Presumably, they both want to save the dying man.

As the situation progresses, the person trying to assist the dying man would make decisions based on what they independently observe is hurting, by which movement brings the loudest screams, or by which open wound is bleeding most profusely. Because the priority of the situation demands it, they would ignore the swearing and the sweat and the blood. If the wounded soul gets out of control, they might sedate them if possible, or simply slap them to snap them back to reality and focus. Having been in similar situations, I can tell you there is shouting and flailing galore. The communication will be rough, it will be high velocity, and it will rarely be diplomatic or couched in rhetoric and hyperbole. After all, someone is dying.

If you are starting a new project, chances are it is already dying. Will you watch politely while it bleeds out? Will you bind the hands of those who can set the bones or knit the flesh? When a person with their hands in the gaping head wound says "Move!", don't demand they say Please. Remember, your project is dying.

We Have a Piper Down!

Yesterday I was attempting to customize my Flickr feed so that my Twitter posts would be more readable and I used Yahoo! Pipes to make it all happen.

The above buzzword-laden sentence is an example of flurry of intertwined concepts and technology that is rapidly becoming a cornerstone of my life. And I love it!

Yahoo! Pipes is very cool technology. A stunning example of driving adoption through value-added services that are intangibly monetized. (What a friggin' mouthful.) What I mean by that is that Yahoo! Is providing this service free of cost and what they are realizing is a slew of benefits that don't have direct immediate financial gains. The long-term gains of developer loyalty and driving adoption of their related services (Security, Mail, Blog, Reader, Calendar, etc.) will pay off in spades if they continue this trend.

During the early years of Windows there was the Win32 War. Some people thought 16-bit processing was better, others wanted 32-bit. Apple as a platform or Windows or OS2 or ? It became apparent that the way to win platform adoption was by having the most applications for that platform. You get the most applications by making it as easy as possible for developers to create those applications. This is the same today when the "platform" is a service you want used, and the "developer" is a consumer who points and clicks and publishes feeds.

The thing I found most intriguing about the Yahoo! Pipes offering is how easy they've made it to leverage all the outstanding work that others have created. Not only is there a massive wealth of capabilities directly in the tool, but the ability to clone other Pipes means the learning curve and information sharing is ridiculously easy. Whoever is running the show over there needs a serious raise, and a bigger budget. More of this and better press would put Yahoo! as a platform much more seriously in the running.

Don't Get Bullied

Building software for a crowd of generic consumers while challenging, operates by some reasonably straightforward rules that can be reasonably understood. For example, simpler is better.

On the other hand, building custom software for an educated user-base to fulfill specialized processing is excruciating because of the unreasonableness of it all.

The closer your users are to the problem, the more ideas they will have on HOW to solve the problem. This naturally leads to a slew of fragmented and disjointed concepts as they attempt to articulate in fits and starts their individual, informed, ideas about how the system should function.

At the other end of the spectrum, having educated and empowered users who will discourse with you about the nature of the problems to be solved, listening with open-minds to potential solutions, providing feedback to perfect the product, this can be hyper-productive.

We like to say, "They know enough to be dangerous."

When you have fragmented and disjoint components that don't subscribe to a cohesive approach to problem resolution you end up with lots of superfluous code that is usually much more complicated then it needs to be. Twice as much code doesn't make the solution twice as complex, more code adds exponential complexity.

This is not to say that you altering the end-goal for the functionality being delivered, you are changing HOW the software will meet the end-goal of functionality. When you subscribe to a cohesive vision, the product isn't just easier to create, it is simpler to test, quicker to validate, more robust in operation, faster to debug, and much easier for a user to adopt. The evidence supporting this is vast and varied across the technology landscape. The simpler answers always have broader adoption.

When you approaching an engagement, ask yourself what kind of user-base is supporting your efforts. Are they generic and uninformed? Keep it simple. Are they educated, pushy, and sure of their solution? Good luck with that (unless you can change the game). Are they empowered but open? Engage them early and often and you'll be really successful.

Is That Your Hand In My Pocket?

Yesterday we heard from our own news sources about a recent release from the US Justice Department about allowing fees for priority routing of internet traffic. Today, courtesy of the BBC, we see a simple restatement.

The US Justice Department has said that internet service providers should be allowed to charge for priority traffic.

The agency said it was opposed to "network neutrality", the idea that all data on the net is treated equally.
-- BBC News

Why can't our news ever spell anything out this simply?

What’s next? An Uber-Elite Network that’s much faster than the current one…oh wait, we already have I2…
Well how about a private network that you have to pay for higher bandwidth…oh wait, all the major carriers already do that…

Hmm…something is fishy about this, I just can’t quite put my finger on it.

Call me...ScrumMaster

So evidently know I'm a Certified ScrumMaster. Yay.

You have to attend a two-day course, which if you are lucky like I am, will be with your friends. During the course, you get to practice your Scrum skills and take turns beating on each other to reinforce the principles of competitive cooperation. It was a fantastic course.

Much of the course principles were things I already had lots of exposure to, but there were some neat techniques in the course delivery that I thought were really first rate. It has been some time since I was in the instructor seat and such a hands-on course was a good refresher for me. The instructor Michael James is a little zen, but did an excellent job modeling the behaviors for the class.

If you haven't taken a Scum course, I highly recommend the training. Even if you don't intend to follow an adaptive methodology, the teaming techniques can be reliably executed in almost any environment.

Social Networking Sites

Lately I've been watching a couple of social networks really take off. Mostly from the standpoint of how I might take advantage of their numbers for various professional reasons.

As I've been considering each of their unique perspectives, usage models, and participation, it was interesting to me how many of them really only thrive on a form of peer-pressure. They don't have to actually be valuable in and of themselves. You simply get sucked in because someone you know dragged you into it via their email address book.

Obviously someone must be finding value in these services or they wouldn't thrive. But how much energy are those who really find the services rewarding putting into them? Is this just another avenue for someone who already spends significant effort? Or does it help even the generally anti-social to become more social?

Have you been one of those lurkers who doesn't participate? You join and then forget about it. Were you at one time? What prompted your activity? Did you one day recognize some value, or have one of the sites serve some need? Did that create a turning point for you?

I can't help but think that these services are only as good as the value that individuals put into them. But then empirical evidence counters that the case must be different. Otherwise, how would any peer-to-peer technology ever take off? Surely even the sum of a bunch of lurkers must provide some value. And every time a lurker becomes involved, even if only marginally, that must increase the value of the system in a meaningful way.

Now I have to go research this. Anyone have answers they give to save me some reading?

DSL Factory Utilities

Lately, my team has been doing quite a bit of work using the DSL Toolkit. It has been quite a grind, but we've developed some pretty cool abilities.

Now I find that we weren't the only ones struggling and that help is on the way for the guys who start on this path next. Thanks for coming to the party guys!

The dslfactory community posted some great stuff on codeplex: http://www.codeplex.com/DslFactoryUtilities

If you are working with the DSL Toolkit even a little, you should check this out.

Microsoft eScrum

It was a quiet release, but Microsoft released a new offering in the Agile space built on Microsoft Team Foundation Server. Here is what the release says:

eScrum is a Web-based, end-to-end project management tool for Scrum built on the Microsoft Visual Studio Team Foundation Server platform. It provides multiple ways to interact with your Scrum project: eScrum Web-based UI, Team Explorer, and Excel or Project, via Team Foundation Office Integration. In addition, it provides a single place for all Scrum artifacts such as product backlog, sprint backlog, task management, retrospective, and reports with built-in context sensitive help.

You can download it here.

Looks like things are heating up!

Sharing Agile

In the spirit of sharing, today's post is some reading suggestions for all you agile developers out there. If you are serious about becoming more agile in your development, here are some books you should absorb:

	Agile Software Development by Alistair Cockburn
	Agile Project Management with Scrum by Ken Schwaber
	Agile and Iterative Development by Craig Larman
	Extreme Programming Explained by Kent Beck and Cynthia Andres

When you've finished with that, shoot me an email and we'll move on to real-world examples.