Ok Grasshopper ... When you can take this pebble from my hand...

On the Merits of Certification:

At its very core, Certification is a piece of paper that says you have been exposed to or have been trained to a certain level of proficiency in a certain body of knowledge.

I won't question the value of the certification. I for one think that there is intrinsic value to being trained and certified, Certified Scrum Master (CSM), Project Management Professional(PMP) whatever. For me the issue is that the connotation that one can be certified in something like the PMP or the CSM and they walk away a master in the art/discipline is specious.

All PMPs are not created equal all CSMs are not created equal. All those credentials really mean is that they have exposure and ideally a better than average understanding of what the methodologies offer as value propositions to an organizartion and how to implement them, to what levels of success may vary.

In the case of the CSM, I think the real weakness of the certification is that because its "Agile" it is some how easy and fast a panacea of sorts. This connotation sets erroneous expectations of what someone walking around with a CSM is or is not capable of. Maybe a more hardcore approach to the certification is warranted. Hopefully the discussion with the village elders of the Agile Community will come up with something that better protects the integrity of the skilled practitioner and brings more value to the table.

For the PMP, while the certification is much more rigourous with the concept of an auditable period of time before qualifying and continuing education requirements, that really only scratches the surface of what it means to run a project or be a project management professional or a leader in general which is really what project management provides at its basest level, and any leader worth is salt will tell you no one can just magically wave their leader wand and bam you are a leader, something about blood, sweat, and tears needs to get mixed in there,

Let's use a metaphor for this issue (everyone loves metaphors), I look at it like the mall strip Karate Studios and how many people have black belts these days? 2k and 1 year and bam you get yourself a black belt. They were certified in "attaining" knowing a certain level of skill, practiced it in a prescribed time, and a governing body approved said level of skill.

I have studied and trained for more than half of my life never got more than a brown belt at any one school of martial arts. To the uneducated many would discount me as a dabbler or amateur until they check my references as a closed door student to several highly respected masters of the martial arts, renown by blood and by deed. Maybe one day I will pony up 2k and join the certification class but then the master's would look at me funny and say so what's this about you want to start your own school too huh? (like that?... yeah like that and all it implies.)

Certifications are always nice to haves. I for one am far more concerned with practical skill and experience than fancy papers even though they can make me look really cool. My real value lies in how I apply my skills and expertise not whether or not I have a pedigree and I sleep-walked through it all. Black belts like that get weeded out eventually, usually by a kick to the neck and a short nap on the canvas.

Does that mean I don't value a certification process? No but I do check under the hood and kick the tires a couple of times just to be sure things are where they are supposed to be.

Remember in Kung-Fu the series Grasshopper's journey didn't end when he was able to take the pebble from his masters hand... It was only the beginning. Oooooo...Zen-esque Mystical stuff now what would be the billable for that?

- Optimal Optimus

Agile Perspectives

I recently attended an Agile Seminar sponsored by RallyDev (a great tool so far as I can tell). Anyways I found it very very informative.

Ordinarily I am never one to drink the proverbial "Kool Aid" but I found their approach to implementing the Agile Methodology as very rational and sound. Yes there was an air of Yoga to it but it was light.

I found the discussions with Israel Gat to be particularly ... profound would be too strong a world but insightful is a much better ring to it. His blog captures alot of what I discussed with him in our break out.

Either way what I took away from the event was that not everyone that does Agile is a "Bible Thumping Zealot" and that the methodology is sound to the point major corporations have leveraged the principles presented in the Agile Manifesto to great success. So for any of those who watch the Dog Whisperer it was an opportunity to see the possibility that it could work, it can be done, and that is very empowering and also encouraging.

It also reminded sadly how far away my current organization is from truly being Agile or even following the precepts of Agile to realize any of the economies of scale that the panelists are extolling and challenging us to meet.

But if everything is an iteration then we are a few more iterations away from having a shiny agile implementation. Here's to the next release.

-Optimal Optimus

Dependencies, Critical Path, Float... who needs em?

* Dependencies?
* Critical Path?
* Float?

In the game/consumer product development world those things are laughable.

Dependencies? Of course there are dependencies probably hundreds am I going to track them all in some sort of master map of a schedule and plan when they change daily as we innovate or find new ways to do things or move in a different direction. That in and of itself would be a full time job. How much value add do I provide saying oh yeah based on dependencies we have lost 4 days of work

Critical Path?
When everything has to happen doesn't that mean everything is on the critical path? There's an equation to Critical Path the "sequential tasks with the longest duration" Oh yeah but you throw that into mix with the maze of Dependencies how do you make the critical path worth tracking?

Float?
Time you can leverage to move resources and effort to other parts of the project in hopes to get it back on schedule? Is there such thing as spare time in a product development environment. Shouldn't we be working full tilt from inception to launch?

Everything has its place and so do these concepts. The important thing to remember is that the context changes depending on the environment. There are dependencies in Product Development environments as well as float and a critical path. However they are all treated differently and "managed" differently.

In a Product Development organization dependencies are acknowledged and worked through on a tactical level, so that the schedule concentrates on what going to be delivered next, not how the past is affected it. If dependencies are not being met they are raised as an issue(s) and resolved by the appropriate management level.

Critical Path is the entire project, every task, every item. How do you manage it? Issue Management. When things like dependencies put the delivery of the product at risk it immediately becomes the most important item on the critical path. Every item that stops the forward motion of the project is the "Critical Path" and needs scrutiny and resolution.

Float? there is no float, float is an illusion, a luxury of those who do not realize that at any given moment if we don't judiciously apply our efforts and resources we end up slipping. Its the job of every Product Development group to be fully leveraged at all times on delivering the product or game since I happen to be in the game business.

- Optimal Optimus

An Agile Understanding

Some excerpts from a presentation I gave to people looking for help with Agile Project Management and SCRUM. Credit to the Dilbert folks J of course.

So what is SCRUM and Agile Project Management?

Not going into any overly specific jargon or canned answers:

• Agile is a Project Management Methodology that focuses on
• Iteration
• Interaction
• Transparency
• Product Delivery
• SCRUM is a meeting and project tracking format used heavily in organizations that practice Agile Project Management

Traditional Project Management and SCRUM/Agile Project Management

• Traditional Project Management places emphasis on
• Milestones
• Artifact management
• Historical reporting
• Minimizing Change
• SCRUM/Agile Project Management places emphasis on :
• Iteration
• Product oriented delivery
• Transparency
• Extensive Product Owner Involvement
• Change is expected and incorporated in the process to provide value add.
• Does not rely heavily on historical or artifact management but rather how much work remains moving forward.

The Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Pasted from <http://agilemanifesto.org/>




Iterative Development

• Developing End to End, a working product with the assumption that improvement and gains can be made throughout the development iterations
• The product may not have 100% of the feature set but could be used in production
• The general concept is to flesh out and improve over each iteration to meet the requirements/expectation of the business



SCRUM… What's it all about

• SCRUM is the default process for Agile Project Management and has the following assumptions in its pure form:
• Senior Team Members
• Dedicated Team
• 100% Product Owner Involvement
• Product Backlog
• Sprint Backlog
• Daily Meeting
• The Burndown
• Sprint Planning Meeting
• Pigs - Committed
• Chickens - Not Committed



The Daily Meeting

• 15min or less
• What are we doing?
• What is planned?
• What is blocking us
• Take a look at the "Burn Down" or whatever graphical representation of the project the team uses
• That’s it. No muss no fuss

Pitfalls of the Daily

• "Lets talk about implementation details" - Good Idea, wrong time
• "Logorreha" - The idea is to keep meetings short so the communication used is supposed to be boiled down, too much talking and team members not on your portion of the sprint loose interest and slows morale
• "What are we supposed to be doing" - No product owner no sprint is what I say, he's the guy/gal that breaks ties on what has to happen and should be the definitive authority on the project Prioritizing and Deprecating as the process moves forward.
• "Scrummaster does that? Right?" - Scummaster doesn't do very much but act as the alarm for the team and escalate issues and run interference for the development team (Pigs and Chickens)



The Burn Down

• This is the Graphical Representation of Agile it measures velocity of completing a sprint.
• It looks to work remaining as the metric as opposed to how much is done.
• Seems counter intuitive but from a line perspective it allows the resource to see what is remaining and how much its going to take as opposed to looking at the Gantt and seeing what was done and have no idea how much its going to take given the current time frame.



Question 1:

• Are Unplanned items usually unexpected production support related issues? What else is unplanned?
• Well from my perspective we prioritize the production issues and weigh them against the constraints to hitting the sprint as negotiated by the product owner.
• If the product owner says this product support issue trumps the feature the issue gets the effort and the feature gets pushed to the product backlog for reallocation .
• Remember because of the Transparency (in this case finite resources and product owner involvement) Delivery expectations match what the product owner wants.
• Note: as soon as the Product Owner assigns the task to a sprint and gives it a priority it stops being unplanned.

Question 2:

• If we determine part of the way into a sprint that existing code (Created before the Sprint) needs refactoring, should that be included as an unplanned item
• In the sprint the User Story should take into account potential unplanned tasks and reflect it in the Complexity Points (If you use them)
• At the very least be brought up as a blocker in the Daily for discussion on inclusion into the sprint and requiring Product Owner resolution.

Question 3:

• If we start work on a story and realize the initial estimate of the story was way off, do we modify the total number of points in the sprint?
• I wouldn't. This should be brought up in the daily that the sprint as it currently sits is in jeopardy and that the product owner needs to re-assess the Sprint as a whole and reprioritize the Tasks/User Stories as it would meet the expectations of the Product Owner and end users.

Question 4:

• If we start work on a sprint and the product owner decides he/she doesn’t want a story anymore do we modify the number of points in the sprint?
• Yes. However it's been my experience that the Product Owner never wants to take things off without adding more. The reason is typically to assign more work.

Question 5:

• What sort of requirement gathering process do you go through before you start a new sprint?
• I have a pre-planning meeting with the Product Owner and Lead Engineers, review the product backlog, and then pick the brains to identify additional work.

Question 6:

• If we have a project that is only 1-2 weeks worth of work would you recommend setting this up as a spring? If not how would you choose to handle it?
• I would assess is it really an independent initiative or if I could roll it up as a User Story in the forthcoming sprint.

Scrummtastic!!!

So I am now a newly minted Certified SCRUM Master!!!

Do I feel any different? Have the Project Management gods opened up their pearly gates and blessed me with a glimpse of arcana that will revolutionize my organization?

One word? No.

For those of us just joining the blog, I am not big on the seemingly growing trend of Methodology Fundamentalists growing out there and just like their Religious counterparts, they only seem to make things more difficult than they really are.

Just call me a secular bastard but bottom line it there are things that we can do in project management in business that take all these tools these methodologies and apply them judiciously and where appropriate to make significant gains.

Bottomline:
Results matter. How we get there whether pure XP, Scrum, Waterfall, Ninja Techniques from the Black Scrolls of Mu; Ship the product with minimal bugs/issues within expectations and everyone busts out the stoagie and we go home with the prom king/queen WOOT!!!

That said am I glad I took the training? Absolutely. It opened up some areas for improvement and experimentation to the hybrid model I have been employing . Will I sport the credential? Damn Skippy!!!

Above is probably one of the best pictures of the Agile Methodology I have seen to date. (I found it in a google search)

Image - 2008 ENVISAGE Technologies Corp.
1441 S. Fenbrook Lane - Bloomington, Indiana - 47401 - 812.330.7101

- Optimal Optimus

Project Management… Science or Crusade? Red Pill or Blue?

So this is my first post on R-Cubed Project Management and I thought long and hard about what the first rant would be because that’s really what I am doing here, ranting. I decided to go with a Matrix/Transformers motif ergo the little YouTube snippet with the apropos Red Pill "Truth"/Blue Pill "Blind Faith" dialogue; Project Management Methodologies/Tools/Processes...Science "Red Pill" or Crusade "Blue Pill".

Being a project management professional for the last 10 years I have seen my fair share of project management flavors of the month: Agile, PMBOK, LEAN, XP, Scrum, etc. What gets me standing on a soap box is that these PM Tools, (cause that is what they are tools) come complete with pushy evangelists and "over-internalizing" chest thumping adopters.

Instead of looking at the problem space that an individual organization faces and what tools that the scope of the project management profession has developed i.e.: Agile, Scrum, XP, LEAN, PMBOK. These so-called "practitioners" adhere blindly to a methodology or worse a PM Tool Suite thinking that it will miraculously solve all of their operational woes. Nothing could be further from the truth.

There is no magic bullet or cure to project management or management/leadership in general. The only thing I can think of that would come close to a cure for project management/leadership woes is to look at it scientifically as opposed to taking it on like a crusade.

Selling Agile processes is not project management.

Identifying how applicable and how Agile processes can be implemented and thereby prove a value add is project management. The idea that having multiple iterations and weekly meetings is not being "Agile"; its simply having multiple iterations and weekly meetings. Thinking that any one methodology or any particular part of a "methodology" means you are doing it 100% is dangerous ground to stand on and since being in Project Management means you try to find the least dangerous ground to stand on, it would make sense to pause and re-evaluate such decisions.

Science or "Scientia" in the latin means "to Know" which later spawned the Scientific Method meaning "to know" via the practice of observation and experimentation. This concept has a couple implications on this issue:

• It takes away the marketing pull of Methodologies/Canned Workflow Tools as a panacea for Project Management.
• It applies a reason/rational approach to how we make our management decisions this includes what methodologies/processes/tools we adopt.

Applying a scientific approach divests us of the emotional clamor of "crusades" to handle projects in an "Agile" fashion or a "Lean" process. It allows the Project Manager or decision maker to evaluate the methodologies/tools/processes to make decision on what makes best sense to solve the business problem. After all we are in the business of business not thumping the latest management mantra. Just because an expert says that true blue Agile works best at XYZ company doesn’t mean that true blue Agile will work for yours. It may take a hybridization of different methodologies, tools, and processes to get it just right for the decision maker and their organization.

Crusades, generally speaking have rarely ever been a good idea because a crusade takes rationality out of the equation and replaces it with faith. Effectively saying "who ever believes hard enough will win out in the end". It's rings with the tone of "God Wills it". I don’t presume to know the "Will of God" or to speak for him. I will however take my "God-given" brain and apply rational thought to my selection of methodologies, tools , and processes to solve the business problems presented to me, because it makes sense and not because the "Agile" gods will it.

-Optimal Optimus