On occasion I judge and critique projects done by college students as part of outreach by the SW Ohio PMI chapter. It seems more often than not a wedding comes up as one of the “projects” done by a group of students. A wedding is perhaps one of the first and largest projects that most amateur project managers attempt to undertake. Some couples hire professional wedding planners, I suspect the vast majority do not. Hence a wedding is a prototypical project management experience for many people regardless of what their profession may be.
I am very close to two very important people who will be getting married latter this year. I could offer my project management services to this couple the way a photographer or a florist may contribute. They have been busy planning and it seems that they have a good handle on the tangible aspects of the day. I worry still that all of this planning may ironically become an obstacle to that perfect day they both so richly deserve. Rather, I think a more valuable offering to my son and his future wife and any other couple planning a wedding is this adaption of the agile manifesto.
A wedding is a momentous event where family and friends gather to witness the vows of the bride and groom and the start of a new life together. It clearly needs a lot of preparation and planning. This is especially true when there are out of town guests and considerable financial expenditure is involved. All that planning, especially when the bride and groom are in the center of it all can take on a life of its own and over shadow the really important things that day. Through my wedding and being a guest at many other weddings over the years experience over the years I have come to value:
• Family, friends, hugs and tears over reception hall/church guidelines and “The Knot “ check list
• Precious memories of a happy day over hours spent posing for photographs
• A multi family & multicultural celebration over a party planned by a few people
• Being present in each moment over worrying about what has to happen next
That is, while there is value in the items on the right, I value the items on the left more.
I find it relatively easy to teach and mentor people about the classic aspects of project management what I struggle with is imparting the wisdom I have gained over the years about what is really important. That seems to be true for a wedding as well as many other endeavors. How to find the right balance is the central question.
Sunday, April 19, 2009
Wednesday, April 1, 2009
Tailor at your own risk
I signed up to speak at the next Cincinnati SPIN meeting next week. I plan to talk a bit about adapting agile methods such as SCRUM to work in distributed environments. Or just tailoring your current methods to introduce some agileness. I have a fair amount of anxiety on this topic.
What I fear is encouraging people to pick and choose from a set of Agile methods and then get in deeper trouble or further spread misconceptions. I believe processes like Scrum are the result of considering a particular development scenario and then putting it through a lean process filter. The outcome is a small tight set of processes where nothing is optional. (retrospectives, user stories, close customer collaboration, etc. ) Where some one to cherry pick a few of those processes and then claim to be doing Scrum it could be a big problem. Hence I think the difference between SCRUM and agile is like the difference between a set of values and a coherent integrated set of processes. Values are more abstract and processes are more concrete. It is like democracy and the government system of a particualr country. Agile is to democracy as Scrum is the the UK system of government.
On the other side of the coin I consider the multiple places I have worked or served as a process mentor and despite what ever label they apply: RUP, extreme programming, FDD or scrum there are still considerable variations among groups the profess to be following the same process. I believe that we tend to believe that things are more alike than they really are for groups who profess to be following a certain process. We under appreciate the tacit and implicit customizations that each group adopts. These adoptions are critical success factors.
Bottom line there is no magic bullet best practice. The art and science is in the tailoring and adaption of the broad range of best practices as identified by SEI or PMI with a values foundation as expressed in the Agile Manifesto. People over process, working software over extensive documentation, etc. Think like an agilest but make sure you have a story for dealing with scope management, risk etc.
I thought I was pretty smart 10 years ago when I had 20 years of experience. Now that I have 30 years of experience I realize how difficult this is and I have even less confidence. What I do appreciate is the wisdom I draw from all schools of thought and bodies of knowledge. Comming up with the most appropiate development and project management process is a very challenging endevor. The good news is there is now a lot of wisdom to draw from. Good Luck.
What I fear is encouraging people to pick and choose from a set of Agile methods and then get in deeper trouble or further spread misconceptions. I believe processes like Scrum are the result of considering a particular development scenario and then putting it through a lean process filter. The outcome is a small tight set of processes where nothing is optional. (retrospectives, user stories, close customer collaboration, etc. ) Where some one to cherry pick a few of those processes and then claim to be doing Scrum it could be a big problem. Hence I think the difference between SCRUM and agile is like the difference between a set of values and a coherent integrated set of processes. Values are more abstract and processes are more concrete. It is like democracy and the government system of a particualr country. Agile is to democracy as Scrum is the the UK system of government.
On the other side of the coin I consider the multiple places I have worked or served as a process mentor and despite what ever label they apply: RUP, extreme programming, FDD or scrum there are still considerable variations among groups the profess to be following the same process. I believe that we tend to believe that things are more alike than they really are for groups who profess to be following a certain process. We under appreciate the tacit and implicit customizations that each group adopts. These adoptions are critical success factors.
Bottom line there is no magic bullet best practice. The art and science is in the tailoring and adaption of the broad range of best practices as identified by SEI or PMI with a values foundation as expressed in the Agile Manifesto. People over process, working software over extensive documentation, etc. Think like an agilest but make sure you have a story for dealing with scope management, risk etc.
I thought I was pretty smart 10 years ago when I had 20 years of experience. Now that I have 30 years of experience I realize how difficult this is and I have even less confidence. What I do appreciate is the wisdom I draw from all schools of thought and bodies of knowledge. Comming up with the most appropiate development and project management process is a very challenging endevor. The good news is there is now a lot of wisdom to draw from. Good Luck.
Subscribe to:
Posts (Atom)
