This past Wednesday at the Great Lakes Area .NET User Group I had an opportunity to listen to Brian Prince (Architech Evangelist from Microsoft) speak about agile development practices. The following are just a few of the concepts that were covered on the topic.

Stand Up Meetings

Every day at a set time get together with your team and meet for anywhere from 10-15 minutes. The time limit is important to adhere to no matter how large or small your team is and keeps the meeting flowing and on topic. Take long discussions offline after the meeting so that you won't be taking up other people's time. Use some type of object as your speaking token and only the person with the token gets to talk. This token can be anything you want and gets passed around the entire team. It's encouraged that everyone is standing during this time, which besides the fact that its called a "stand up" meeting, I would imagine that it also keeps people from getting too comfortable and extending the meeting time longer than it should be.

Usually the stand up meetings covered these three things:

1. Talk about what you did yesterday.
   
2. What you plan on doing today.
   
3. Anything holding you up
   

The "Moscow" rule

Moscow, which stands for Must O Should Could O Wont, is used to give your tasks prioritization. The client plays a big role in this as they will be constantly prioritizing the tasks regularly based on their needs. Try to think of the Moscow rule as a series of containers. The rule of thumb here is to have your client put as many tasks in the "won't" section as they want and then divide the rest of the tasks evenly into "must", "should" and "could". By practicing this you have a clearer picture of what types of things that people should be working on for each given iteration without allowing the client to have every feature assigned to the "must" container.

The Iron Triangle

The Iron Triangle is a way to visualize each aspect of a project and how it affects the other. By emphasizing any two areas from the triangle you will be taking away from the one remaining piece. Interestingly enough, where is the "Quality" piece of the triangle?

Not all rules of agile must be adhered to, use what works and forget what doesn't. It can take upwards to a year or two in some cases for your team to fully embrace and acquire the benefits of practicing agile development.

Source:
http://businessagile.blogspot.com/2005/02/breaking-iron-triangle-project-manager.html

After doing a little searching I found an excellent (and FREE) visual voice mail service called YouMail. Upon signing up I discover that my beloved carrier wants to charge a fee of 20 cents a minute to forward unanswered calls to another number (including YouMail). This is something that other carriers offer at no change! Whats the deal Sprint??

Now I don't get a tremendous amount of voice mails so its something I can live without, but I can't fathom why it would mean charging for the service given that other carriers do not.

</end rant>

[UPDATE]

I've just sent a request to be invited to the Google Voice phone service. An update will surely follow about my experiences.

Everything in Scrum...

• is a time box (aka sprint), so things don't go on forever
• is done with cross functional teams who don't need to be managed
• has a constrained team size ( under 8 people )
• has to achieve some form of a shippable product at the end of each time box / sprint
• assumes that you are intelligent enough to come up with a solution to the problem at hand
• requires minimal or no interruptions while sprinting

Additional points

• Scrum goes hand in hand with Extreme Programming practices.
• Working more hours does not equal better code quality. Code will likely become exponentially worse as a result of quick fixes and ideas that haven't been adequately thought through. The cost to fix these issues even outweigh the cost that would have been saved by keeping normal work hours. As a result, overworking is not a good way to increase project velocity.
• Unexpected features can harm project velocity in such a way that if not adjusted in time for quality control will cause future iterations to gradually worsen as you build upon a flawed code base. This continues until eventually you have a "design dead" product.
• Over 65% of all functionality that is delivered (which must be maintained) is rarely or never used.
• 35% of all requirements change during the life of a project.
• Using a prioritized list of features, overtime the items will begin to loose value and at some point the time may be better spent elsewhere.

Resources

The Innovators Delima
Scrumalliance.org

Microsoft Silverlight 2: Control Model
http://channel9.msdn.com/pdc2008/PC29/

Styling a Silverlight based Twitter application with Expression Blend 2
http://channel9.msdn.com/posts/Dan/Celso-Gomes-Styling-a-Silverlight-based-Twitter-application-with-Expression-Blend-2/

Helpful Links:

• Snoop (WPF Debugging utility)
• Nibbles Tutorials (Redesigned silverlight site by Celso Gomez)

"Since 1991, the Professional Developers Conference (PDC) has been Microsoft’s premier gathering of leading-edge developers and architects. Attend the PDC to understand the future of the Microsoft platform and to exchange ideas with fellow professionals. You’ll learn about upcoming products, meet Microsoft’s leaders and top engineers, write some code, and be inspired! Unplug for a few days and think about the future."

ASP.NET 4.0 Roadmap
http://channel9.msdn.com/pdc2008/PC20/

ASP.NET and JQuery
http://channel9.msdn.com/pdc2008/PC31/

Microsoft Visual Studio: Web Development Futures
http://channel9.msdn.com/pdc2008/TL48/

ASP.NET MVC: A New Framework for Building Web Applications
http://channel9.msdn.com/pdc2008/PC21/

Its almost been a week now since Google's new Chrome browser has been released to the public and from what I've been seeing, the response has been overwhelmingly good. While its too soon to tell how much adoption the new browser will have especially to your average web user, if this past week is any indication of this then we may have one serious contender on our hands.

The idea behind the new browser was Google's acknowledgment of how much time we spend online conducting our daily business, whether it be online banking or sending email. Sites are being developed now that are capable of performing much more complex tasks than we would have ever imagined 15 years ago when web browser were first introduced. This realization has given way to finding a better browser architecture capable of dealing with the high demands of sites such as online word processors, airfare booking, maps and many other types rich internet applications.

So I guess the more important question is should you be using Chrome in its current development state? Do you like to jump in feet first and test the waters with a whole new experience? Are you not concerned with bugs, incompatibilities or worse.. potential security holes? Then by all means, this is your browser. Now don't get me wrong, this isn't trying to imply that there is anything wrong with treading new ground and pushing new technology. For myself though, I'll be mostly using Chrome as a fun new toy to experiment with rather than migrating over entirely. What I'm really interested in seeing is what will come out of the open source community that is actively working on the browsers core which I believe in time that we will see great things come out of the chromium project which powers Chrome. While there is no certainty that Google Chrome itself will come out on top when its all said and done, but there is no denying that it will be known as the browser that was at the forefront of a new undertaking in how we think about today's web applications.

Pros:
Introduces a new way of thinking about how browsers work
Innovate way of handling complex websites with V8 JavaScript rendering engine (complied)
The UI is simplistic (the browser should be transparent)
Everything is open source!

Cons:
Google is a company that is best known for it's services NOT it's software.
The UI is simplistic (I miss having my firefox plugins at my disposal)
As if web developers need one more browser to test on
Too early to tell its adoption rate

This first solution has stood the test of time and is known as the clearfix method. This technique uses the :after pseudo-element which is supported by CSS2 compatible browsers. Unfortunately, this doesn't include Internet Explorer 7 and below. You may notice that there is actually two style blocks for our CSS and that is because we are using conditional comments that will target any Internet Explorer browser and use the proprietary hasLayout CSS attribute that must be commented or else your page will not validate.

<style type="text/css">

  .clearfix:after {
    content: ".";
    display: block;
    height: 0;
    clear: both;
    visibility: hidden;
    }

</style><!-- main stylesheet ends, CC with new stylesheet below... -->

<!--[if IE]>
<style type="text/css">
  .clearfix {
    zoom: 1;     /* triggers hasLayout */
    }  /* Only IE can see inside the conditional comment
    and read this CSS rule. Don't ever use a normal HTML
    comment inside the CC or it will close prematurely. */
</style>
<![endif]-->

View Example #1

Another method uses an additional <div> element on the page with a style of "clear:both" which will force your container to accommodate the cleared element. While just as effective as any of the other methods, there is the concern of adding additional "meaningless" markup to your pages.

<div id="outer">
    ....
    <div style="clear: both;"></div>
</div>

View Example #2

Finally there is a relatively newly discovered technique which is quite easy to implement and is one which doesn't require additional markup. It simply involves adding a "overflow: auto" property to the outer <div> element.

Half an hour of testing later, I was amazed to find Paul was 100% correct - as this example shows. It seems that reminding the outer <div> that it’s overflow is set to ‘auto’, forces it to think "oh yeah.. I’m wrapping that thing, aren’t I?".

-Alex Walker, sitepoint.com

View Example #3

So there you have it, three different techniques that will help you clear all of those pesky float issues.

The form results are displayed to you in a nice pie chart. The actual data is output into a spreadsheet behind the scenes if you need to use it for any other reason which is a nice touch as well.

An alternative service that I also recommend is called WuFoo. This service is free to try and allows for further customization of your web forms. I kid you not when I say that seemingly everything that you could ever want is included with this service such as phone number and date fields which include custom validation messages built in. There is a monthly fee as your usage increases however.

For me personally, Google Docs does just fine for my needs. Feel free to give your ice cream preference if you'd like to try out a sample form.

We'll first start out with some html markup, notice the lack of css class attributes or JavaScript event handlers present.

<fieldset>
	<legend>Log In</legend>
	<p id="loginResult">Invalid login.. try again.</p>
	<form id="login" method="post">
		<dl>
			<dt><label for="username">Username:</label></dt>
			<dd><input id="username" type="text" /></dd>
			<dt><label for="password">Password:</label></dt>
			<dd><input id="password" type="text" /></dd>
		</dl>
		<p><input type="submit" value="Login" /></p>
	</form>
	<small>u:username / p:password</small>
</fieldset>

The next step we take is to target each element down the list and assign it a css class. We do this by using jQuery's element specific selectors :text and :submit.

	$(function(){
		$('form#login :text').addClass('inputTextbox');
		$('form#login :submit').addClass('inputSubmitBtn');
	});

Next, we'll add the event handler for the submit button by using .click(). To make things easier on ourselves we could always shorten our code by chaining the click event at the end of our submit button selector which was already defined in the previous step.

$('form#login :submit').addClass('inputSubmitBtn').click(function() {
     // click event code
}

Throw in an animation for good measure to display a message for invalid attempts and you're good to go. Here is the full JavaScript code we're working with.

		$(function(){
			$('form#login :text').addClass('inputTextbox');
			$('form#login :submit').addClass('inputSubmitBtn').click(function(){
				if($('#username').val() != "username" || $('#password').val() != "password")
				{
					for(i=0;i<5;i++)
						$("#loginResult").animate({opacity: 'toggle'}, 500 );	

					$("#loginResult").fadeIn(500);
					return false;
				};
			});
	    });