FiOS vs Comcast in Kirkland WA

Naturally, after my last post about switching from Comcast to FiOS I should tell you which one is better. See for yourself:

FiOS from Frontier for ~$69.99 /mo

Comcast for $64.95

I have run many speed tests with both services over the last couple weeks. I would say these are pretty representative of the average speed test results. As you can see the big difference is in upload speed. Everything else is pretty much the same.

I don't have the fastest available service from either - Comcast tells me the speed is 15Mb/s down and 4Mb/s up. Frontier FiOS tells me my speed is 25Mb/s down and 25Mb/s up. Comcast apparently sells a 50Mb/s down and "up to" 10MB/s up for $99.95/mo. Frontier FiOS offers 50Mb/s down and 20Mb/s down for $139.95.

Bandwidth Caps

Yeah, I didn't use comcast much lately :)

Comcast shows you explicitly your cap is 250GB per month on your account page. More than that and as I understand it, they cut you off.

FiOS doesn't mention it anywhere, and according to many FiOS users who monitor their staggering Internet usage apparently FiOS has no bandwidth cap.

Fiber to My Home with Verizon/Frontier FiOS

Since I cannot post a reply to the How-to: make ActionTec MI424-WR a network bridge thread on dslreports.com I decided I should at least write the info down here for others.

A Free Router! Yea!
Verizon FiOS (now Frontier FiOS in Seattle Washington area) brings out a wireless router when they come out to install. They first install an Optical Network Terminal (what you'll read referred to as an "ONT", described by dslreports more here) which is a surprisingly large box for the Fiber from the street to go directly into. Out of this they will run a coaxial cable into their own router. The router in my case (and many others according to my reading) is a Actiontec MI424WR. It is a really nice router actually. It has 802.11g Wireless, DHCP, NAT, port forwarding, DynamicDNS, a flexible firewall and more. In short, Verizon/Frontier did a nice job in selecting the router. It's good.

Fiber from the street waiting for the tech to arrive

Except Geeks are Difficult
However, for us geeks we don't like someone else's router on our networks. We have our own stuff and don't ask why we can't use your router - we can't explain it, it just won't do. So the previously mentioned article explains how to put the Verizon/Frontier router into Bridge mode so you can use your own router instead. However, it is a damn shame because now you have this other router (now a bridge) that all those electrons have to jump through and that sucks more electricity all the time to run for absolutely no reason - since your own router does all the same stuff.

First of all, I am pretty sure that the DaDragon's explanation will work fine. I meticulously read the manual and scoured the settings of the Actiontec router and it should work fine. However, I found it is surprisingly easy to get ethernet directly out of the ONT working with my own router. Basically just called Frontier and asked for it.

The ONT

I called and got some unpleasent person that was adamant that I couldn't use my own router and only their router would work. I explained that this was hard for me to believe, and if this really is the case, I don't want FiOS at all. He eventually was willing -but whining and not happy- to call a "network technician" and ask if there were any options. Luckily the "network technician" was smart and told him that what I wanted to do was perfectly fine. All I had to do was power-down and unplug the Frontier/Verizon router and hook my router up to the ethernet port inside the ONT. Then the network tech at Verizon/Frontier could remotely switch the ONT's ports from coax to ethernet.

I did this and everything immediately started working fine with my router. I did take the liberty of releasing the IP from DHCP on the Actiontec router before I unplugged it, so maybe this helped.

Now I will return the Actiontec router to Frontier/Verizon and I have one less box in utility room and its all my own geek equipment so I can rest easily now :)



P.S. I called Frontier and they didn't want the router back. They just said it was completely free and I could keep it. Cool.

Now for some Nostalgia: The Original Flyer for ActiveReports

Although we've been living in the Seattle area for about a year now, we left all of our stuff in Columbus. We literally threw what we could fit in our car and drove here in a mad rush to attend the first day of our Software Product Management class at the University of Washington. We had no where to go but a hotel, and only essential items we could fit in the car (uh, you know, laptops :)). It was a bit hectic, but I totally recommend that everyone do that. We've loved it and wouldn't change the journey one bit.

We decided to stay, so we've even settled in to a house here now. Just a couple weeks ago received our stuff shipped from Columbus. So we've been going through boxes and unpacking lately. One of the interesting things I found was the original flyer we created for the initial release of ActiveReports back in 1998.

I scanned it for fun and put it up here. This was the early days of Data Dynamics, if we had a garage it would have literally been the quintessential two and a half men in a garage (the half is me). We were working day and night, did everything between the two-and-a-half of us. From coding, documentation, testing, support, and marketing and flyers like this one:

Front cover of the original four-page ActiveReports flyer

Inside-left page

Inside-right page

Back page

Those were the days.
Ferhat had been writing the first versions of ActiveBar and ActiveReports nearly single-handedly while Issam and tested. I dealt with support and a bit of documentation and Issam did everything else. Tim Moffatt worked with us hand dealt with nearly everything business to make sure our lights were kept on and talking to the normal people :)

We were working extra hard at this time because we were preparing to release both ActiveReports and ActiveBar for VBITS 1998.


Incidentally, I went looking for a good link about VBITS and found some pictures from those days. You should definitely check them out. It was when Issam's hair was black, I was a hippy with hair on sholders, and Scoble was - well, he was pretty much the same, but I bet his kid was a lot smaller. Carl Franklin was the same too :) Funny that you can see Ferhat holding a picture of this very flyer. The bus trip we took to Yosemite with Scoble,  Carl Franklin and friends that year was awesome. Definitely unforgettable, and I'm glad someone kept pictures around! Thanks to whoever did that (leave me a comment if you read this).

I remember a particularly funny story as we were getting up to the final stretch with ActiveReports. At the last minute, we realized it didn't print. We just hadn't tested printing in a long time.

Luckily it was an easy fix (or so Ferhat's incredible skills made it seem) and it was working in no time, but a funny thing we used to laugh about, especially considering we were originally going to call the product "ActivePrint" :)

That was a long time ago, and particularly rewarding since both of those two products are still used by thousands of people more than ten years later today. ActiveReports is going stronger than ever now at GrapeCity and I'm glad to be working with some of my old Data Dynamics comrades there.

Wait until you see what we have in store next for ActiveReports. I promise you a big surprise and another "Next Generation" in reporting!

Changes in The Text

While studying in preparation for the entering the textual criticism of the Bible program at Bob Jones University, the speaker, Yusha Evans, read the bible 6-7 times straight through and in Hebrew and Greek. In this YouTube video he is speaking about his experience reading beyond the four canonical gospels of the New Testament and making it into the writings of Paul:

Not only did I notice changes in the text, but changes in the way the language was spoken. Because you can tell in...in hebrew when God is speaking, because it is an extremely eloquent speech. A speech that is not like any human speech. You can tell the difference. And then you can see when it automatically changes to almost like slang. It changes to like, uneducated speech. And it goes back and forth, back and forth... and you can see this. Someone who knows languages will see this, you can see this. It's like having a person with a PhD in English speaking and when a fourth grader is speaking. You can tell which one is which. Even if they were behind a screen and they wrote it on a piece of paper. You would tell which one is which.

Grammar Tip: Punctuation with Interjections

Every once in a while I obsess over grammatical correctness in some particular situation. Today I learned the following:

The position of the exclamation point is determined by the way the sentence is read: if the voice falls after the interjection, the exclamation point is used there; if there is a pause but no fall of the voice after the interjection, a comma is used there and the exclamation point comes at the end of the sentence.

- http://books.google.com/books?id=xPUAAAAAYAAJ&pg=PA291#v=onepage&q&f=false

Should we row harder?

Microsoft and IBM were in a boat race with nine people in each boat. Microsoft had eight people rowing and one person steering. IBM had one person rowing and eight people steering. After losing the race by a wide margin, IBM commissioned a three-month, two million dollar study to determine how they could win the next race. After extending the study to six months and five million dollars, they finally came to a conclusion: the one person doing the rowing needs to row harder.

- story circulated at Microsoft after the OS/2 debacle ended.

Techniques for a Product Manager in Scrum: Estimating Techniques

This article continues my series of articles on a Product Manager's role in Scrum that began with The Role of a Scrum Product Owner which was followed with Responsibilities of a Product Manager in Scrum. This time I'm discussing Estimating Techniques.


When talking about estimating techniques in the context of scrum you'll hear a variety of interesting things come up, like: "We want to estimate product backlog items in T-Shirt sizes!" Or "We want to estimate product backlog items in points!" Or maybe you've heard, "For estimating, we're going to start playing planning poker." You think to yourself: What are these guys smoking?

But, actually everything is perfectly normal. When us software engineers estimate in hours or days they're wrong anyway, so why not estimate in T-Shirt sizes, points, or with card games?

Bare with me here... I've worked with teams that used all of these things, and I think they're all equally successful or unsuccessful and at least as good as estimating in hours. The idea here is to not get too attached to terms that have powerful associations with them like hours and days. In the end, it doesn't matter if they use hours or T-Shirt Sizes. You just need a way to measure the team's velocity.

Velocity
To measure in velocity, you have the team attach some "value" to each product backlog item (e.g. points). Then each sprint, the team will accomplish a few product backlog items and you can add that value up to see how much "value" (e.g. points) they were able to accomplish. After several sprints, you should start to see that the team fairly consistently accomplishes roughly the same amount of "value" (e.g. points) each sprint. So for your scheduling, you can use the average amount of "value" that the team can accomplish in a sprint, to determine how many sprints it will take to accomplish all of the items in the product backlog.

A great way to get started this style of estimating is with Planning Poker. There is a great site dedicated to that at http://www.planningpoker.com so I'll let you get into the details on that site.

Some quick rules of thumb I've learned:

• Early in a project, estimating in sprints. The cost here is limited of accuracy (usually due to the cone of uncertainty). 
• Use a rough order of magnitude estimate when providing estimates to others.
• If an estimate for a product backlog item comes out “big”, work with the team to break it down into smaller ones.
• Planning poker is effective and fast for teams that are hesitant to provide estimates.
• If everyone is rolling their eyes, use hours (and track everything so you can track velocity to get more accurate over time).

Series: This article is part of a series that includes the following articles: The Role of a Scrum Product Owner, Responsibilities of a Product Manager in Scrum, Techniques for a Product Manager in Scrum: User Stories, Techniques for a Product Manager in Scrum: Estimating Techniques.

Techniques for a Product Manager in Scrum: User Stories

This article will continue the series that began with The Role of a Scrum Product Owner which was followed with Responsibilities of a Product Manager in Scrum. In the last article, I outlined three areas of responsibility for a Product Manager working with a Scrum team:

1. Business Value
2. Be Available
3. Set Expectations

In this article we'll look at a few tools and techniques I've found useful for aspiring to achieve these laudable goals.

Product Backlog
Before we get into the main event for this article, I want to quickly give some homage to the product backlog. What the product backlog is is straightforward enough (read about it in the first article). However, as I stated in Responsibilities of a Product Manager in Scrum, it is an incredibly powerful tool in scrum. It is your primary way for ensuring that the team is working on the right things. So own the product backlog and always make sure it is up to date and product backlog items are clearly explained. Every time you add a new item to the product backlog get some feedback and reaction from the team and make sure it is clear for them. I've found that it often isn't, and needs some added explanation. So get out in front and be proactive about clearing up any confusion.

User Stories
Now for the main event... User stories are a way of writing an item for the product backlog. They are always written as follows:

As a <type of user>, I want <some goal> so that <some reason>.

You fill in <type of user>, <some goal>, and <some reason>. That's it. Once you've done that you have a user story. Not much of a story you say, but I say: Au contraire, mon frère...

A user story puts incredibly important information into a very small amount of space and it does it with a simple pattern. The important information that a user story includes is answers to common questions when considering a feature:

• Who benefits?
• Why would they want that?!

More importantly it makes the reader (developers and QA engineers) identify with the customer's need. Just for a brief moment, they have to acknowledge the perspective of the customer. Priceless.

Lets look at a quick example: You might find the following in a product backlog:

Add password to backups

Written as a user story, it might be written like:

As a Dad, I want to make sure my kids can’t delete my backups so that I don’t loose important docs!

As you can see, user stores are a painfully simple tool that are also useful. However, often times people don't like them because they're so monotonous to read. If you can get over the tediousness of reading them, they are are including incredibly invaluable information into a simple sentence. However, if you (or your team) doesn't like user stories, fine, just make sure that this other information is included in a template. So instead of writing:

As a <type of user>, I want <some goal> so that <some reason>.

You will write something more like:

User / Role / Actor:
<type of user>... 

Goal:
<some goal>...

Why is it a Goal for the User?:
<some reason>...

Some people prefer templated forms to fill out, and that is fine. I like user stories because I have found that forms tend to get wordy since people want to fill them out "correctly" and use more words to show how hard they're working. Then more "required" fields get added to the template so that everyone's stroke of insight about requirements can be memorialized and eventually the forms loose their value and nobody really wants to read them anymore anyway.

So I prefer user stories, and if needed -and it usually is- I back them up with a link to a requirements page, but I think cramming all that invaluable information into a single sentence is a great way to start.


Next week at this time I've got a fun article on estimating techniques prepared for you.


Series: This article is part of a series that includes the following articles: The Role of a Scrum Product Owner, Responsibilities of a Product Manager in Scrum, Techniques for a Product Manager in Scrum: User Stories, Techniques for a Product Manager in Scrum: Estimating Techniques.

Responsibilities of a Product Manager in Scrum

Recently, I wrote an article on the The Role of a Scrum Product Owner which was a crash course introduction to software development with a Scrum team. This article will go on to discusses the responsibilities of a Product Manager working with a Scrum team. If you haven't read the first one (and you're not a ScrumMaster) you probably should probably at least skim through it.

Update: I have received some comments about my usage of Product Owner and Product Manager. From my perspective, a Product Owner is a Scrum-specific term for the more broadly used term Product Manager. So I will tend to use the two terms interchangeably in these articles. However, it is fair to say that the responsibilities of a Product Owner are limited in scope compared to that of the typical Product Manager, as a Product Manager is usually responsible for a product's business case, marketing, competitive analysis, etc. These things are simply outside the scope of development and where Scrum is typically applied. To make a long story short, if you are currently called a Product Manager and will be moving to work with a Scrum team, they might start referring to you as a Product Owner.

I think Scrum is truly all about the underlying principles. The ceremonies, roles, and artifacts are all nearly useless and often even counter-productive without an understanding of and discipline around the principles of Scrum that I outlined in my prior article. My "Principles of Scrum" are as follows:

• Transparency: You should have problems when using Scrum ("that's a feature, not a bug").
• Inspection: You cannot inspect without transparency.
• Adaption: You cannot adapt if you do not inspect.

As a Product Manager, you'll need to understand and embrace these principles for a Scrum project to be successful. Even if you find scrum tedious or a little too informal, then at least try to keep in mind that these are the core tenets that should always be honored embraced. If you embrace them, your chances of success as a Product Manager or Product Owner -and as a team- increase dramatically.




Business Value
As you know, scrum teams work in short, rapid, iterations -"Sprints"- at the end of which the team demonstrates some useful functionality to the customer (or customer representative). The team does this by working on the highest priority items from the Product Backlog. This way the team is always working on the functionality that is the most important to the customer. In other words, the team is always working on the most valuable functionality: Business Value.

However, this assumes that the product backlog is always prioritized accordingly. The Product Owner has the exclusive responsibility for always keeping the product backlog prioritized. If Product Owner does a good job of prioritizing, the team will deliver features that have the highest value to the customer. If the backlog is not well prioritized, the team's work is in vain and the customer gets little or no value. Therefore, the importance of this responsibility canot be overstated.

Be Available

from freefoto.com

Scrum does not prevent questions from coming up or limit the need for reviews and feedback from the Product Manager. However, as scrum teams work in short iterations, time is always of the essence. So it is essential that when the team has a question or needs some guidance that the Product Owner is available to provide that guidance or feedback rapidly. 


To add a little bit of perspective: If a team works in a two-week iteration with one day of planning, that means if the PM takes one day to respond to a blocking-question from the team, the team looses 11% of their available time to their commitment. So be available!



Set Expectations
The Product Owner is the link between what customers want and what the team delivers. As such, the Product Owner is responsible for managing the expectations of both the customer and the team. Make sure that the customer is always informed and aware of what they will see at the end of the sprint. Never leave an unpleasant surprise lingering. Customers are generally understanding about delays if they know about them up front and are offered a chance to be involved with the team. But if a big surprise comes up at the end, they're less like to be understanding.

What is maybe less intuitive is that you also are responsible for making sure that the team's expectations are aligned with the customers. This is a Product Owner's fundamental role: Making sure that the team understands the expectations of the customer. Lets read that again for emphasis: Making sure that the team understands the expectations of the customer.

Be sure that the team understands the customers needs and ultimately what they are expecting to be delivered. Work closely with the team in setting a clear unambiguous commitment to be achieved at the end of every sprint. This commitment is to ensure that what the team delivers at the end of every sprint is what you -and by association the customer- is expecting.

So how do I do all that?

There is no easy way, and no doubt, after >10 years of development and several years of team leadership roles, I'm still learning myself. However, I have observed some useful techniques and practices and I've already started writing those up for an article next week. So stay tuned...


Series: This article is part of a series that includes the following articles: The Role of a Scrum Product Owner, Responsibilities of a Product Manager in Scrum, Techniques for a Product Manager in Scrum: User Stories, Techniques for a Product Manager in Scrum: Estimating Techniques.

United States Deficit & Debt During Presidents from 1969-2019

What is the difference between the Deficit and Debt you ask? Wikipedia and the U.S. Department of the Treasury have good explanations.

At times my curiosity will get the best of me and I start trolling through the glorious amount of data available on the Internet. A while back I started using the awesome data published by the United States Congressional Budget Office to better understand the US Deficit and US Debt during the different presidential terms in recent history. I managed to coerce the data into a useful chart that satisfied my curiosity:

USA CBO Deficit & Debt Since 1969, Projections through 2019

The top chart is the deficit and the bottom one is Debt held by the public. All numbers are expressed as a percentage of GDP as this seems to be the only meaningful value over time. As the legend shows the dark blue line is actual and the light blue line is projections.
The actual data comes from the Congressional Budget Office Historical Budget Data report revised on June 23, 2009 and can be found at http://www.cbo.gov/budget/historical.shtml. The projections data comes from "The Budget and Economic Outlook: An Update published in August 2009. It can be found at http://www.cbo.gov/Spreadsheets.shtml.

All of this was done as a spreadsheet in Apple Numbers '09. The spreadsheet with the raw data and the chart can be downloaded by anyone here.

Fixing the Google Buzz Feeds

Buzz to Twitter is...
Recently I showed you how to find your feed for Google Buzz and integrate it into FreindFeed. This allows you and your friends to see your Google Buzz posts on FriendFeed, and since FriendFeed will automatically push your updates out to twitter it gives you a way to make your Buzz posts show up in Twitter.

Cool but...
That all sounds good, but the problem is the feed from Google Buzz stinks. Every post has a title with something like "Buzz by Scott Willeke from Mobile" or "Buzz by Scott Willeke from Google Reader". So you see this in your feed over and over. Nice huh? Yeah, I didn't think so either.

Yahoo Pipes Makes it Better

So I've Used the venerable Yahoo Pipes to clean this mess up for all of us. Yahoo pipes is a visual environment that makes it easy to mashup information from web pages, and is really useful to modify RSS/Atom feeds. To use it just visit http://pipes.yahoo.com/activescott/googlebuzzfeed and enter the URL to your Google profile page (see this page for help finding your Google Profile Page URL). It will return a feed that you can click on "Get as RSS" and get a magically cleaned up Google Buzz feed.

Now, right-click on the link and copy it. Then enter that URL in FriendFeed (see friendfeed's help on this) and it will send much more cleanly formatted feed to FriendFeed and Twitter.

How does it work? Well go see for yourself. Yahoo Pipes are open source by default so you can go view the pipe and see how it works and even clone a copy to play with for yourself. Cool!

Publish your Google Buzz Posts to Twitter with FriendFeed

Visit your google profile page (e.g. mine is http://www.google.com/profiles/activescott) and view the source. You'll find a "link" element like so:

<link rel="alternate" type="application/atom+xml" href="http://buzz.googleapis.com/feeds/YOUR GOOGLE BUZZ ID/public/posted">

Take the url you find there in the href and add it to friendfeed as one of your services using the "Custom RSS" service (see friendfeed's help).
Then go to your friendfeed settings and make sure you are publishing your google buzz service entries to twitter. See this friendfeed help article for info on how to do that.

Now post to google buzz and watch your posts end up in twitter!

The Role of a Scrum Product Owner (and an Introduction to Scrum)

Introduction to the Introduction

Many of you know that I am currently a student at the University of Washington in The Software Product Management program. Overall the program is very good. My wife and I are both in the program and we chose to move from Columbus Ohio to Seattle Washington to take the course because of its special focus. Its special focus is on the specialized field of Product Management and going further it is focused on Product Management of software products.
However, it is not narrow in scope, as we cover everything from recognizing successful ideas for products, to marketing (lots of marketing), to detailed business cases (one former alumni who holds an MBA said this course is basically a “mini MBA”), to project management and of course extensive detail on requirements. I could write much more about details of the program, and for now we’ll start with one small part of it.
Recently, I was asked to do a presentation on the Product Owner role in the Scrum framework. Based on feedback from the audience the presentation went well. They are all much nicer than me though, so maybe they’re being polite. I’ll count on my fellow opinionated Internet friends to give me an honest assessment. Please do.
So, with this pedantic introduction to a topic that has many other informative and experienced authorities that I stand on the shoulders of, lets get into my first article on The Role of a Scrum Product Owner.

Before we Begin: What’s the deal with Pigs & Chickens?

Before we can discuss Scrum we need to cover the deal with pigs and chickens. If you read much of anything about scrum you’ll start finding references to pigs and chicken. This comes from a little story:

A chicken and a pig are together when the chicken says,“Let’s start a restaurant!”
The pig thinks it over and says,“What would we call this restaurant?”
The chicken says,“Ham n’ Eggs!” The pig says,“No thanks, I’d be committed, but you’d only be involved!”

The lesson is: Since the team is responsible, empower them. The practical matters are only team members estimate their work, and only team members speak in daily scrum meetings.

Introduction to Scrum

There is an official description of Scrum by the authority on scrum at ScrumAlliance.com. It's short and you should read it. You will find that most of the people you talk to that are "using Scrum", practice Scrum differently than the description therein. However, due to these differences I feel it is important to give a very brief introduction to my understanding of some core elements of Scrum before we can effectively talk about the role of the Scrum Product Owner.

People tend to practice Scrum in a multitude of different ways. I find that often they don’t know they are using Scrum in a way that is not “official”, but many are aware of it and you’ll hear them say “We use Scrum but...” Thus we refer to these people as “Scrumbuts”, and you can find many articles referring to Scrumbuts, and I think they are some of the very best articles on Scrum (ignore the condescending ones) and iterative project management in general.

The Sprint

Sprints are short iterations of work performed by the team. Key components are the following:

• Begins with commitments
• Ends with deliverables
• Consistent team
• Consistent length
• Short: <1 month

Every sprint must begin with commitments from the team. The team makes a commitment to deliver something of value to the project’s customers at the end of the sprint. At its essence this is what the sprint is all about: The deliverables to the customer.

Here, I define "customer" as the one paying for the project/product. This might be a client for a consulting engagement. For a commercial product this might be the executives sponsoring the project.

The commitment of the team cannot be understated. At the beginning of each sprint a success criteria must be defined and agreed to by the team that is crystal clear. At the end of the sprint all parties need to feel that the success/fail result of the sprint is obvious. At the end of a sprint if there is any doubt, try to define a better success criteria next time.

Consistency

Sprints are used as a basis for estimation. So it is important that they have a consistent length and a consistent team. This way, under normal circumstances the same team will get roughly the same amount of work done each sprint. So resist the temptation to let your sprint linger around an extra day and do whatever you can to keep the team intact. If these things change at some point just be prepared to see results that are not consistent with past results.

Scrum Roles

Scum identifies the following roles: Team, Stakeholder, Product Owner, ScrumMaster.

The Scrum Team is the people doing the work. These are usually mostly developers and QA engineers. The team is central to Scrum. The team is permitted to make their own commitment each sprint and they are to be uninterrupted during the sprint with new tasks.

In Scrum, a Stakeholder is the customer. Usually the one paying for the project or the ones who will use it and decide whether the project’s result is successful or not (this is different than most other project management methodologies such as PMI).

A Product Owner is the person who is responsible for the business value of the project. If you’re working on a product this is usually a “Product Manager”, in some other cases this might be a representative of the client.

The primary responsibility of the ScrumMaster is to remove obstacles for the team. He/she should also make sure that the other roles work according to the scrum framework. He is a "master" of the scrum framework, not the "team". In this respect a ScrumMaster is unlike the role of project manager as he doesn’t have any particular authority over the team. However, many of the skills that a project manager uses is also useful as a ScrumMaster. These include communication, people skills, good judgement, etc. The ScrumMaster is often a member of the team, but can never be the Product Owner too.

Scrum Artifacts

Product Backlog

The product backlog is a prioritized list of business value that the team needs to deliver. It is not a list of tasks. “Business Value” means value to the stakeholders. Everything must be expressed in a way that, when “accomplished”, the stakeholder will experience/see a real benefit.

Sprint Backlog

The sprint backlog is a list of items from the product backlog that the team commits to delivering during the sprint. Additionally, each product backlog item that the team commits to deliver should be decomposed into its respective tasks during the Sprint Planning  meeting.

Burndown Charts

Burndown charts are a measure of the total amount of “effort” (e.g. estimated hours of work) that is remaining during a sprint. By the end of the sprint a sprint burndown chart should show that zero effort is remaining.

Scrum Ceremonies

Sprint Planning Meeting

Before each sprint the team sits down and accomplishes two things:

1. Commit to delivering a selection of the highest priority items from the product backlog. This selection is made exclusively by the Team and is their commitment.
2. Decompose the selected product backlog items into manageable tasks.

If you want to learn more about scrum I recommend Scrum training or spending time with a passionate Scrum practitioner (not just any ol’ scrumbut Joe). However, a great book on the topic is Ken Schwaber’s Agile Project Management with Scrum. Check out it’s rating on Amazon and you will see that many others agree.

Daily Scrum

Every day of the scrum the team meets very briefly and every team member concisely shares the following information with the rest of the team:

• Accomplishments since our last scrum meeting
• Things I will accomplish before next meeting
• Obstacles to progress

There should be about three accomplishments and three things to accomplish. The obstacles should be outstanding and the ScrumMaster must take responsibility for either resolving them delegating someone to resolving them. Every team member should state all three points. If he/she has no obstacles they should state that clearly: “No obstacles.”

Sprint Retrospective

This is usually known as a “postmortem” but that term is often considered to morbid. Essentially it is an opportunity for the team to sit down briefly at the end of a sprint and discuss what worked well during the sprint and things they should change for the next sprint.

That’s it!

Principles of Scrum

As you can see Scrum is very simple. However, I like to say that Scrum is simple, but it is not simplistic. For Scrum to be successful you will need at least one person who truly understands and believes in the principals behind it. There are three principals of Scrum:

Transparency

You should have problems when using Scrum ("that's a feature, not a bug").

Inspection

You cannot inspect without transparency.

Adaption

You cannot adapt if you do not inspect.

The process of Scrum is designed to expose problems. You will find things like requirements that users don’t really want, that you began with not enough requirements, unrealistic estimates from dev or QA, unrealistic time constraints from stakeholders, team members that contribute significantly differently from others, lack of commitment from team members, lack of accountability, etc. That's good! Identify those things and discuss how to fix them, and fix them! Remember, it’s only two weeks. So if you can identify some problems in two weeks then at least you identified them in two weeks and now have the opportunity to start fixing them.

If you have genuinely smart/effective/savvy people scrum will work well (but so will just about any other process). Unfortunately, this is rarely the case, and with an experience Scrum coach or ScrumMaster, you will be able to identify and adapt to challenges rapidly.

For more on Scrum:

www.scrumalliance.org

delicious.com/activescott/scrum

Now, that this is out of the way, soon we'll talk about the role of the Product Owner in more depth.

Series: This article is part of a series that includes the following articles: The Role of a Scrum Product Owner, Responsibilities of a Product Manager in Scrum, Techniques for a Product Manager in Scrum: User Stories, Techniques for a Product Manager in Scrum: Estimating Techniques.

Updated: Lessmsi - Less Msiérables - Utility to extract files from a .msi File (Windows Installer file)

A new update to the Lessmsi utility is available. Several people have requested various features and fixes and I have made several of them. There were many small updates and some of these are more tricky than they sound, but the most visible changes are as follows:

• Good support for Windows Vista and Windows 7.
• 64-bit operating systems are working automatically now.
• Elevation is lo longer required / LUA is handled properly.
• Columns are now user-sortable for all the lists.

Source code and compiled downloads are available at: http://code.google.com/p/lessmsi/
Everyone should update their links to point to that link as it will be the most permanent location for the project going forward. All updates will be published there from now on.

And just because a screenshot is obligatory with any post about software :)

Let me know if you have any problems or -better yet- if you find it useful!

Covariance, contravariance, and C# 4.0

Today I was working on some code where I came across something that seemed perfectly logical language semantics but C# didn't agree. The scenario was as follows:

Assume we have the following types:

class MyBaseClass
{
}

class MyDerrivedClass : MyBaseClass
{
}

and we have the following methods:

static void MyMethod2(out MyDerrivedClass outArg)
{
    outArg = null;
}

Then I want to write the following code:

MyBaseClass c;
MyMethod2(out c);

But C# tells me:

error CS1503: Argument 1: cannot convert from 'out ConsoleApplication1.Program.MyBaseClass' to 'out ConsoleApplication1.Program.MyDerrivedClass'

Even the error message struck me as odd. I'm not trying to convert from MyBaseClass to MyDerrivedClass (obviously that wouldn't be valid), I'm trying to convert to MyBaseClass.

If at first this doesn't seem odd consider the following method instead:

static MyDerrivedClass MyMethod1()
{
    return null;
}

This method is syntactically different than the first, but semantically it is exactly the same since in both cases the signature declares a method that takes no input but accepts MyDerrivedClass as output (and only as output).

However, with this syntax I can make the following call:

MyBaseClass c;
c = MyMethod1();

Note that semantically, c = MyMethod1(); is exactly the same as MyMethod2(out c);. Yet I can make the call to MyMethod1, but not MyMethod2. Why not?

Well, I thought, it doesn't really matter. It is obvious that it should work, the spec is just too strict and it doesn't.

This is some covariance that C# doesn't support. It is covariance, right? I always get those two backwards. Anyway, it is a bit surprising, because since generics where introduced, the C# community in general has a lot of emphasis on contravariance and covariance. So I got distracted doing some reading into contravariance, covariance, and eventually C#. I eventually ran across some plans for C# 4.0 which as a document named "New features in C# 4.0". Interesting...


As I'm reading, I see C# 4 features as "Dynamic lookup" (reflection/late invocation done beautifully), "Named and optional parameters" (yawn), "COM specific interop features" (I love COM, but isn't it a bit late for this -yawn-), and "Variance". Variance!? Cool!

So yes, ladies and gentlemen some cool covariance is supported in C# 4.0. In C# 4 you can write the following bit of code you have done ugly things to avoid in the past:

IList<string> strings = new List<string>();
IEnumerable<object> objects = strings;

Awesome, right? It does require the type -in this case IEnumerable- to declare that it will not take elements in though. Obviously, we don't want someone to be able to put a non-string object into that IEnumerable<object> now. The declaration for this is a bit funny considering how I got here:

public interface IEnumerable<out T> : IEnumerable
{
    IEnumerator<T> GetEnumerator();
}
public interface IEnumerator<out T> : IEnumerator
{
    bool MoveNext();
    T Current { get; }
}

In the document it explains the above as:

The “out” in these declarations signifies that the T can only occur in output position in the interface – the compiler will complain otherwise. In return for this restriction, the interface becomes “covariant” in T, which means that an IEnumerable<A> is considered an IEnumerable<B> if A has a reference conversion to B.
As a result, any sequence of strings is also e.g. a sequence of objects.

The funny thing is, despite the fact they are using "out" to declare covariance on types (and delegates), according to the document it doesn't apply the same logic to parameters that are declared with "out". So despite the fact they've done this cool work for covariance on types, it appears the scenario I was after originally still won't work. Oh well, at least we learned about some cool stuff to come...