Tuesday, April 14, 2009

Software Development is like cooking with too many chefs in the kitchen ;p...



Working with Software Developers is always a challenge IMO (not so humble opinion) its the more difficult challenge as compared to other more tangible Project Management disciplines (IT, Construction, etc). The simple reason is that you are dealing with the intangible and often fluid nature of software.

Software of any significant value is simple in its value offering, but inherently complex in its development. This complexity is an equation of developer personalities, responsibilities, organizational infrastructure, communication levels, political battles, resources all shifting to meet the needs of the consumer of the application that needs to be balanced adroitly. The same could be said for a construction project or server deployment but the concept of ground being broken and servers are on the dock is by and far more real than, how an abstract object will be handled by the as yet un-coded system.

Where in traditional IT shops and more concrete project organizations like construction there are a lot of regulatory strictures that exist, governance is part of the overall development model, in software similar concepts exist but the ways to meet them are as limited only by the architecture and skill of the development team(s) and their product owner(s) framing the problem space. That's why software is so different. So many factors so many people feeding the critical mix soup, then factor in the vendors, the methodologies and the time and associated risks it often is a maelstrom of chaotic decisions and knee jerk reactions all to the beat of the all mighty "Time to Market Drum" hammering away at you.

This is not to say all Software shops are the same they aren't, like anything there are orders of Magnitude of chaos. Software serving high governance industries will never be built the same as a video game (having worked in both sides of the spectrum I can attest to that). But it never looses its fluidity its almost art like quality, that when your cooking it it has to come out right or it will fail to meet expectations. Developers are like Chefs striving to make the experience unique and to their liking, like true artisans of their craft and the restaurateur the product owner or management hammering away at them to make the restaurant shine and then there's the general manager of the restaurant doing his best to keep the kitchen in shape and the chef's from fighting with each other and churning out wonderful dining experiences so that people come back and buy more.

Awfully flowery but close enough.

The whole idea here is that for me at least, a project manager in a software environment is supposed to bring harmony in a world of dissonance. To pull together the team by whatever means (hard selling or soft selling methodolgies, tools, communication models whatever is apropos to the problem space) necessary to bring clarity and concordance to the team and start delivering value add as quickly and as efficiently as possible. (Somewhere in there there has to be management support but that's a whole other story)

Thursday, April 9, 2009

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

Monday, March 30, 2009

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

Friday, March 13, 2009

Communication Discipline

Communication

So abused a word. There are so many aphorisms that exist stressing its importance, its rarity, etc.

Here's the deal for me. Communication happens all the time. When we talk, email, text, blog, twitter, even when we don't say anything. The problem is that people do not realize that their communication doesn't always make sense to everyone that sees it. I am guilty as anyone in this regard.

I am of the opinion that as project managers we should be the best communicators on the deck. My preferred comm style is to be as unvarnished and concise as possible, this more often than not does not help me win friends, but what it does help me do is illustrate issues that need to be addressed. Format and spacing and whether or not you put a little ":)" in it never come into play.

Why so hard? Doesn't the more bees with honey adage apply? No. Here's the reason why and its an inflamatory statement but that's ok I have a thick skin.

Communication requires some sort of mutual understanding, typically the understanding is centered around a shared vision or goal or something that the one or both participants can agree upon or desire. The more simple and easily articulated the goal the more likely mutually beneficial outcomes come to fruition. Sounds easy right?

Here's the rub. As PM's we are often in the difficult position of trying to establish communication channels, plans, responses etc. We are charged to do this with team members with vastly different experience sets, agendas, and perspectives. What one participant understand can be vastly different than the other. It is imperative that the PM and stakeholders are clear and succinct to identify the mutually agreeable goal. Why do you ask? If there is no discipline and understanding of how difficult communication and collaboration is the team will tear itself apart trying to come to a resolution.

Communication Discipline - adhereing to a code of conduct typically "taught" or "trained" in regard to communicating with others.

If someone was taught that 5000 emails a day was status quo and that was the extent of their discipline then it is exponentially difficult to get those individuals to do something else or communicate with them that there are alternatives to their current level of communication discipline.

Repetition, patience and working on clarifying goals become the only effective means to improving the situation.

-Optimal Optimus

Wednesday, February 11, 2009

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

Tuesday, February 3, 2009

A post on Corporate America



This is a great show. Definitely captures the essence of being a late 20's early 30's in the new millenia. Part of me is sad that I'm actually 3 years older than the main stars in the show. The comedy is sharp and relavent. Cobie Smulders is ridiculously haawwwt. But my favorite character and probably the favorite character of many is the character of Barney Stinson.

In this newest episode Barney doled out an "Awesome" insight in the world of corporate america as evidenced by the youtube clip above.

The episode centers around the gang talking about resumes in hopes of helping Robin's character from being deported due to visa violation. Barney relates what Corporate America is looking for in an employee.

As we watch Barney's ridiculous video resume about randome non relavent buzzwords with flashy images and no mention of anything he has done. The gang points out that resume has nothing about what you do and Barney looks up and says exactly.
"Corporate America doesn't want people that do. Corporate America wants people that look like they do but don't; in fact doing anything ... that will get you fired." (or something to that effect)


A more true statement has never been uttered. I have had my share of hiring and firings and let me tell you from my experience more people are hired on flash than substance and when substance is provided they are usually punished for it.

I get all kinds of excuses for it:

"Nature of the Beast"
"Welcome to Corporate America"

Excuses aside doesn't change the fact that its not right. If you stretch it a little all our economic woes stem from the tolernance of this line of thinking.

"Sell a good game and don't deliver. Then protect your sale by doing as little as possible as cheap as possible possible."


Sounds like a winning solution set to me.

I founded Generation-Joe and its professional oriented R-Cubed Project Management (the more professional oriented sister site/blog) to take a stand against sentiments like that.

We should stand on principles

  • If you can make a difference then make one.

  • Speak your mind without fear of reprisal

  • If you are going to speak make sure it makes sense and its not bullshit

  • Never give up

  • Fight for what's right

  • Don't be a passive aggressive dick

  • Take Risks

  • Don't believe your own press



- Optimal Optimus.

Sunday, February 1, 2009

Project Management and Web 2.0



SO I have been thinking. Yes I know its not often but I have my moments.

This Web 2.0 business:

* Wikis
* Social Networking
* Twitter

All of this stuff what's it mean to the practice of project management. I mean the extent of web 2.0 to project management IMO has been the leveraging of Sharepoint. The concept of project work spaces and such is hardly news but what is news is that the communication that Web 2.0 starts bringing and taking it to the mainstream means we as project manager can start driving communication by the tools we use.

Does a client need the strict hierarchies of Sharepoint? Are they fluid and flexible that they like some sort of wiki implementation. Do they leverage an artifact tracking system? Web 2.0 provides fast and easy implementations that allow the PM to concentrate on the communication model rather than implementing a tool. I think its pretty cool.

For the record I am following the following tools

*dekiwiki
*ning
*boonex

Either way its definitely an interesting time to be a PM.

"The PM Matrix" Integrated tith Ning's Social Network Platform


- Optimal Optimus