Old, grumpy and agile – the ideal combination?

This is a thought that I have been struggling with for a while: Are agile methods working better for managers and developers "born agile", i.e. that was never exposed to more ‘waterfallish’ structured approaches, or is the real power of agile only reaped when you have exactly that background?

Last week my interest in the issue was resparked. I had a discussion about Scrum with the students in the e-business class that I lecture. It was really inspiring to see the eager contributions (not always the case, I must admit...) and the students' experience and opinions about Scrum. Nevertheless, I also felt that compared to when discussing agile principles with my colleagues (not all grumpy and old, but you get the idea...), we were missing some common ground and viewpoints that are useful having as a background when consciously deciding to work in an agile fashion on a project. Thus I wonder if those never exposed to such documentation-heavy methods miss out on something, even if we all agree agile methods are "better"?

I find it a bit hard to pinpoint and be specific about the relatively vague feeling/postulate. I’ll try with two, maybe relatively random, examples: If you have grown up with carefully designing an architecture before starting to code, you’ll know which parts to include in the “vertical part" of a broad prototype/first-sprint-end-version[1]. Or, if you have experienced the often large gaps in understanding of a formal specification, you can use that knowledge to document just the right stuff in your user stories - knowing when to formalize to clarify. That kind of knowledge, in my opinion, goes beyond just being "experience" - it is also tied to the more documentation-heavy approaches and how to work with the shortcomings of those.

It is also my opinion that, at this point in time, the vendor side of most projects is often more keen on working with agile methods than the customer side. In that regard I also think the grumpy old fellows have an easier time, knowing how to smooth things a bit out by providing the linkage between structured reporting and the measurement of progress in terms of pure increments of working code.

My preliminary conclusion is that currently it is certainly no disadvantage to have been exposed to more classical project management and software development methods before moving to agile. Rather the contrary. But, I also have a positive outlook towards more and more buyers of software projects specifically wanting to work using agile methods. When that happens I might end up just grumpy with no advantages of it at all. Well, I guess I can resort to thinking about how much better things were in "the good old days"[2] (well, not really - but "If you take away make-believe from the average man, you take away his happiness as well").

[1] - It is my strong opinion that the first deliverable should as broad as possible in terms of functionality, but as indicated in the above paragraph I think it also makes sense to select some narrow (and often tricky) parts of the solution for a full vertical proof-of-concept as early as possible. Selecting these is often more an art than a science, and my little fear is that this skill is not as well nurtured for the "born agile" colleagues that are currently graduating.

But I might be wrong and just "not getting it", because of my somewhat old-fashioned mindset... I also wonder if it is wise or misled to use sprint N for "architecture of X" or "design of X" and sprint N+1 for "implementing X"- isn't this just waterfall in disguise? That was a sidetrack (in a footnote!); maybe a post on that later.

[2] - Of course, being born in the late seventies, I don't know the really good old days, when everything actually was better. Or so I've heard.

Portfolio planning: Create storms, not forms

I said some time ago that strategic portfolio management goes beyond what is typically achieved in a project management office (in my 8th "brief tip" for project management). My best attempt at formulating this in a rememberable way comes here: Create storms, rather than forms.

I think better value from a project portfolio can come from creating storms - honest discussions between people that typically own the day-to-day business operations that the projects are about to change - than using very detailed sign off procedures and authorizations. Rather than requiring many people to sign off projects of a certain size, have them take part in the regular meeting that is the only place such projects can be authorized for initiation.

An important outcome of such meetings is which projects not to run and also to create visibility of the most important projects for senior management. Ask top management: "What are your current major running projects and which are the top priority ones?" Getting any kind of stuttering as a response is a big red warning light.

If you just take the form-based "PMO coordination" approach, there is a danger that all projects will just be administred - not prioritized. One useful way of visualizing projects can be as a radar, with distance showing the expected end date and the size of the dots showing the size of the project, possibly with sectors for business units. Over time, some rules of thumbs might evolve about how many major project the organization is able to digest, which types of projects require the most coordination across business units, etc.

A weak point of the method of de-facto giving the line management power to decide which projects to run, is that often only the needs of current customers will be heard. This is similar to Christensen's Innovators Dilemma. You may make your self obsolete through many incremental innovations of the status quo, that by them self make sense - but fail to capture big shifts. This is really a separate discussion, but one solution might be to separate early stage R&D projects both organizationally and from the project prioritization process.

A final word, maybe to avoid any unintended storms (!): Forms can also be useful. The most obvious example I can think of is that a suitable template, or form if you will, can contribute to getting the project owner to think in business case terms when arguing why it is a good idea to run just their project... And PMOs can of course be useful facilitators for the decision process. Also, I am not suggesting to get rid of documentation or preparation for the meetings, but I still think that the main point is valid: Prefer storms over forms, decisions over documentation, and prioritization over administration.

Those who can, do...

You have probably heard some variation over the saying: Those who can, do. Those who can't, teach. Those who can't teach, consult. I am actually going to complement my consulting by teaching the next semester, so I guess that puts me quite clearly in the "can't do quadrant"? :-)

Anyway: The subject I am going to teach is a 2nd year college course in computer science, focusing on XML and web technologies, at NITH in Oslo. The gig will be starting in January.

It might have been only a matter of time before I had to try this[1], with parents that are both teachers... Even so, it is only a thing I do a small portion of my time because I hope it will be energizing and meaningful. Or maybe it'll just be frustrating and make me feel old? I might post some of my experiences after the semester.

With the holiday season coming up I would also like to take the opportunity to wish you the best and suggest you make sure to really recharge those batteries that might be close to running out as everything must be finished in time for Christmas...

[1] - One might argue that I have tried a little bit already, as guest lecturing and training short courses is something I have done on the side both while I was a student myself and later.

Summarizing my brief tips for project managers

So, that was the 10 posts. Here are my 10 brief tips for successful project management summarized (each sentence links back to the individual post):

1. Do not forget that it is the people in the project teams that actually deliver successful projects
2. Be sure to use every chance throughout the project to manage expectations
3. Be sure to put conclusions in writing immediately, even if not using documentation heavy methods
4. You can never communicate too much as a project manager
5. Keep a close eye on risks throughout the project and use a visual risk log as a communication tool
6. Starting - not just planing, but actually doing - the most difficult tasks as early as possible increases the likelihood of a good result and minimizes the effect of a bad one
7. Establish checkpoints that you follow in each of your projects, even if operating in an agile way
8. As a project manager, try to add value beyond administering the project
9. Make sure that you have buy-in on all relevant levels, and reconfirm this as the project moves on
10. Try to look beyond the project, to ensure the project contributes to reaching the overall goals of the organization

When I look at it now, what do I feel – should I have changed something drastically? I think I might have created one specific post on goals. I think it is really important to have the goals clearly defined (and on the right level) and understood across project team and stakeholders. That is maybe buried a bit in the “managing expectations” heading in the current list of tips. Make sure to have it clearly visible in your mental checklist.

Apart from that and to be sure to communicate roles and responsibilities very clearly (and also to always work in stages or increments, but that is sort of given and an underlying assumption in everything that I have written so far, I think...) I am quite happy with the list as it has developed. But you might not be, and then the best way to show it would be leaving a comment. :-)

The always challenging question of summarizing it all in a sentence? Well, how about: Be proactive and care for your team, choose common sense rather than legal fights and have fun!?

Final brief tip, #10: Look beyond the project

I must admit that I love projects. I find them energizing and really enjoy going from the unavoidable feeling of uncertainty if it is feasible at all, to a successful delivery. I also like to be able to finish off, and then start a new one – with clean sheets (for the joy of Norwegian readers, I’d like to add a reference to Alf Prøysen, who came from a place close to my mother’s, at this point: “Du skal få en dag i mårå”, which I would say translates more or less to “You’ll have another chance tomorrow”).

Even if it you are like me and are happy about finishing off the project and then start a new one, possibly a different place and in a different field: I urge you to try to win the war, not only the battle… Thus my 10th and for now final tip is worded like this:

Try to look beyond the project, to ensure the project contributes to reaching the overall goals of the organization

You can be sure no-one will thank you for delivering on your formal mandate, if the product you delivered does not really leave behind anything valuable or useful when the project is terminated.

For me a key aspect of project management, as well as management in general, is to pursue continuous improvement, both within the project and across all projects of the company. The more mechanistic aspects of this, with Lessons Learned logs etc., are well covered in most project management methods. But it is of course even better if you can adjust course rapidly (agile, if you will…) as the project goes along, and that is as much a question of attitude as of hefty templates.

Another classical fight is the one between short terms requirements (“give me that functionality, and give it to me now!”) and long term demands of architecture and maybe even cleaning up some old mess. Again, trying to eat the elephant in smaller pieces is key – try to build architecture project by project and if you have a large code base (and they are never only pretty), leave it just that little bit better every day. Oh, and when estimating the cost of your next project: Make sure to estimate the required time and cost to improve architecture as you conduct the project.

I am considering writing a piece about project portfolio management, arguing that this is really more than what can be achieved in a project management office or similar structures. I hope to do this sometime before Christmas. Please come back to have a look. My next piece, though – and hopefully in just a few days, will be summarizing the brief tip series of posts.

Development in software business models – and the power of hindsight

When I recently was selecting a mail solution for my new company, I went for Google Apps. I did this after also considering a small business edition of Exchange, as well as just continuing to use the built in email service from my domain hosting provider that I already had up and running. Also my current client, i.e. my previous employer Inspera, has moved to Google Apps from an in-house Exchange solution, they just finished the transition last weekend.

These two decisions made me think back to what I wrote in my thesis on software business models in 2007 (part of my MTM degree, an MBA in technology management from NTNU, MIT Sloan and NHH - link to full foreword/abstract is provided for anyone interested):

…[even if] there is no “one size fits all” for business models in the software industry, if I had to place one bet on which business model innovation that will have most impact based on my findings, my decision would be clear: My money would be put on SaaS – on-demand subscription based software. Predicting paradigm shifts is a risky business, and especially so with shifts that have been predicted similarly without really happening before. Nevertheless, my take is that enough enabling factors have changed so even if it will not replace the traditional license, it may radically change the way software is sold, distributed and developed the coming years.

So the million dollar question is: Is this actually happening for mainstream applications for mainstream companies as we speak?

Extrapolating from the two samples (yep, two years since I last touched academia and reading the daily Dilbert since...) the conclusion has to be: “Sure”. On the other hand, I have also worked for some big companies over the last year that just wouldn't even start to consider Google Apps. But still, major changes in buying patterns often start with smaller companies and over time becomes an option also for the larger enterprises requiring time-tested and mature solutions.

Even if I feel the last two years have added support to my hypothesis of a possible “disruption from below” ala Christensen, I think the jury is still out on the question if SaaS will replace the traditional license based model as the dominant model at any point – or just be a supplement. (And to me financing a traditional license – making it look somewhat like a subscription – does not make it SaaS, by the way.) Cynics might also add that the predictions of net-PCs given in 1998 are not much different from the SaaS and “everything in the cloud” visions of today, they might argue that it has been coming in large scale “real soon now” for over ten years...

Reading the abstract two years after also drew my attention to another thing I wrote, that ...lines between data, applications, software and services can sometimes be blurry. This I at least think is even truer today than it was in 2007 – or to ask rhetorically: Is Twitter worth a zillion because of its software?

A twitter-er with no tweets...

Although I feel a certain degree of ambivalence towards the (near) real time aspect of Twitter, I have finally given in and registered - after one of my generally very insightful colleagues (a dedicated non-fan of Facebook, BTW) insisted it was very interesting and even useful.

I have no ambitions in the directions of real time updates of what I do (my life just isn't that interesting), but hope to take part in some interesting discussions.

My twitter ID is pmmonkey. Will probably keep my read-to-write ratio high going forward, but maybe time to post that virgin tweet now anyway...