PMP

On Monday this week I passed my PMP exam. It was easier than I thought. Though the process to get ready was rather long and that must have contributed to the easiness I now feel about the test process. I started off late in May and with a few weeks-long breaks in my study it's only October when I finally got to take the test. I should feel some sort of excitement I guess but the only thing that I can consciously feel is relief, a big one actually :)

I heard people say that PMP study was boring for them. Not for me. I didn't enjoy it, don't get me wrong, but it was not boring. Time consuming indeed, excellent sleeping medicine for sure :) but not boring in a sense when you do something because you have to and can't help but regret the time wasted.

What it was for me one might ask? Best of all, a way to systematize my knowledge and pick up on the right vocabulary and professional language. That is essentially the outcome for me, plus of course the label for the resume. People in PMI require project managers to advance in their careers and get better in the profession. So I can say I just complied with the PMI Code of Ethics and Professional Conduct :)

--

One of our executives approached me the other day and wondered why I picked the PMI certification and not some sort of "agile label", a SCRUM master or something else of that kind.

SCRUM, RUP and other life-cycle models / management methodologies for software development projects are specific to the software industry. PMI is industry-agnostic and does not teach a particular life-cycle model. Instead, it leaves life-cycle specifics to the particular industry and calls it "application area". PMI flies high above that focusing on major things and areas of concerns a project manager in any business domain should be dealing with daily. And it is in fact true. Person in charge of the project will be dealing with stakeholders, planning, scope management, risks, etc. In areas of quality management it lines up with ISO standards and CMMI models as well as Six Sigma. And again, it would be wrong to consider CMM/CMMI and ISO a development methodology, though I often hear people associating it with the waterfall-ish (less or more iterative but non-agile) model. But it's like apples and oranges, often cross-cutting and not necessary conflicting concerns. Primavera Systems, by the way, has their true SCRUM-based development process ISO certified.

Software craftsperson

It's well understood that the more cross-domains knowledge you have the better off you are as a specialist in a particular area. It's very true in software business.

I've always appreciated that I had a chance to start my IT career in a small software company where over a course of 3 years I learned and practiced all different kinds of programming languages and technologies. Never since did I touch as many different things (over the same period of time) delivering production software.

All extra time I had put in learning new things, extra effort I had spent jumping from one technology to another is now well paying off. It's an invaluable asset and actually a must requirement for R&D, technical presales, and projects' rescue missions (SWAT). The three things I enjoy doing the most.

Apparently, a few years ago Scott Ambler wrote about it in his Generalizing Specialists: Improving Your IT Career Skills. I somehow missed this one. It would not have changed anything for me as by then I anyway knew this is how it should be. It's just I haven't had a reference, I was unable to support my understanding of the way to develop IT capacity in a fast growing large software company with words of somebody who's well known and respected in the community, a thought leader. Now I have it and I thought I might share it with whoever follows my posts...

Cheers

Is doing Agile like having a jam session?

This post opens what I hope will become a series of posts on Agile in general and Distributed Agile in particular; about challenges adopting Agile in a geographically diverse environment; about injecting Agile in originally CMMI-oriented environment; all about running Agile with offshore. And to open a series I felt like I needed a metaphor, something to describe Agile in a new fashion, something fancy .

Yesterday I happened to be dragged into a chat in the office of one of our executives mangers (Alex, sales and marketing). People were talking about how to better position our experience and expertise in Agile.

Alex suddenly asked me a question:

- ok. so tell me. what do you do differently in your job [running projects and saving projects that are not going that well, to put it short] when you do it Agile? explain a fundamental difference to me without software jargon terms, make me understand it.

Then he paused and looked straight into my eyes. I felt like I really needed to explain it, and I wanted to explain it.

Think about it. There's no straight answer to this question. Agile manifesto declares principles that don't make (force) project teams do something fundamentally different from a "regular" (plan-based) approach. Iterative, continuous, open, transparent, collaborative, backlog, priorities, changes, test-driven, etc. - all this can be equally true regardless of the approach. I mean, we exploit all these techniques even in a big corporate high-profile, highly-political, and thus heavy on governance and formal processes accounts. None of this was the answer I was going to give...

- Hm... here's what I do different. I am actually always doing it but Agile setup just makes it very natural. Imagine me communicating with my customer (business representative, business analyst, architect, anybody) about requirements and priorities. I would listen to what they're telling me and actively engage in the conversation by running a funny background process in my head. I would convert what I'm hearing into a software abstraction, that is how would I build it. This abstraction is a very abstract abstraction - assumption-based pseudo architecture. It's like if I hear that there's a format conversion I can think "make it XML, there's always an XML-2-XML, we're done. doesn't matter if we end up doing it completely different, enough to know there's a viable approach that makes sense to me now." Or when I hear there's a report and tabular data I think "make it a relational model and I'll query it out, then slice and dice, we're done". And so on. If I couldn't build an abstraction I would ask for more details. Once I have a fuzzy abstraction that I'm comfortable with (I just need to feel it's feasible) I convert it back to the business functions to see the gaps in what I ended up with and what I was hearing in the first place. And here I would challenge the gaps and clarify the concept, redo the conversion, and go on and on in cycles. It's like I'm always actively thinking and building software in my mind as requirements get progressively elaborated on. I do the same in plan-based environment too, but I do it offline (!). In Agile environment I do it online. That's the difference.

And Alex gave me the metaphor I very much liked:

- so it's like jamming, like a jazz band having a jam session, true ?

here you go. It is like a Jam session, don't you think? The only thing is: you've got to be a damn good musician to do a remarkable jam session...