Thursday, August 31, 2006

Some people hate PMPs :-)

2 comments

Today I came up with some write-ups /blogs about Agile vs Plan Driven Methodologies in Project Management.. I didn’t know that people have so much negative feelings about PMPs who are in to Plan driven methodologies till I read this particular blog

“particularly the PMP crowd, are often oblivious to the incredible amount of waste inherent in their approaches.”


“In sum, you are describing exactly the battles I fight with PMBoK slaves when trying to help them see that Agile appoaches do everything they're expecting to see, only they do it *a lot more* often and keep doing it from "big picture" down to "tiny details"... “

Ok Im a PMP.. But I use agile methods as well., Being a PMP doesn’t mean that you have to believe PMBOK method as a religion and reject all the other methods. What I have seen in my whole career as a PM and Head of PMO is that, you cannot be inflexible and stick in to one method. I find many projects which really need agile methods.. But there are projects you need a fixed plan and a strictly plan driven method. When I have to release a product to my marketing department and when the scope is well defined, I have to commit on a exact deadline and plan everything in advanced. When we should start the contract of the marketer, when to arrange a product launch, when to hire specific software professionals to my project., everything should be well planned and should execute according to the plan., In the same time we have projects which we can convince the customer on our agile approaches ( Very difficult in offshore projects I should say) A PMO should strike a balance.

Recently I met an IT director in a Multinational Software Company who thought Project Management is MS project. I told him I have never used MS project. He asked me.. in that case how you track the project? I just said MS Project is just another tool. But I don’t think I have convinced him at all.. So imagine a PM practicing scrum under a superior like him. It will be a disaster.

No matter whether you are a PMP or certified scrum master or Prince 2 certified PM , you should be open up to new ways of managing projects, and should be able to switch as and when needed.

Friday, August 25, 2006

Easy Scrum – 3 Don’t let this happen

2 comments

Ok this is another experience I had with scrum teams; One day I noticed that our daily scrum meetings were going on for hours.

What we have to keep in mind is that, the Daily Scrum is not used as a problem-solving or issue resolution meeting.(this is the exact mistake they did) Otherwise what happens is that daily scrum takes too long and due to the issues raised by few people, the whole team keeps on arguing and going on in different directions. Actually those issues can be taken care of, after the daily scrum meeting with affected team members.

During the Daily Scrum meeting, each team member is asked to answer the following questions;

  1. What did you do yesterday?
  2. What will you do today?
  3. Are there any impediments in your way?

So the sprint backlog should be updated accordingly. and if there are any impediments, they should be listed . After the scrum meeting, you can take care of the issues found out at the meeting or any other adhoc issues.. Other wise You will start the scrum meeting at 9AM and go till 5Pm when there is a critical issue with your program specs or class diagrams..

Thursday, August 17, 2006

New Name

6 comments

Don’t be surprised.. I just renamed this blog. I had some problems in RSS feeds with the existing name “Project Management” as it was a really common name.

Thursday, August 10, 2006

Another very big thank

2 comments
Its really nice to see that this blog is mentioned in the PM Network magazine August 2006 Issue through “Social Network” article.

You can find the soft copy at http://www.pmi.org/info/PIR_PMNetworkOnline.asp

Very big thank goes to the person who wrote that/recommended this blog.

Easy Scrum – 2

0 comments

First I thought of writing details of each step of Scrum. with that idea in my mind, I posted “Easy Scrum – 1”. But Yesterday I did sort of a case study with one of my teams to practice Scrum. So I thought its worth to write about it and it covers the whole cycle.


Ok here it goes…

I got the team together, none of them have practiced Scrum before., I did some initial presentation of Scrum to get some idea and then gave them the case study.


The case study was a Project to make a “Vesak Lantern”. ( I have very few Sri Lankan readers reading my blog, but so many overseas readers. So its worth to explain what a Vesak Lantern is . Vesak Lantern is a Lantern we Buddhists make for the Vesak day ( Lord Buddha’s Birthday )celebration ). So all my team members have made at least one vesak lantern and they have the “Industry Knowledge” . So it was easy. I acted as the customer to change the decoration requirements of the Vesak Lantern the way I want ( It was annoying J )


Project Constraints:

Vesak day is May 21st. It’s a Project Constraint.


Product Backlog :


We have to light the lantern on the Vesak day night.

So the team got busy. First I selected a Scrum Master. And I asked them to create the product backlog.. That was interesting., Planning, Designing, Making the Skeleton, Purchasing Materials, pasting papers, Setting Light Bulbs so many things in the list., .. What happens if there is a power failure on Vesak Day.? ( Which is very common in Sri Lanka). They had the risk plan too.. the mitigation was to light a candle inside the lantern instead of a light bulb.

The design we wanted was a aero plane shape of a Lantern. But I kept on asking changes to that.


Once the Product backlog is made, it was estimated with required man power cost and the material cost. But the team had to revise it many times and recalculate it as the requirements kept on elaborating


Then the priorities were decided by the scrum master and the team., of course you cannot paste papers without making the skeleton. They prioritized the tasks accordingly


Sprint

They defined sprints, durations for Sprints were vary. They selected the Items based on the resource availability and Priority for the first sprint. Sprint backlog was created.

Daily Meetings

As a good Scrum team, my fine team simulated the daily standup meetings.. But they wanted to sit and chat instead of standing, Never mind.. This is easy scrum.. so I told them that its ok.. Every day at 9AM the team meet to discuss the daily plan and 5PM to review the daily achievements.. It went on for the whole sprint..

How about the people who try to skip meetings? Do we have a penalty.. Yeah .. Rs. 100 ($1 ) should be collected from absentees and use it for team outings after some time…If I have a good team.. I will not have money in the till :-)


This is a very productive thing.. We do not slip daily targets and we do not postpone work until the last day and then struggle with it or just do something about it.. I know the team will find this bit hard at first. But they all will appreciate it after some time..


Burn down Charts

Scrum master created the Product Burn Down chart based on the items taken off for the sprint. We didn’t create any Sprint burn down charts as our duration for the sprint is very short.


Impediment List

One of the objectives of daily standup meetings is that to foresee the barriers for the team to achieve their daily workload and eliminate those barriers. So we are not waiting till the last minute project meetings in order to find why we have not achieved such tasks and to realize its too late.. They found that the guy who had to purchase material doesn’t have a vehicle to go to the stores. So they have eliminated the problem by hiring a vehicle for that.

Product backlog Delta Report

Scrum master kept on updating the product backlog Delta report. I found the status of items as follows.

Not Done (initial state)

In Progress

Done

Deferred

Deleted

Lessons Learned

We completed the lessons learned after every Sprint. So we could more or less eliminate the over estimating issues in latter sprints.


Project Management office?

PMO wanted few standard reports . So we completed the Milestones report and weekly Project update report based on Product backlog.

Over all we could get the team buy – in for the method by doing a case study with lot of fun. I think if you need to introduce such methodology to your teams, this may be a good start.

Conclusion

+ points

Scrum is really a good way to manage projects which are quite uncertain

Every team member feel that they have a major Stake in the Project.

Team members have a very good understanding of the workload and the challenges they should face in the project as a team.

Team members don’t feel that work is assigned to them., they feel that they have volunteered to do tasks as they want to be the winning team.

Over all very good Project Control

With this method.. you are never too late.. Because you don’t wait till you are too late.

Its no more covering backside for anybody..

Difficulties I see

Sometimes its hard to practice this with people who are not in same caliber with other team members.

Taking leave affect the sprint backlog

Difficulties of committing to the final deadline due to multiple iterations

Difficulties to negotiate with project budgets time to time

Thursday, August 03, 2006

Easy Scrum - 1

7 comments

We have a Project to develop a common product for Retail Distribution. I thought of using an Agile method in order to manage this project due to the nature of this project. This has more chances of changing the scope and the project seems very uncertain. So We selected Scrum.

But we have many challenges..

We don’t have a Scrum Master. We have only a Project Manager. We don’t have a Customer working with us., But we have a Domain Expert within the team who will act as our customer. We don’t have Microsoft Team Systems. But we have Microsoft XL. We have a Project Office which needs some sort of generalized templates of all the projects.

How do we go with it.. ?

First I wanted the team to be familiarize with Scrum. The Problem is training.. We don’t have such training and workshops available here and no project budget to send them overseas. So the next option was Web and Online mentors.( Which is the only option we had)

My main concern here is the caliber of people we have for this Project., To practice Scrum Its really required to have team members who contribute to the product., And not the team members who just code the given spec and think of themselves as furniture of the company.


Step 1 - Create Product Backlog


First we got to create a Product Backlog.. How do we do that? Its very Simple.

You got to create a list of all the product functionalities ( You can simply use a XL sheet or MS VS Team Systems). You may have got so many documentation at this time. Go through it clearly, understand the required functionalities, understand everything what you have to do with the project, List them. Then prioritize them in order to see which ones to be completed first, depending on their dependencies, impotencies and effort requirements.

Then the question comes.. Who can add items to Product Backlog.?? Do I have to secure this sheet with a Password? No ..In our case we asked everybody to add items., PM, Tech Lead,Project Owner, Team, Domain Experts and so on. Then we prioritized them based on the required functionality of the product in order to do release 1 of the product.

WBS vs Product Backlog

Remember your good old WBS? (Work Breakdown Structure is the deliverable based grouping mechanism inProject Management ).. You can see the Product Backlog as something similar to that. Both can be used by the PMO to understand the amount of work to be carried out in the organization’s projects. The Difference is that WBS is a Deliverable based Grouping and it doesn’t reflect prioritization of your task or estimations. Its more or less defined, and its created by the Project Manager. But Product backlog has almost everything you got to do with the project. It shows which tasks to be done first., and the value and importance of them. Any stakeholder can add items to the backlog. New Items will be added over a time period.

WBS helps a PM to plan the required work Packages and estimate them., Product Backlog helps the PM and team to plan items for a Sprint. ( Short time Period) and estimate the work to be carried out.

Once the Complexity / Value and risk is identified for each item, You got to estimate your Product Backlog. This can happen in 2 instances

  1. A new Item is added to the Product Backlog
  2. Existing backlog item is substantively changed.


How do you estimate the Product Back log? Are you going to categorize items by Size and put a weight on each category? Or is it by any other costing methodology?

This is very useful for the Project manager to evaluate the effort involved in a release and this allows the team to select the backlog items for the coming sprint.

 

PROJECTIZED. Copyright 2008 All Rights Reserved Revolution Two Church theme by Brian Gardner Converted into Blogger Template by Bloganol dot com