Archive for December, 2009

Reading Tip: Lean and Portfolio Management

Just a brief reading tip today: ‘Lean and Portfolio Management: A Winning Combination in Trying Times’. (Currently, you can download it for free at the link given. Probably for a few days only!)

Here’s the abstract: Struggling with the age-old challenge of too much demand and not enough time and resources to do it all? We all know what the solution is: focus on those things that yield the greatest value for your organization. Fortunately, two major methodologies — portfolio management and lean — have emerged over the past decade that can help you find and maintain that focus. But what if you could take these two proven approaches and bring them together? Would it work? This is the challenge that the author of this Executive Report sets out to investigate.

I really liked the report – a nice read, triggering a lot of thoughts. I’ll probably touch on it again in later posts.

This is one of several really interesting papers on Agile Project Management and Portfolio Management offered on the website of the Cutter Consortium. Most materials are for fee. I recently found another pretty good one. Here is the Summary of ‘The Lean-Agile PMO: Using Lean Thinking to Accelerate Agile Project Delivery’. I am not sure if the full report is still available for free.

Happy reading.

PS – I have no connection whatsoever to the Cutter Consortium ;)

December 30, 2009 at 15:35 Leave a comment

Intelligent Disobedience

There is currently an interesting discussion going on at LinkedIn about a Computerworld article called ‘Intelligent Disobedience’. If you have a minute in-between Christmas panic shopping attacks and shoveling snow, it’s worth a look.

The author (Gopal K. Kapur) states ‘Discussions with project managers about the key causes of failed and challenged projects always raise two primary issues: half-baked or harebrained ideas becoming projects, and excessive scope creep.’ He then draws an interesting analogy between a blind person (sponsor) and their guiding dog (the Project Manager). Aaaahhh… this could be misread! The focus there is NOT the sponsor being blind, but the dog’s behavior ;) The dog needs to disobey in certain situations (i.e., don’t cross the street even if the master says so) in order to protect its master’s health. For me this is yet another case for the modern PM role, which is moving a lot closer to the business.

You can tell from the comments on the LinkedIn discussion that sponsors / customers coming up with not-so-grand or grand but half-baked ideas is quite a common phenomenon. We’ve all been there, haven’t we. As some comments point out, some of the PM disciplines like change management and particularly risk management can be of great value to handle such situations.  And of course, experience helps you dealing with such rather delicate situations. I think it is very important to approach these kinds of suggestions with an open mind. In the end, this is about innovation! Maybe this is a good thought, and all it now needs is a bit of tweaking. It would certainly not be wise to just turn something down because it seems complex at first or ‘just’ because it means changes to your projects. After all, projects are undertaken to gain business value! (And there is this thing called agile Project Management that has been designed to solve a lot of these issues and is proven to be effective in in rapidly changing, innovative environments.)

December 22, 2009 at 21:21 Leave a comment

The agile PMO – an oxymoron?

With Scrum and other agile project management frameworks spreading more and more across the industry, there is also a certain maturing process happening: If you have a few scrum projects ‘to test the waters’ in your company, not a big deal. Once you fully commit to agilizing ;) your project portfolio, you’ll come across issues like:

‘Is there still a need for a Project Management Office (PMO)? And if so, how on earth can this fit with the self-organization and minimum-interference approach of Scrum?’

I thought a lot about this in the past weeks, gathered all my thoughts in a little mindmap, and am sharing the key thoughts with you today.

For a little fun at the start, have a look at The Biggest Little List of Oxymorons Online! Agile PMO is not in there yet, and maybe there’s no need to submit it. I believe that there is still value in having a PMO, even in times of Scrum&Co.

I’ll touch briefly on both sides of the Portfolio Management as suggested in the Portfolio Management Guidance by Craig Kilford:

  • Project Portfolio Definition – investing in the RIGHT projects
  • Project Portfolio Delivery – making sure projects are done the RIGHT WAY

Regardless of the project management approach applied, you as the owning organization still want to ensure you’re investing your resources into the RIGHT projects, i.e. the need to apply Project Portfolio Definition techniques (strategic alignment, categorization, prioritization, based on business value, financially and non-financially). I’d see no big difference here compared to the ‘classic’ approach, the same rigor should be applied when it comes to project appraisal and authorization, based on a compelling business case. Keep in mind, there is nothing in Scrum that prevents you from developing software that is not needed (if only the Product Owner thinks so).

Once your authorized projects are up and running, you’re entering the Portfolio Delivery cycle, and you’ll want to be up-to-date about the status of upcoming major milestones / releases, key impediments and risks that cannot be resolved/mitigated within the individual teams, etc.

For impediments and risks – all that lies within the team boundaries and can be resolved there should stay there. Impediments and risks that span across teams could and should be escalated to from the Scrum teams, so that the PMO can get organization-wide issues out of the way. In addition on the risk side, risks should also proactively be identified and managed across projects, as a function of the PMO.

When it comes to reporting, you’ll need to start looking at the iron triangle between time, cost, and functionality. Typically, time and cost will be fixed, with functionality somewhat flexed, as the GOAL is fixed but not the exact detailed features to get there. This will provide you a first clue where to start. A few ideas for information to gather at the end of sprints below:

  • Overall RAG status for upcoming releases
  • End-of-sprint report
  • Release Burndown Bar
  • Impediment chart, particularly any impediments that could not be resolved within the team
  • Identified risks that impact other projects, too

And this is where I’d probably stop. Minimize the overhead as much as you can, keep it simple and reuse artifacts created by the team anyway as much as possible. And remember, WITHIN Sprints, this is all a black box to everyone outside the team! No interference except the team specifically asks you for it. If you’re too curious, you can ask the team to observe (silently!!) their Daily Scrums, but that’s it.

I’d be careful when it comes to comparing velocity across teams. You’ll have to be cautious not to compare apple with pears, and furthermore you could introduce a sense of competition that might be counter-productive. This leads us to standards:

As one of the underlying philosophies of Scrum is a team that organizes itself the way it works best for this respective team, one should generally be very careful when it comes to standardizing.
However, once you have a certain number of projects running, a certain level of standardization will help you to ease the overarching functions. A few examples:

  • Use a standard environment for team collab spaces / wiki sites, e.g. provide a standard server, but allow the team to structure and fill their space as it fits best.
  • You COULD standardize story points, i.e. define a typical “5” story points user story, that everyone can relate to. Use with caution as this smooths the way to compare velocity across teams (see my comment above).
  • If you’re thinking about standardizing things like reporting or minimum requirements for tasks boards, starting with a ‘best of the breed’ approach would be wise. As a rule of thumb when it comes to standards: Always bottom-up, never top-down.

The last area where a PMO can add a lot of value is in a facilitator role to encourage the sharing of knowledge and experiences across teams. The PMO could for instance suggest rotations across teams, informal meetings between ScrumMasters, and so on.

To get an indication how the change process (i.e. Scrum adoption level) is going, the PMO could sit together with ScrumMasters from time to time (I’d say no more often than once or twice a year) and go through one of these Scrum Checklists that are available online. This will give you clues which areas are working really well already, and where further improvements could be made.

That’s it for now. I’d love to hear your thoughts and experiences. And a little health warning: This is just a collection of thoughts and not a scientific paper ;)

December 18, 2009 at 11:31 3 comments

ScrumMaster Training

After reading a lot about agile and Scrum, I attended a two-day ‘Certified ScrumMaster’ training class in Hannover last week. On the ROTaMI (Return of Time and Money Invested) scale, this course scored pretty high.

It was really helpful to reflect the core concepts and discuss them with other project managers, developers, software architects and of course the trainer. Key take-away: Most of the Scrum ‘standards’ are rather straightforward. The key are not sophisticated artifacts/tools/process flows but being able to interact with the team, nurture and support it and get together into the Flow. The changed underlying philosophy (empowering the team, encouraging exploration and changes) for the projects means significant changes for the role a PMO should play, and importantly, how.

B.t.w. now I am 100% sure that there is really no need for a PM in a Scrum project ;) I’m really looking forward to applying all of this in real-life projects!

December 14, 2009 at 14:36 Leave a comment

Scrum … and what happens to the Project Manager

In preparation for the course next week, I started to read the recommended book “Scrum – Agiles Projektmanagement erfolgreich einsetzen”.

So far, I can only recommend it (well, it helps if you understand German ;). It is really down-to-earth, with a lot of practical advice. It is useful as a starter, and it also contains advanced topics like applying Scrum for larger projects, distributed teams, and so on.

I had a few aha moments already. So far, I assumed the ScrumMaster role is the one closest to the ‘traditional’ PM role. However, it seems the Product Owner (mostly together with the team) owns a lot of the traditional PM territory: Scope, Time, Cost, Risk Management, etc. At the same time, the Product Owner needs a deep understanding of the product being developed and the used technology. The ScrumMaster is really more of a facilitator and ‘guardian’ of the Scrum process and mindset.

And to revise the ‘where’s the PM’ discussion, I tend to agree with the author: Based on these roles, there is no need for a Project Manager any more. Classic Project Management functions are distributed across the defined Scrum roles, and most importantly: The team collectively carries a lot of responsibility.

Still, no need to panic for all the PMs out there: First of all, a lot of the soft skills and experiences gained so far will be very valuable in any project, Scrum or not. Secondly, good news for all PMs who like a challenge and love to learn new stuff from time to time. And thirdly: There’ll probably still be a lot of un-Scrumish projects out there!

And a little outlook into the next posts. What has been bugging me for a while is the following: Assume Scrum is a good fit for many of your projects, and your organization was successful in making the shift towards agile project management. How does this affect / change the role of your Project Management Office (PMO)? Plus, I owe you the second part of ‘The Myth of Managing Change’.

Happy weekend!

December 4, 2009 at 22:31 Leave a comment

I caught the Agile virus

I’ve been reading stuff and discussing the agile developments for a while. After years of working in virtual teams, spread across the globe, under a very strict regime, this agile mindset somehow appeals to me ;) And even if you don’t follow e.g. the Scrum rules to the letter, there are elements that surely could be applied to a lot of projects (not only in the software space) to make them more successful.

So… I’ll attend a Scrum Master certification class next week. Really looking forward to it. I’ll let you know how it went.

December 1, 2009 at 15:43 Leave a comment

December 2009

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 5 other followers