This week I really wanted to turn up the volume of things I wrote about.  I have a lot to say (and write) about project management and if you missed reading my blog on a given day and don’t have an RSS feed or follow me on Twitter, you’d have to go searching in the archives to find it.  I don’t think that’s good enough.  I should make it easy for you to read what I write.  Hopefully, this week in review will help you find something new while you enjoy your coffee or tea.

1/28/2010

Seeing Value From The Customer Perspective

I don’t care if you’re using Agile, Waterfall, or other methods to deliver value.  What is important is you understand your process and what mechanisms provide the greatest value to the customer.  Just because a process does not appear valuable to you, it does not mean the process does not provide value…

1/29/2010

Refine Your Process If You Must Deviate From It

If you’re looking for a free Microsoft Visio template of a Sprint process workflow, which you can edit at will, you can download it here.  As I mentioned in my post Seeing Value From The Customer Perspective, if you think you need to deviate from a documented or understood process, rewrite or refine your process to account for the deviations…

1/30/2010

The Impact Of Social Networking On Project Management

Good leaders do not operate in a vacuum. They exchange ideas and information with people. Offer free information and it will come back to you tenfold. Listen to knowledgeable people and then make a more educated leadership decision… In this post I compared the traditional communication paths and how that process is turned on its ear, thanks to social networking…

1/31/2010

This Is How You Know When To Kill A Project

A personal rant about paper telephone books and how I never realized, until now, who the real customer was. There is a very similar parallel between the newspaper industry and the printed phone book industry.  They both believe or promote the scarcity of information.  That scarcity justifies cost.  To the contrary, we now live with an abundance of information.  That information is freely distributed and reaches a broader audience…

2/1/2010

The December Numbers Are In For PMPs

Yes, the December numbers are in.  December 2009 numbers for Project Management Professional (PMP®) certifications were published and it looks like there will be over 400,000 holding the certification in 2010…

2/2/2010

And The Best Methodology Is

I recently commented on two blogs that address similar topics.  Jesse Fewell wants to empower teams to succeed, equip managers to lead, and enable executives to unlock the secrets of high performing organizations.  Jesse wrote a blog post offering the real reasons behind the methodology wars.  It’s an insightful post and I would recommend you go and read it…

The other blog post was from Mike Cottmeyer, someone I turn to on a regular basis to find inspiration and wisdom within the industry.  Mike wrote a blog post asking Why is Agile so hard to sell? Again, it is a very good read and you should set aside some time to read some of his writings…

The Pain Of IE6 And Application Development

There are legacy applications out there that were built on IE6 and it’s not an easy migration.  There are some Agencies which ONLY use IE6 and the users don’t have permissions to install a new browser.  So, what do you do?…

2/3/2010

Updated 10 Step Help To Submit PMP PDUs

All PMPs need 60 PDUs during a CCR cycle so don’t put it off until the last minute.  I document the process on how to claim your require 60 PDUs…

2/4/2010

Using Common Sense With Documentation

Though I really love good documentation, going heavy on it does not guarantee a successful project.  My recommendation is you spend a little time identifying documentation that truly meets your needs.  More importantly, identify documentation that truly meets your customer’s needs…

2/5/2010

Managing Risks and Opportunities

Washington DC is in the process of getting 20-30 inches of snow, over the next 24 hours.  Though I know you can’t foresee all possible issues which may occur over the course of a project, you should make an honest attempt to identify them in order to open a dialog with your stakeholders.  Has weather ever delayed your project or pushed it over budget?…

The question is always asked, which Methodology is best?  It is interesting to see or read the responses from people and their reasoning behind their opinion.  I actually don’t like to use the term Methodology. I would prefer to use the term Approach.  Merriam-Webster defines methodology as a body of methods, rules, and postulates employed by a discipline; a particular procedure or set of procedures.  An approach is the taking of preliminary steps toward a particular purpose.  THAT is what people do.  If you review the PMBoK or the Agile Manifesto, neither are going to say in the event of A-B-C, in this sequence, do D-E-F.  Life, application development, and project management are complicated enough.  You don’t need to write an algorithm to know the next step needed to accomplish goals.

There is a pain point in the industry that I’ve seen ongoing for several years now.  In this post, I’m not going to say which approach I think is better and why.  It’s really kind of irrelevant.  I think what is important is we ask ourselves and our stakeholder. What IS important?

I recently commented on two blogs that address similar topics.  Jesse Fewell wants to empower teams to succeed, equip managers to lead, and enable executives to unlock the secrets of high performing organizations.  Jesse wrote a blog post offering the real reasons behind the methodology wars.  It’s an insightful post and I would recommend you go and read it.

The other blog post was from Mike Cottmeyer, someone I turn to on a regular basis to find inspiration and wisdom within the industry.  Mike wrote a blog post asking Why is Agile so hard to sell? Again, it is a very good read and you should set aside some time to read some of his writings.

My bridge to both blog posts is identifying Wants and Needs.  Both drive motivations.  Once you understand the motivation, you can answer the question “why?”

Before analyzing why one team likes one approach or has disdain for another, you have to question their motivations. We assume we all desire the delivery of value. That’s not necessarily true. Some are more motivated at protecting the status quo or their position in the program.

The hierarchy of wants, not needs, will commonly differ between teams, if we want to admit it or not.

Image courtesy of quickandirty

On our current project, we have over 100 people across 14 Scrum teams.  The challenge?  How do you communicate between Scrum teams?  Well, that all depends. What are the dependencies between the teams? Though I could write a 1000+ word post about this, I figured I would just link to a short but informative video.  In it, you’ll see Mike Cottmeyer talk about scaling Scrum and how you might have different types of scrum-of-scrums (the way you would communicate between Scrum teams).  Mike is a Product Consultant and Agile Evangelist at VersionOne.  You can read more from Mike on his blog, Leading Agile, or on the VersionOne blog, Agile Chronicles. I’m hoping if all goes well, we’ll be bringing Mike to Washington DC to offer a few days of training.  I’m sure this will be one of the many important topics to cover.

I just read are very intriguing post by Ken Clyne on the Agile Blog, located at RallyDev.com. The post was about how problems can arise when people don’t realize a meeting is over.  Ken offered one way to avoid the never-ending meeting is by having a clear signal that the meeting has ended.

I could not agree more. Don’t you just hate it when a meeting has ended, not everyone knows, and people just start to filter out of the area?  I’ve found myself looking at the meeting host and actually ask if we were done.  That is not a way to conduct a meeting.

Though I believe this applies to all meetings, the daily stand-up (daily scrum) really needs to have a clear beginning and end.  Though some may not agree with me, I like to use a visual aid like a big alarm clock.  Everyone sees the clock ticking away and know a very loud alarm is going to go off at an agreed upon time.  You see people get anxious if others are rambling on and the time is ticking away.  Think back to your youth.  Remember how you knew you were late for class because you heard that starting bell?  Remember how you knew you were dismissed from class because you heard that same bell? Let those years of conditioning motivate the team.  Though I like the visual queue, you should still say something to the team to close the meeting.

Unlike your school days and hearing your assignment is due Monday, I know I’ve closed meetings with So let it be written, so let it be done, Make it so and May the force be with you.

Link to the original post

(Image by zert.sonstige_2008 on flickr)

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 features 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.4 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 2.1 ideal developers are available.  Multiply the number of ideal developers by the number of work days to arrive at the total of ideal work days.  These ideal work days will be applied against your estimated features, to arrive at an initial velocity.

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