update with Agile overtones

In case you care, and some of you do because I have received a few emails, I wanted to make a quick post updating things on this end.

You may know, I lost my Dad and best friend about 5 months ago and my Mom is very ill. Also, about a month ago, a major contract fell through due to a change in managerial direction. So, things are pretty tough and I have done good old prioritizing in regard to MY stuff and my duties.

I have not found much use in discussing Agile or Project Management in light of this personal business (although I can’t stop arguing with or discussing things with people on LinkedIn and Twitter), but I will submit that the lessons I have learned from being a software process guy and software team guy have been somehow integrated into my daily life.

For instance, I have a standup with myself every morning. I plan sprints (week-long). I am getting things done and the fact that a new difficulty has knocked at my door is easily accomodated by the flexibility this routine affords me. I am fortunate to have a great development team that I can continue to work with, and do mental “timeboxing”.

Scrum didn’t help me, and I cannot say that by the book Scrum has helped all my Clients or all the teams I have worked with. Same can be said for RUP, PMI, etc. However, the totality of experience – that which makes us who we are really (some philosopher said we are the sum of our experiences) – has proven invaluable.

I could not have predicted this course of events nor have been nearly as successful at pulling things off if I had a waterfall mindset.

Agile is a state of mind. It is helping me in my personal life and professional life. I urge everyone to read as much as possible. It is about being human, among humans, and getting things done. Try to be technology and methodology agnostic. Try to just learn. That’s my unsolicited advice. Like every day is new, every project is new, and like every project yields fruits of knowledge… so do the things that life throws at us.

Hope you are well.

Best,

Josh

Book of Knowledge

“The Path” sounds pretty heavy, but it exists out there in the amorphous world of SDLC methodologies and more accurately, the PLC. It is that common abstraction and line that runs through each but might not be so easy to articulate. You might liken this Path to the common truths that religions share without being called ridiculous. You would be left with a wonderfully broad palette of tools and discoveries resultant from freedom. I was a philosopher so religion kind of slid aside for me and was trumped even theoretically by the proclamation that I cannot worship a God I do not know exists. Pascal’s Wager is a cop out, although it is still used in IT “Best Practices”. The whole idea of Best Practices is absurd unless you restrict it to a very definite activity, at which point it defines that activity and you have a tautology.  Every project methodology shares the same *fundamental* goals. Every project shares something.

Just like religion, once instantiated in a human being or group, it can become enlightening and serve as a source of strength or if you are a skeptic, an imperfect but workable guide. It can also rip a team apart faster than an army of Google Recruiters. Here is where something fairly subtle has created a problem; it is a problem that needs immediate remediation.

You have a project lifecycle (PLC) and it details your project from start to finish. You also have a software development lifecycle (SDLC), which details the way the “work” happens and the stuff gets done. The PLC is a kind of container for the SDLC.

I am not sure that this Path (PLC) is anything more than one of Ayer’s Universals, to be honest. Sure, to have an end you need a beginning, but is that a construct or acho fundamental truth? Or, is it the way we have chosen and come to understand the world? A PLC is a way to choose to understand the process of a project. It is something you might find in an employee handbook, or “The Book That Describes OUR Process”. Once you get into the SDLC, there is magic and other cool stuff that is not so easy to capture without doing. I really do not care if you have a Scrum or an XP or a Waterfall SDLC. Compare it to another instance of the same. There will be differences. They may be small, but they will be *important*.

A PLC and an SDLC are both methodologies, although quite different in the amount of science that can go into them as opposed to the amount of theory (in this case, science is objective work). The PMI insists that they do not teach a methodology. Still, they produce PMPs, which are people who have mastered their Book of Knowledge. Book of Knowledge?  If you did not know, yes, they really call it that. There is a PMBOK, or Project Management Book of Knowledge. You get it as part of a package with logos all over it. Apparently, some long-bearded geek came stumbling down a hill with it one day and fell down, proclaiming the way has been revealed. You just need to go buy some PDUs, spend a little money every so often, and you will also glow with the wisdom within the Book of Knowledge.

I didn’t say it sounds like Scientology. I didn’t.

Impossible Job Description

I have received this three times from three agencies in the last 2 weeks:

Notice anything a bit ambitious?

The SharePoint Engineer is a member of the Application Support Services team whose focus is to derive business value from core server applications.  The environment will soon be expanded to offer new sites and functionality, so an in-depth knowledge of SharePoint (MOSS 2007) will be required to assist in the development of product roadmaps, governance models and architectural design for a mid-size (500+ user) infrastructure.  The individual should also have extensive experience in the planning, implementation and administration of SharePoint server, and the development of team sites.

The individual will provide technical leadership and expertise for SharePoint projects managed by the Project Management Organization or internally and will mentor more junior systems engineers as needed.  This position will interface daily with members of the Information Services Division (ISD), Shared Technical Services (STS), end-users, departmental managers, business application and system owners, and vendors.

7-10 years IT experience with proven ability and experience in developing and managing systems infrastructure solutions is required.  Bachelor’s degree or equivalent work experience is also required.

1.       7+ years experience planning, implementing, configuring, and supporting a mid-size SharePoint 2007 (MOSS 2007) server infrastructure (500+ users)

2.       SharePoint roadmap development

3.       Governance policy creation and administration

4.       Site development using SharePoint designer and InfoPath

5.       SharePoint workflow and document management experience

6.       Experience with IIS, SQL Server 2005/2008, Windows Server 2003 is desired

7.       Familiarity with server hardware, networking and related infrastructure and devices is desired

8.   Experience with data security and system security (virus protection, anti-spam, etc.) applications is desired

Google Phone? Google Maps? Google TP!

I am a little confused – some of the label is in English. Specifically: “Virgin Pulp”.

(?)

- Josh

Maturity

This is Level One out of 5 of the CMM, meaning it is the most IMmature of the 5 levels.

• Initial (chaotic, ad hoc, individual heroics) – the starting point for use of a new process.

Does this sound immediately odd to anyone else?

That is, aside from the fact that apparently there is value in telling us that a brand spanking new thing is not a mature thing. (Cuz yeah, I didn’t know that.)

That also is, totally ignoring the fact that what may appear immature may actually be metamorphosis.

The CMMI is applied to software and other industries. It started in government. It is applied to organizations that make things. How *mature* are these organizations? Can we expect them to deliver? Maturity is repeatability, absence of waste, etc. I see cubicles. 9-5 workers. I see waste of a different sort. You have to kind of hide Agility in there, because agility is kind of like being a Lion Tamer to a lot of execs.

I like working with heroes, personally. The context for the CMMI is narrow and like all things that can be branded (“CMMI for Agile” for instance) is being productized and NOT helping.

Thank you,

Josh