Shared Items in Google Reader

Yesterday, I listened to This Week in Google 3 (TWIG) on the way home from the office.  They talked about a TechCrunch article detailing new features of Google Reader.  Though I don't believe I've discovered my one-stop-shop to find or disseminate information I digest and enjoy on a daily basis, I feel Google Reader is heading in a good direction.  The hard part is just incorporating it into my current routine.  As soon as I arrive at the office, I check email, voicemail, and then it's off to Google Reader and Twitter.  I do all of this before  8AM.  It's not that I intentionally make this a habit.  It just is. So, in the spirit of early adoption, I'm going to attempt to use one of the new social features of Google Reader.  It is the sharing of items from Google Reader in my Google Profile and distribute to social sites like Facebook, Twitter...  My first share is Visualizing the Flow: Polar-State Based Personal Kanban with Habit Trackers via Evolving Web by Jim Benson on 8/1/09.  You can find it at google.com/reader/shared/derek.huether

What is my new habit?  Share at least one item I read in Google Reader to my Google Profile and Twitter on a daily basis.  Enjoy!

My Personal Kanban Story

Personal Kanban

A little over a month ago, Agile Zen started following me on Twitter.  They are creators of a very clean web-based kanban solution.  Around the same time, I connected with Jim Benson.  Jim is a collaborative management consultant.  He is the CEO of Modus Cooperandi, a consultancy which combines Lean, Agile Management and Social Media principles to develop sustainable teams.

Though I've used information radiators like kanbans in the past, I've been working in a non-Agile PMO for the last six months and it's all very foreign to them.  Thanks to reading the works of David Anderson, Jim Benson, and AgileZen, I'm back in the game.  I'm using AgileZen on a daily basis for everything from business deliverables, to an entrepreneurial project, to my wife's honey-do list.

My actual task completion velocity has noticeably increased in the last month.  I attribute that to AgileZen having a very easy to use product, Jim musing on a daily basis on the topic, and most importantly limiting what I'm working or focused on.

I wish I could thank all of the kanban supporters out there that I follow on a daily basis.  These 3 really have to be mentioned.  If you're interested in Kanban, look them up.

Free Project Charter Template

Project Charter Template

How many times have you started working on a project and don't even have formal authorization for that project to exist?  A project charter is a document issued by the project initiator or sponsor that formally authorizes the existence of the project, and provides the project manager with the authority to apply organizational resources to project activities.  Using this template will put all the cards on the table.  Knowing answers to key areas before you begin will save you time and money. This document includes areas for project overview, authority and milestones, organization, and points of contact.

On your current project, do you know the project oversight authority?  Do you know your critical success factors? Have you documented all of your project roles and responsibilities?  If you used this template, you would increase your chances for success by documenting the basics up front.

MS Word

[Click here to download the free Project Charter Template]

IE6 Friend or Foe?

Upon reviewing my Google Analytics account, I discovered 25% of my web traffic is from users using Internet Explorer 6. Almost the same amount of my AdSense revenue is from IE6 users. Being my site is designed for the current browsers, it misbehaves when viewed by IE6. I can't just ignore them, since clearly one quarter of my ad revenue is coming from these users. Still, I want to offer the best user experience. If you want to read more about the same issue impacting others, read the Mashable article. I'm seeing quite a bit of talk on Twitter about this issue. I wonder if it will have an impact.

Free Project Initiation Worksheet

Project Initiation Worksheet

When you are about to initiate a new project, you should capture the basics of project information.  If you don't, you're walking into a minefield.  Even before you write up a charter, you should be able to answer the following: Problem (or Opportunity) Statement -Describe the business reason(s) for initiating the project, specifically stating the key business problem or opportunity

Project Description - Describe the approach the project will use to address the business problem

Project Goals and Objectives - Describe the business goals and objectives of the project. Refine the goals and objectives stated in the Business Case (which you should also have)

Project Scope (Requirements) - Describe the project scope. The scope defines project limits and identifies the products and/or services delivered by the project. The scope establishes the boundaries of the project and should describe products and/or services that are outside of the project scope.

Critical Success Factors -Describe the factors or characteristics that are deemed critical to the success of a project, such that, in their absence the project will fail.

Assumptions - Describe any project assumptions related to business, technology, resources, scope, expectations, or schedules.

Constraints - Describe any project constraints being imposed in areas such as schedule, budget, resources, products to be reused, technology to be employed, products to be acquired, and interfaces to other products. List the project constraints based on the current knowledge today.

If you can articulate these seven areas, you've proven you have at least a basic understanding of what you're up against.  If you can not, you better go back and find the answers.  It is a lot cheaper to answer a question when the project is still initiating, compared to deep in executing.

[Click here to download a free Project Initiation Worksheet]

Free Critical Path and Float Calculation Worksheet

Critical Path Float Calculation Worksheet

The number one search on the Critical Path website is for a Critical Path and Float worksheet.  Though you should be using software to calculate a critical path, if it is mission critical, it is important to understand the concept for the PMP exam. Rather then go into the specifics on how to calculate the critical path and float in this post, I'll merely say a free worksheet template  and PowerPoint presentation are available and you can download them at any time. (see links below)

•

Remember the Critical Path tells you the activities that can not slip a day without increasing the total duration of the project or moving the project completion date. It is the longest path of logically related activities through the network which cannot slip without impacting the total project duration, termed zero float.

Free Meeting Minutes Template

Click here to download the Meeting Minutes Template

Back in March, I wrote a post about helpful tips for running a meeting.  With it was a free copy of my meeting minutes template.  Here is a brief refresher when hosting a meeting: [1] Write out the purpose of the meeting with actionable events in mind. e.g. “Provide an updated status, identifying risks and opportunities, and identify new action items.”

[2] Identify your attendee list but only keep those you can map to the actionable events listed in step 1.  There is a difference between an attendee list and a communications distribution list.

[3] Create an agenda.  Do not ever arrange a meeting without a written agenda.  Your meeting will suffer scope creep in the worst possible way.

[4] Identify who will run the meeting and who will take notes.  It should not be the same person.

[5] Ensure discussion points align to the agenda.  If they don’t, recommend taking the topic to another forum.

[6] End the meeting by having the note taker read back the discussion points and the understood action items.

[7] Send out the meeting minutes within one to two days.

Please note I don't recommend using this for a Daily Scrum or Stand Up Meeting.

Calculating Initial Velocity On Day Zero

While reviewing proposal documentation yesterday, I noticed the contractor's predicted velocity rate was pretty high.  Being they are not experienced in using Agile and they haven't even started the project, I was curious how they were able to calculate such a high velocity rate for the first iteration.  I know how many developers they intend to use and I know their proposed iteration durations.  I'm not going to get into the specifics as to how they estimated features (user stories, requirements, backlog items, etc.).  So, what did I expect? Velocity is a very simple method for accurately measuring the rate at which teams deliver business value. To calculate velocity, simply add up the estimates of the items successfully delivered in the last sprint or iteration.  What about the initial iteration?

Terms to understand when calculating initial velocity:

1. Number of Developers – How many developers will you have doing actual work?
2. Capacity - What is the maximum amount of work one person can accomplish in an ideal situation during the iteration?
3. Number of Iteration Days – How many work days are in the iteration?
4. Load (Capacity) Factor - The ratio of the actual work output over a period of time and the output if the developer had operated at full capacity over that time period.  e.g. 1/3 = 2.66 Hours , 1/2 = 4 Hours, 1/1 = 8 Hours
5. Velocity - How much Product Backlog value a team can deliver in one iteration.

Because you don’t know team velocity for the first iteration, plan initial velocity at one-third of total capacity in order to account for coffee breaks, design, email, meetings, rework, research, etc.  As an example, with seven (7) developers and at one-third (1/3) capacity, a total of 18.62 development hours are available per day.  Multiply the number by the number of work days in the sprint to arrive at the total of initial work hours.  These work hours will be applied against your estimated items, to arrive at an initial velocity.

(7 [Developers] * 1/3 [Load Capacity Factor]) * 21 [Work Days] = 44.1 [Ideal Work Days]

Ideally, the team should already be formed and stable, so that you can just forecast.  Unfortunately, this whole scenario is faulted. Not only are estimates for team capacity going to vary wildly, but what about the estimates for the deliverables themselves?  I can get pretty good at estimating a level of effort for work that could take a few days.  But the contractor that was noted in this post was estimating a 3-year project.  By the way, if you're curious, the contractor failed within 1 year. The federal agency then exercised their right to not renew their contract for the option years.  The agency then brought in a new contractor with more Agile experience.