Here we go again!

Well, two years ago this month, I started this blog. I titled my first post, "here we go", and then 'it went' after a little over a month. I had good intentions of using this blog as a tool for helping me dive into agile software development from a very anti-agile PMI background. It served me well, but as my sixth post titled, "drinking from a fire hose" indicated, I was overwhelmed and the blog died.

So here we go again two years later in October (strange?). Lets see if this time the blog will maintain life for a while. For the last two years of trying new agile practices, some of them stuck, some failed miserably, but all good experiences none-the-less. With the ups and downs however I am a full practitioner and advocate.

Through the last two years, this particular whitepaper by Michele Sliger of the Rally Software Development Corporation has been an oldie, but goody.
A Project Managers Survival Guide to going Agile

Agility in Leadership

While learning about agile and what it can do as a project management methodology, it has come more evident that there is a need for the PM to be agile in his/her own daily practices and thoughts, not in how they manage their projects alone.

In a Program Management Forum Luncheon, John Hirsch (Guide Consulting), presented on the topic of "PM Talent Management: Leadership & Talent Management During Times of Rapid Change".

As companies move to an agile approach, this topic is on the forefront of many minds within the organization. Hirsch reported that typically only 10% of executives are agile in their behavior. In times of transition, most people fail or excel. The question is can you be agile in the development of you and your project team?

The following are questions that John Hirsch presented to help us answer that question for ourselves;

* Do you have a development plan for yourself?
* Do you have development plans for those on your team?
* On Average, have many hours per week do you engage in development activities?
* Can you describe your development activities?

As a project manager, you have the opportunity to help other people develop even though you are not directly responsible for them. You should look at your team development as well as your own. You can use personal and team development to help ease into an agile environment.

Commitment

In Project Teams

I heard a great analogy used to describe commitment.

In regards to breakfast... If you have a breakfast with bacon and eggs, both the pig and the chicken contribute to breakfast, but which one was committed?

You can be a contributor without demonstrating commitment, so how do you get your project teams to be committed?

As part of an athletic team, you are committed to the organization and the other members of your team. Everyone has buy-in to a common goal that was adopted or created by all from the beginning. If a collegiate athlete is not committed to the team and the goal, it is not long before the success of that team diminishes. Focus is taken off the goal and redistributed to dealing with obstacles that the lack of commitment creates. An example of on obstacle would be, the team having to re-direct their focus from the task to that individual person to try to bring them on-board. "Obstacles are what you see when you take your eyes off your goal."

Success is difficult if not everyone buys into the fact that, what they are doing, will get us there. Most athletes buy hole heartedly into the idea that the end goal is to be on top, the best. A project team in an organization may be more difficult to convince. This is where ownership comes in.

3 example actions that might help increase ownership in project teams;

• Have the project team directly involved with creating thier own goals.
• Make sure the project team individual knows how important their contribution is in the overall success of the organization.
• Allow the project team individuals to be a part in day-to-day decisions.

Ownership breeds commitment. Commitment comes from understanding and accepting a common goal within a project team. If a project team or individual has a hand in determining the method in which is going to help get to that goal, they become much more committed to seeing it through.

In agile development, the team members share a goal and a common belief that their work is interdependent and collaboration is the best way to accomplish their goal. Teams heavily depend on their teammates to be committed to the organization, team and the task. Because teams are focused on specific tasks within a short in length iteration. Agile will help to expose those that contribute, but may lack the commitment. Agile methods inherently drive the team in a self-organizing direction - this demands commitment to be successful.

Drinking From A Fire Hose

One of the benefits with an Agile development approach, is the potential for more output in our development department. We were brainstorming on how this will impact other departments, especially support. How will they be able to successfully handle more products and features to support? If this agile method works for us, in theory, we should be able to output more in a shorter amount of time.

The analogy is the idea of drinking from a fire hose every so often as it is quickly turned on and off as opposed to drinking from a constantly dripping source.

When we open up the end of the fire hose, a HUGE release goes firing out the end. This release to our customers has everything in it that we haven't been able to put out because we haven't had a general release in 6 months. The other departments, i.e. support are left trying to handle this enormous amount of new functionality to support and learn. It takes that drying off period in between fire hose squirts for them to clean up and get back on their feet for the next hit. Historically, they are not done feeling the affects of the hit before the next one comes. This leaves no preparation time, only reactive recovery.

A constantly dripping hose seems more efficient right? I believe this to be true, but only if there are good processes in place to handle these small more manageable increments coming down the pipe. If not handled correctly and promptly, they can build up to mimic the fire hose being turned on as well. Support has to be able to adapt to an iterative cycle way of life as the development department is working under. This isn't just a methodology and mindset change for one department, but for an entire organization.

Of course this is just in theory, we have yet to begin this process. In regards to newly implemented agile approach to software development, what was the trickle down effect to other departments? Does anyone have experience with this?

Can you wait 2 weeks?

I attended the Pacific Northwest Software Quality Conference seminar on Monday 10/10/05 where Agile Alliance co-founder and owner of Mountain Goat Software, Mike Cohn spoke on Practical Approaches to Agile Estimating & Planning. His emphasized the agile approach of knowing more before you provide estimates. He also provided some great tools and techniques for obtaining estimates from a project team and not just the individual contributors.

We have all been asked to provide estimates for projects based on the limited factors that are known up front. If you have been like me, you provide a detailed project plan schedule based on those individual estimates and thus coming up with an end date that delivery promises are based on before the ink dries.

One of the best take aways from the conference I had was the phrase, "can you wait two weeks?". Here is the context...

Providing dates is an important form of communication, and when accurate, help to build trust between a PM and his/her stakeholders. With Agile, you don't provide major milestone dates until you are more informed. Requirements can change at any time and be of any magnitude. Because of this, how much time did you waste as a PM creating a plan that was obsolete as soon as it was signed? Mike Cohen stated that he always asks the stakeholders if they can wait two weeks before providing an estimate. This lets the project team get started with the iteration cycle, and based upon that performance, is in a better situation to provide a more accurate estimate. In a non-agile approach, we might typically take two weeks, shut up in our office coming up with the estimate that is no longer valid when we come out.

When you do provide a more accurate and reliable estimate at the end of that two weeks, that builds trust. The answer to the question, can you wait two weeks and I will have a much more accurate estimate on that for you?, becomes easier for the stakeholders to answer, yes! Another pro in my book for the agile approach.

Forced Into 'Agile'

This is not a blog written against agile, in fact I am neither a proponent nor opponent at this point. All I know is that in the IT project world Agile is the hot topic at moment and so I must 'go there'. You cannot search on any PM topic right now as related to software development without running into words like; agile, iteration, scrum, sprint, backlog etc.... Needless to say, I am managing my first project using Agile with SCRUM next month.

What happened to, you have to have detailed blueprints before you can even think about laying that first brick? If Agile methodology was used to build a house, how would you know that the corners will all match up in the end? The answer is, I guess, you can never guarantee that by extensive up front heavyweight planning either. Up front, you don't know everything you need to know yet. Here are the questions that got me thinking...

• 1. Are you more informed as the project moves forward? How about at the end?
• 2. How much more did you know in the end that you wished you new when you started?
• 3. How many of us have made estimates 6 months in advance and ever hit that original end date?
• 4. How many of us have ever had an original end date that didn't change within the first two weeks of the project?

One big differentiation that is made today is that it isn't fair to compare software development with construction because construction is governed by physical and mathematical laws. Software development projects are their own beast, in which a lightweight methodology just might be enough.

So what does this mean and how do I have to change not only my skill sets, but my mindset to prepare? Remember as a rookie, I have only just learned the, "right" way to do things. Agile was not a part of my PMP certification training. Can you teach a new dog new tricks? An old dog has at least been able to reap the rewards from his old tricks for a while. When I say new, I mean new to me. I realize Agile has been out there for several years now. Will it become mainstream in software development projects? Is waterfall gone? For us. ask me in a couple of iterations.

Not a PMP, Get It!

According to the PMP overview on Velocitech's website, " in 2001 it was estimated that only 1% of all project managers world wide had attained PMP Certification" That percentage has grown by leaps and bounds in the last 5 years. If you have scanned the job market recently, you will notice a considerable amount of PMP certifications required and not just preferred.

In an article titled; "Mastering the Profession" in the April 2005 PM Network magazine written by Marcia Jedd, she talks about the 4 levels of project management certification that the company ABB customized for itself. ABB is a leader in power and automation technologies that enable utility and industry customers to improve performance while lowering environmental impact. The ABB group operates in around 100 countries and employs around 103,000 people. So, large.

The 4 levels are;
1. Associate Project Manager
2. Project Manager
3. Senior Project Manager
4. Company Senior Project Manager

In these 4 examples, where do you think in the ABB company a PMP certification is required? The answer is 3, Senior Project Manager. The next level requires 10 years of experience. Not until level 3 senior project manager handling complex domestic or international projects do they characterize these PM's as the ones with the PMP certification through PMI.

When I started on the path to obtain my certification, I thought that it was more 'unique' than it turned out to be. I thought that it would really help to set me apart from my competition. It is still an accomplishment that I am honored to have and it has opened doors for me, but I certainly don't feel that I am ahead of the game. It is now becoming something you need to just be able to turn in an application.

I would also like to add that as a Rookie, this certification is invaluable, but book smarts doesn't replace experience. If you are new to PM, start here and obtain your certification. It may still help to catapult you ahead, but it will surely guarantee you are not behind. My advice, Get-R-Done! ( I promise that is my only hillbilly reference I will ever make)