Whenever I tell people that I am both a PMP and an Agilist, many look at me as if this had to be some deep, dark secret.

How could one study and practice a formal project management methodology and also use Agile?

Josh asked me to write about some of the challenges and obstacles that we face in our environment. In order to do that I should explain a little about that environment.

Over the past 36 months we have transformed ourselves…

via Flickr by drewgstephens

In this post, I explained that SCRUM is not a silver bullet and that there some significant barriers to entry for organizations wanting to adopt SCRUM. In this post, I’m going to introduce Agile estimating, planning poker, fibonacci, and velocity.

Let’s say that your organization is ready to go, you’ve turned command and control on it’s ear, you’ve identified the Product Owner and you’re going to be the ScrumMaster. You’ve put together a team of seasoned developers, a creative designer, and a QA Lead, but the designer and QA Lead have never worked on an Agile project and they also have never worked with this team of developers.

Let’s say that the Product Owner has put together a pretty comprehensive list of User Stories [let's say that for argument sake that these have been validated and prioritized and you have verified that they follow the INVEST principles...more on that in another blog post]. What now?

First, you need to work with the “Team” to make sure that they understand what their responsibilities are, this includes the talk about being a self-organizing team, that they’re responsible to one another, the Product Owner, and ultimately to the organization to do what they say they’re going to do.

The next step is for the SCRUM Team [that's the development team, the Product Owner, and the ScrumMaster] to decide which items in the Product Backlog you’re going to deliver in the upcoming Sprint. In order to accomplish this, you need to be able to quantify how much time or effort each item on the Product Backlog will require.

This quantification of the Product Backlog is called estimation and is commonly accomplished by having the development team play a game called Planning Poker.

Game playing? Man this SCRUM stuff is wierd. OK, let’s talk about Planning Poker.

The idea behind User Stories is to collect the requirements in bite-sized pieces. The size of those bites will inevitably vary. The Agile solution to this problem is to rate each User Story according to relative “size”.

The best analogy I’ve heard is to compare the stories to dog breed…compared to the other stories, if the current User Story a Toy Chihuahua or a Great Dane? Where in the middle…Jack Russel Terrier? Labrador Retriever? Once each person has an idea for the relative “size” of the item, each person has to play their hand, and the group consensus wins…highest and lowest have to explain why they think the feature is larger or smaller than the rest of the team.

When I do this, as the ScrumMaster, I intentionally don’t play a hand because I don’t think I should influence the team’s collective insight into how big or small a feature is. To each their own. The planning poker deck we use was purchased from Mountain Goat Software and was well worth the few bucks it cost. There are online versions and of course with a pair of scissors, some index cards, some markers, and a little free time you can make your own.  The important part is that you understand the notion of the relative scale of accuracy and the variability that is introduced as a feature gets larger.

You’re probably familiar with the Fibonacci series of numbers. We use this series of numbers to incrementally scale the “size” of a feature. Why do this at all you ask? Well, if I ask you to estimate in inches, the distance from the tip of your index finger, where it currently is, to the tip of your nose, you will probably be able to estimate with better than 85% accuracy. Now if I ask you to estimate using the same criteria the distance from the tip of your index finger to the middle of the letter “O” on the nearest Stop Sign [depending where you are right now] you might be able to estimate with a significantly smaller degree of accuracy, and finally if I ask you to estimate, in inches, the number of inches from the tip of your index finger to the tip of the Empire State Building in New York City, you are likely to have an accuracy approaching 0%.

With this in mind, we use the Fibonacci sequence because as a feature increases in size, our inherent ability to accurately estimate it’s size diminishes. After all of the items on the backlog are estimated, the next step is to determine the Sprint Backlog…the estimated subset of product features that will be addressed in the Sprint. We had a hard time understanding how much we could bite off in our first few sprints [in other works, how many "story points"...or Fibonacci values we could consistently complete in a sprint].

In order to get around this, we took two decisive steps.

First we committed to micro (one week) sprints and second we intentionally rigged the sprint backlog with items that we knew were small enough to complete in a week, yet big enough to validate [one way or another] our estimates. This process allows us to determine our “velocity”. Velocity is the average rate at which a team can complete story points for a unit of time. Once we were able to determine out weekly velocity, we were able to extrapolate our bi-weekly velocity.

Once we were able to determine the velocity for a “normal” sprint, we have become increasingly confident in our ability to deliver on that velocity. I will put in a big caveat…the velocity statistic is only a general guide, and as you adopt SCRUM, the accuracy of the velocity is only as good as your ability to limit the variability of external change within the team. In other words, if you determine the velocity for a specific team, that velocity will be affected by making changes to the team, and even in some cases by changes that the team may make from within.

For more information on these topics, there is a great book on this topic written by Mike Cohn called “Agile Estimating & Planning“. I highly recommend it.

Guest post by Erika Flora

Stand Out - by Shot_by_Cam via Flickr

With the current economic conditions, an increasing number of people are either afraid of losing their jobs or desperately searching for work. Just like it’s a buyer’s market for housing, it also seems to be a buyer’s market for employers. Those who are hiring can be extremely selective in whom they choose. That’s why smart Project Managers plan today for tomorrow’s “what if.”  We need to be smart about managing our own career “risks” and have a mitigation plan firmly in place now.  There are three simple, cheap, and super smart things you can start doing now to avoid any unneeded worry and panic if you do, in fact, find yourself looking for other career opportunities.

1. Invest in yourself. First, make time to invest in yourself. No more excuses! If you do not currently have your PMP^® certification, now is the time. You don’t have to spend a lot of money. A PMP exam prep course can range from about $800 for a PMI^® chapter sponsored course up to $3,000 for a professional training course. All told, your total required investment is small compared to the rewards (significantly better pay and more visibility as a job candidate). Further, if your current company pays for training, you really have no excuse; that’s a benefit you can’t afford to pass up. Nothing in life is guaranteed, and that includes the job you have today. Take the time to invest in your career now, so you do not end up having to scramble if things take a turn for the worse.

If you already have PMP certification, look into some advanced training that is complementary to project management. There are a number of niche areas that employers are starting to look for (i.e. Six Sigma, ITIL, CMMI, Agile/Scrum, etc.). There is a strong emphasis on “doing more with less” these days, and employers are looking for people who can help improve how they run as a business.  Broaden your skills, and differentiate yourself by being a project manager who understands the world outside of just managing projects.

2. Create a buzz. Now is the time to start making a name for yourself! Start a course of action to position yourself as an expert in your field. One way to create a buzz is to write articles on what you know. You can do this a number of ways. First, try submitting articles to your local chapter of PMI or another local professional organization.  Groups like this are always looking for new content and will often be more than happy to publish your work in an online newsletter.

Another way to get your ideas out there is to start a blog (or even just start posting your thoughts on this site).  Also, WordPress, offers free blogs that take only a few minutes to set up. You can write as often or as little as you like. Write about whatever you are passionate about, and you may be surprised at how many readers you end up with!

Consider joining a local Toastmasters club in your area. If you’re feeling adventurous, book a speaking engagement or two! This will provide you with credibility in your industry, and you will undoubtedly become a better speaker as a result. Plus, it’s a great way to meet influential people in your industry.

Demonstrating your communication skills, both written and verbal, is a good way to make you a better project manager and get the word out that you are an expert in your field. Start building your reputation by putting your thoughts and ideas out there.

3. Make a difference. If you are busy making a positive difference in this world, you will be rewarded.  Volunteer your time! If you are not doing so already, get involved as a volunteer with your local PMI chapter, or work with another non-profit organization in your area. By giving of your time and talents, you will likely find you get tremendous satisfaction in mentoring others around you. You will also strengthen your own skills and maybe even pick up a few new ones. It’s also another great way to meet good people in your area. I personally know a lot of people who have found wonderful new jobs as a result of becoming a volunteer.  Make a difference in the lives of others, and your life will positively benefit as well.

If you focus on developing these three areas, you will undoubtedly have an amazing road ahead of you, both personally and professionally, regardless of the ups and downs of our economy.

Erika Flora, PMP, ITIL Expert
Principal, Beyond20
erika.flora@GoBeyond20.com
http://blog.erikaflora.com

I’ve been crazy again about Scrum recently and wanted to share these great videos with you.  All are entertaining and relatively short, and good for Scrum newbies.

Enjoy!

Scrum Basics

This is one of the best “intro to Scrum” video I’ve ever seen!  The first minute is a little slow, but it gets better after that.

Agile Developement with Scrum: What they don’t tell you

This is a promo and very short.

A Day in the Life of a Scrum Team

Excellent snapshot to give you a feel for what this kind of team is all about!

Recent events allowed me to catch up on some reading and I found myself going through “Sway – The Irreresitable Pull of Irrational Behavior” by Ori and Rom Brafman. The book is a generally enjoyable light read, but it delved into one topic I found very fascinating: irrational loss aversion.

Regular status meetings are boring: everyone goes around the table and rehashes what they did in the last week or month. No one really cares. If the project dates are slipping, the team wants the meeting to be over with so they can get back to doing something useful.

But status meetings can be fun!

I am a Lead Systems Engineer on a very large multi-year project to deploy image processing software for a satellite ground system, and would like to share some experience and lessons learned in trying to manage a project using agile and waterfall software development in harmony.

SCRUM is something I have some experience with, and I believe there are many tools and techniques that grew up in various methodologies that we all can learn from. You may already know that I’ve written about SCRUM on pmStudent.com before, and the various applications of techniques that can be relevant to all types of projects, even those far removed from software development.