The Agile Program Manager

Finding the Project Management Gene

2009-09-19T02:56:00.000-07:00

At Atlassian there's always a lot going on, and it's pretty challenging to keep up with (let alone try to coordinate) the different projects, initiatives, concepts, and campaigns that make up our rapidly-evolving portfolio of stuff. One of the cool things I've noticed here is that whenever a new cross-department effort is shaping up, different people will put up their hands to manage whatever piece needs supervising. The role of project manager doesn't really exist in a permanent way in most departments; it gets created as needed and evaporates quickly when the job is done. Of course, as with most things, some people are naturally better at it than others. Which led me to wonder - what makes a good project manager, especially in the absence of formal training?

To zoom in on the answer, let's look at one role at Atlassian - development manager. We have four of them, and their job is mostly project management (the rest consists of staff management, technical management, program manager heckling, and Thursday lunch football captaincy). But the dev managers don't really think of themselves as project managers; in fact they seem slightly offended whenever I absently refer to them as such. They are formerly-technical-people whose job is now to herd and protect teams of those-who-prefer-to-remain-technical. They are some of the best project managers I've seen, but how did that happen?

We've been talking recently at work about something we call "the product gene". My hypothesis in this post is that there are five factors you'll see in people who exhibit "the agile project management gene":

They have technical smarts
They are blessed with above-average emotional intelligence
They have good planning & execution skills
They are able to adapt to changing circumstances quickly
They seek feedback on their own performance and continually try to improve

Technical smarts - I don't think you need to have current technical expertise across every facet of the codebase you manage, but in most companies you need to understand all the concepts of software development to be able to guide the team through the estimation process and help them identify technical risks and issues. And at a company like Atlassian, you have to be pretty technical to get an interview for a cleaning job, let alone dev manager.

Emotional intelligence - whether you have a large, permanent team of direct reports, or your team members are loaned to you by a functional manager, or you're managing a distributed team, or you're working with contractors, you need to be scoring pretty high on the EQ scale to create a high performance team. I've known plenty of tech-savvy project managers who had very little awareness of their own interpersonal style, and/or weren't able to understand and facilitate the interrelations of their team members. If you can't do these things well, the project will very likely get ugly quickly and your team members will want out.

Planning & execution skills - not a lot of explanation needed here. It's perhaps the most fundamental part of the project management gene, but I don't think it's sufficient on its own.

Adaptability - this is clearly necessary in any agile dev role, but if the project manager can't adapt quickly, the team will either quickly outrun him/her or - worse - continue on its initial trajectory and miss the opportunity to optimise the project outcomes. Being agile and adaptive is contrary to classical project management training (where we are taught to define the project scope, stick to it as much as possible, and - if it is really unavoidable - deal with scope change by wielding our intimidating powers of change control process with great force). This is the area where I think having no project management training can be a distinct advantage.

Seeking feedback & improving - this is a common trait in anyone who is good at their job, in any field. It's a cornerstone of agile methodologies, and it ties in with Atlassian's company values too. I was surprised just yesterday when one of the dev managers wanted to follow up in detail on some feedback I'd given him, but I shouldn't have been. These guys are good.

So what do you think... are these the factors that make up the agile project management gene, or have I got it wrong?

Retrospectives from the Dance Floor

2009-08-09T00:09:00.000-07:00

Nothing beats a bit of quiet Sunday morning reflection for coming up with a few new insights into the spinning mirror ball of program management.

Some new projects look very sexy from all angles, but there might still be a good reason not to start them. We all know this, but depending where your blind spots are, that reason can be difficult to recognise. Especially if you're the person who came up with the awesome idea. The agile practice of a short investigation of the project or feature concept can really pay off here. If you're lucky, another stakeholder in the project will be smarter than you, so even if you can't see any showstopper risks after the investigative spike, they can. If you're really lucky, that stakeholder is also the project sponsor, so you have no choice but to agree with them and kill the project.

If everyone agrees that the seriously cool new project idea looks worthwhile after the spike, and you catch another thrilling glimpse of its magical possibilities, don't forget to pause and consider the benefits to the overall program. (This step is, after all, a core part of your job). The new project might cause detrimental knock-on impacts to existing projects and plans, even if its own immediate outcome is successful. A bit of detached scenario planning will help identify those impacts; think of all the possible outcomes of the project, and look at the likely effects of each outcome on your other projects and teams. Getting input from all the key stakeholders is crucial. (At most other companies I've worked at, where people like program managers and project managers weren't quite so passionate about the products we made, I rarely saw such problems of perspective. It's an interesting dilemma).

Finally, if you just can't bring yourself to kill a risky project idea so ruthlessly, you can put it on ice for a while. You never know, it might become viable later if conditions change. More likely, you'll end up having to let it go, but keeping it on the backburner and sneaking a little look at it every now and then might spark some other, better ideas.

Dates, and when to ignore them

2009-07-12T00:47:00.000-07:00

The thing about software projects is that sooner or later, they're supposed to be shipped out the door. Preferably sooner. This sounds easy - design some code, write it, test it, document it, and you're done. The traditional criteria for project success were that the software is delivered on time, and on budget, and meets the requirements for scope & quality.

Another way of thinking about project success is that the software must deliver functionality that your users want. This kind of thinking led to the rise of Agile development - deliver early & often, get customer feedback, embrace scope changes, and ship as soon as you have enough scope & quality to satisfy your users. Working out what 'enough' means can be as difficult as creating the software. Luckily, that's why we have product managers, and lots of other blogs written for and by them.

What happens if there is conflict within your organisation about the stickiness of the release date? Many companies have been trained to declare a release date months (or years) in advance, and then do whatever it takes to meet that date. Date-driven releases make sense in a number of scenarios:

* Your industry is bound by government regulations (e.g. medical software with fee and drug information that must be updated on certain dates each year)
* Your company has shareholders who view hitting release targets as one measure of company performance
* Your company has quarterly revenue expectations that rely on software releases shipping in that quarter
* Your product is affected by seasonal deadlines ("in stores now for Fathers' Day!")
* Your project is bound by date-related penalty clauses (a common occurrence for custom software solutions, but rare for shrinkwrapped software)
* You have heavy downstream dependencies that are expensive or impossible to move - such as limited integration windows with hardware components; large-scale training or marketing activities; heavily booked QA teams; or locked-in schedules for third-party CD & collateral printing.

If your company or project doesn't fall into any of these situations, how seriously do you need to take date slippages? If you're in the luxurious position of market leadership, it's a valid approach to give your development team more time to get the product right before shipping, even if that means the planned date has slipped once or more. Being a little relaxed about the date means less pressure on your teams, which means less burnout, better morale, and (in theory) a better product.

Which is all good until the competition catches up with you. So give your dev teams as much time as they need, but no more. And check your rearview and side mirrors often.

The Final Countdown

2009-06-10T10:12:00.001-07:00

At a certain point in every program, you start to count down the number of days left until the inevitable collision with that big, immovable deadline. It's a scary and exciting time. Months of work by many different teams are about to culminate in a single, pivotal moment - say, for example, in the form of live demos during the CEO's keynote speech at your company's first major user conference.

Interesting things happen during the final countdown. Teams move into hyperdrive - fueled by caffeine, pizza and cupcakes - and show how fast they really can sprint. Project managers start deploying special weapons and tactics to protect their teams from the onslaught of last-minute "oh just one more thing" requests. Program managers turn into pale, hovering, nail-biting wrecks, trying very hard not to interfere in absolutely everything.

There are hundreds of things we will need to do better next time (such as having more realistic expectations of velocity, learning curves, scope changes & dependencies; improving our inter-team and inter-contintental communications; introducing less than 14 new & unproven technologies into the cornerstone project; setting up the demo machines way earlier), but the one thing I wouldn't change is the amazing collaboration that happens when a whole company focuses on a single goal. We try to do this all the time, of course, but inevitably each team and department has different objectives throughout the year and it's easy to get siloed.

The last four weeks have been chaotic, stressful and exhausting, but it all came together on the day and we're pretty happy with the outcome. Watching 200 talented and dedicated people reach that goal together was awe-inspiring. Listening to customers talk about how they're going to use those new features to make their jobs easier was instantly rewarding. Now we're conducting post-mortems and coming up with those long, long lists of things to improve. This is the part of program management that I normally find kind of discouraging, but this time I can't wait to harness all those lessons learned into a bigger and better Phase 2.

Wiki: $5. Issue Tracker: $5. Agility: Priceless

2009-04-20T20:56:00.000-07:00

I've talked about the coolness of Confluence (Atlassian's enterprise wiki product) as a program management tool in a previous post. If you read that and thought "if only my company would shell out for a decent wiki..." or if you're frustrated with your current bug tracking tool, here's some news to make you happy.

This week you can buy a 5-user license for two of Atlassian's products - Confluence and JIRA - for $5 each. These are fully functional versions of JIRA (awesome issue tracker) and Confluence, including a year of support, and you can renew them for $5.

And if that's not enough to make your day, Atlassian is donating all proceeds to Room to Read, to help build libraries and schools for kids in developing nations. The offer is available until April 24. More info available at http://www.atlassian.com/starter/

Training - Now Available in "Lite"

2009-04-15T03:24:00.000-07:00

How do you provide useful training to technical managers in a timely, lightweight way? I don't have the perfect answer, but here are some ideas I've seen work well.

Book Club
We've been experimenting with this idea for the last several months at Atlassian. The engineering team leads & managers meet once a week on the downstairs sofas to discuss a few chapters of an Agile methodology book (we have upstairs sofas too, which are closer for most of us, but the ambience upstairs is lacking a certain je ne sais quoi) . We all read the selected chapters during the week, so at the meeting we can have a productive discussion, relating our particular experiences and issues to the material covered in the chapters. More often than not we go off on a tangent, but that doesn't matter - we learn a lot from either the book chapters or each other.

We appear to have so much fun at these book club meetings that now the product managers have started their own book club, in yet another incarnation of product management - engineering rivalry (give up PMs, you know you can't win).

The thing to remember with a Book Club is to build a backlog of compelling books (or articles), and have enough copies of them to go round. Sometimes we run out of material and pick something in a hurry... turns out this is not the shortcut to gaining popularity with your peers. Also, try finding books in a beta state that you can download hot off the virtual press. This is a great way to grab really current material, and gives you the chance to give feedback to the authors before the content is finalised. The Pragmatic Bookshelf is a good source for beta books.

Blog-a-thon
A variation on the book club, but can be played as an individual sport. Often requires fewer tree deaths too. Pick a topic you're interested in, search your blog subscriptions (or a handy site like Alltop, or, heck, the whole Internet) for relevant posts, spend an afternoon reading through those posts, and share the links to the best articles with your team. The key ingredients here are: 1 beanbag, 1 dark cosy corner, 1 set of headphones, and 2-3 hours of uninterrupted time. You might want to schedule regular presentations of your findings to your team mates - this creates a deadline for getting your reading done, ensures that you share your learning, and will likely inspire others to stage their own fabulous blog-a-thons. You'll end up with an awesome selection of quality blogs to add to your collection.

Practical Exercises
Sometimes the training you're interested in requires something more hands-on than simply reading about stuff. You may be teaching yourself a new programming language, or working though a strategic planning book, or learning how to read a balance sheet, or following up on a negotiation course. These kinds of training activities need regular practice, or you'll quickly lose your mental muscle. Rope in some colleagues and book in a few hours each week to work through the material together. A bit of friendly peer pressure will help keep you on track. This is particularly useful if you've invested in an expensive and time-consuming training course for yourself or your team - you'll get the most out of it by following up with regular, ongoing practical work when you're back in the office. Our clever QA Team has been doing this after attending a week-long offsite programming course. It's a great learning & team-building win for them, and very reassuring for me (and the Finance team).

Whatever method you choose, the ideal outcome is lasting individual and organisational improvement. Distilling some common themes from the examples above, aim for:

small chunks of targeted learning
on relevant and engaging topics
at planned, regular times
sharing the results with your peers.

By mixing up a few different approaches and keeping the content fresh, I bet you'll quietly establish a culture of continuous learning and sharing in your organisation faster than I can read War and Peace, Book I*.

*Not much of a challenge, since I've been stuck on Chapter IV for the last 8 years. Sorry Leo.

Going Agile with your Program Risks

2009-03-24T02:17:00.000-07:00

You're managing a program. You've got risks. How do you identify, plan for, and track those risks in an agile way?

A bit of inspiration from Agile development can help. Think of risk planning like product release planning. You have a high-level plan for the release, made up of a series of iterations. You know a lot more about the next few iterations than you do about the later stages of the release, so your next 1-2 iteration plans are more detailed and accurate than the overall release plan.

For your program, you can create a high-level risk register - complete with probability & impact scores and mitigation plans - at the start of the program. You can review and update this every month or so, similar to a release plan. It won't be accurate all the time, but it's a good source of ideas and a reassuringly scary reminder of what could still go wrong in the future. I like to use risk categories like Investment, Process, Schedule, Scope, Technology, Equipment, Customer or Sponsor, Staff, and Communications:

OK, so far this is not that agile. But for day-to-day risk management you can create a simple Top 10 risk list. (I first came across this concept nearly 10 years ago in Steve McConnell's excellent book Rapid Development). You can use the Top 10 list like an iteration plan - it's more current and less formal than the big risk register, it's easy for everyone on the team to read and understand, and it drives your conversations and actions for the day or week:

You might decide you don't need to create the high-level risk register at all, and just work off the Top 10 (or 5 or 20) Risks list that you check and update frequently. I've found the risk register comes in handy in two scenarios:

1. You wake up at 3am on four consecutive nights thinking "I know there are more risks out there. I feel like I'm missing something big".
2. That day the new executive asks "So where's the risk assessment for this program? What do you mean, you just have a Top 10?"

In both of these situations, you'll probably feel better if you've gone through the exercise of creating a more formal risk register - especially if you set aside a half or full day to really tap into your most creative worst-case-scenario mode. Get the program team to participate in a risk brainstorming session, or at least make sure they review and comment on it. This way the risk register can serve as a placeholder for way-down-the-track (and/or lunatic-fringe) risks, as well as a source of mitigation ideas for your constantly-changing Top 10.

An Inconvenient Empathy

2009-03-10T02:00:00.000-07:00

A few years ago I was a risk-averse project manager with a pretty big team of developers and responsibility for the company's cash-cow product. This product was similar to many software cash-cows - a large number of globally distributed users; a growing list of features being used in all kinds of ways we never intended; and a complex legacy codebase. There were other product teams at this company, but there wasn't much integration between our products at that stage. Getting two of our products to run on the same machine was considered an interesting but academic exercise, and we were all mildly impressed whenever one of the QA or Support guys actually managed it. My care factor for the products I wasn't managing was, on average, close to zero.

Now as a program manager I find myself on the other side of the fence, responsible for coaxing risk-averse project managers to integrate a bunch of shared features in their products to improve interoperability across our product suite. I know what we're asking them to do will add complexity to their code, will require effort to maintain, and is development time that could be spent on cool and unique product-specific features. If someone was asking me to do this five years ago, I would have quickly come up with 100 reasons not to take on the extra work, and may have spent more than one drive home from the office wishing that annoying program-y person would spot a piano falling from the sky and patiently wait under it.

So it's pretty weird to be looking at it from over here. I am really excited about the benefits of the cross-product features - a more consistent experience for our users, more code reuse and standardisation, more communication and idea-sharing between product teams. But I still feel for the project managers, and I would like to publicly thank them for not telling me to go stand under a falling piano. Well not out loud anyway. Thanks guys :-)

At-a-Glance Release Reports

2009-02-24T01:46:00.000-08:00

No doubt one of your favourite program management responsibilities is roll-up reporting of all the projects in your organisation. Depending on the size of the company, this can mean you might be tracking a handful of projects, or you might be tracking hundreds of them. Setting up a simple wiki page with a high-level Gantt chart view and a table with some more details can be an effective way to present current status of these projects.

For charts I've been very happily using OmniPlan recently, but I will admit that in my ignorant, pre-Mac past I was an MS Project fangirl. Any project planning tool that has baselining functionality will do the trick. I try to minimise my use of Gantt charts because they are usually too heavyweight for most agile projects. At the program reporting level however, the feedback I've gathered is that people across the company find charts useful for giving a quick visual on when we're likely to release all our products (vs. when we thought we'd release them). This is especially true for everyone downstream of the Development teams, like the Product Marketing guys planning the launch activities, the Support team needing training on the new features, and the VP Sales who'll need to plan her next investment property purchase.

In the chart I'm showing Original Target (lighter shade) and Expected (darker shade) release dates. I use the length of the horizontal bar to indicate the estimated uncertainty in the release date range, rather than force a misleadingly precise single date when we don't have one yet. I only expose the "Actual End" and "Planned End" columns for simplicity, but obviously I'm setting the bar length via the (hidden) "Planned Start" and "Actual Start" columns. And I use the baseline feature to achieve those Original and Expected shades.

My informal (but highly reliable) reporting survey also showed that people want a few more details to support the visual snapshot in the chart. So in the table view, status is indicated by a colour, with a column for some notes, a "dogfood" column to remind everyone to do internal user testing (in addition to regular QA activities), a summary of the top features of the project with links to roadmaps and release notes, and the date of the last release of the product for reference. We currently define the status colours like this:

GREEN means on track
YELLOW means the target date is at risk
RED means the target date will be missed unless something changes.

but of course these can be defined in any way that suits you and your audience. The key to reducing confusion is to define the status indicators clearly and apply them consistently across projects and over time.

I update the chart and the table each week, based on the status updates from each of the project team leads/managers. Every couple of weeks I think "I should really automate this", but each time a nerdy little voice in my head says "But this manual exercise forces you to stay current with the status & issues of each project". Still sorting that out...

Wikis Make Programs More Agile

2009-02-15T23:15:00.000-08:00

Life gets a lot easier when you work at a company that has embraced the miracle of wikis in its daily operations. (It's even better when that company makes the wiki it uses, because you get to try out new features, give instant feedback, and maybe suggest an enhancement or two).

We use Confluence for pretty much everything. It serves as our intranet, our network folder system, our word processing tool, our spreadsheet tool, and our project management tool. We all have a lot fewer emails to process every day, because almost all conversations are carried out on the wiki. This requires a great deal of openness, and it wouldn't suit many company cultures, but you can still implement a wiki just for your program team or department and enjoy a lot of the advantages.

For each of my programs, the first thing I do is create a new wiki page, which I use as a lightweight version of a program plan. It might contain:

A brief program mission statement
A summary of the background, scope & milestones
Top 10 risks & issues
Current actions (with owners & due dates)
Top 5 assumptions
A snapshot of the program schedule
A dependency and/or feature matrix

This may not sound too agile yet, but the difference is that as a wiki page:

Everyone can view it
Anyone can edit it or add a comment (and you get an automatic history of changes)
You can add clear headings, nice tables, colours, images, videos, links, and anything else you want to do to customise it.
It's all on one scrollable, attractive page. No more big boring tree-killers!

Those first two points are very powerful. Your communication challenges are drastically reduced with a central program page that everyone can view and edit. This is especially true for remote teams, large organisations, and rapidly changing programs. No more email threads with hundreds of cc's. No more "Hey do I have the latest version of the plan?" or the dreaded "So what's this program for again?"

Once I have the home page set up, I create and link to child pages with more details where needed. These child pages might include a more extensive risk assessment with mitigation plans, detailed meeting minutes, sub-project pages, specific program event plans, roles & responsibilities, detailed program charter information, etc. Some programs might be small enough that I don't need any child pages. Other are so extensive that I'll start with a number of child pages, and the team and I will keep adding more.

The beauty of the wiki is that you can have a nice simple home page for each program - where you keep the central information you want everyone to know - and scale it with more linked child pages for the more specialised information that may not be relevant to everyone.

Next up, more of my favourite wiki solutions for agile programs, including the Release Dashboard, the Benefits Register, and easy executive management reports.

Breaking the Program Management Ice

2009-02-07T21:02:00.000-08:00

Many project, program and portfolio managers face the challenge of introducing agile concepts and practices to a traditional organisation. This is the topic of many great blogs, including a series of posts by Dean Leffingwell on Enterprise Agility.

When I joined Atlassian I had the opposite problem. I was hired to do program management in a company that has been developing great software products in a relatively lean & agile way since its inception. There was some skepticism around the whole idea of program management - some people were worried (understandably) that it would mean more processes and an extra layer of management goo that would just slow everything down. On the other hand, there was a pretty clear need for something like program management, as the company was doing more and more cross-product development and someone needed to play the role of conductor.

Obviously, killing the agility by introducing a set of standard program management tools and processes would have been a bad choice. But some things had to be done differently, or I wouldn't have made it past probation. Luckily for me, there were a few obvious clues as to how I might, ever so carefully, proceed:

1. Atlassian runs on a wiki (Confluence, which we also make... end of today's plug)
2. Everyone who works at Atlassian is smart
3. Smart people tend to have well-considered opinions, which they are usually happy to share
4. I had read The First 90 Days when starting my last job, and remembered Michael Watkins' excellent advice about not making changes until you've done a lot of observing and listening.

These clues led me to an approach, which I'm still adjusting and refining, but which has so far not resulted in total disaster:

a) I manage all our programs with wiki pages, not offline documents. This is standard procedure for every function at Atlassian (Development, Product Management, Marketing, HR, IT, etc), and it works brilliantly for projects and programs. My program plans are visible to everyone in the company and are constantly updated, by me and others on the various project teams.

b) I ask for feedback from the people involved in my programs, to see where I can improve and what I could do differently. These guys have great ideas, and they're not shy about sharing them. (Note to self: could probably do another quick round of feedback this month).

c) I make the assumption that most people want the bigger picture (the program, in this case) to succeed. People operate within their own teams and projects day-to-day, and that is where their primary interest lies. But by making sure people know what the program goals are (and why), I generally find that they are willing to adjust their own project goals to get with the program, so to speak.

d) I try to grow & nurture relationships with the people participating in the program - the CEOs, product managers, project leads, architects, team members. I don't mean those insincere, distracted relationships. I mean actually getting to know individuals, helping them out when I can, and not forcefeeding them with my own agenda. This is the part I enjoy the most, and the fact that it leads to better program outcomes (often via point c above) is a bonus.

Well that was more high-level than I intended, but stay tuned. In future posts I'll talk more specifically about using wikis and other lightweight tools to manage programs in an agile way.

The Baking Manifesto Part IV

2009-01-31T21:45:00.000-08:00

Finally we're up to the last, and most important, value in the Baking Manifesto:

Delicious results your customers will love, over Aunt Mabel's Christmas pudding

One of the things that puzzles me about Christmas is how the Christmas pudding is still part of the ritual. Growing up in Australia, where Christmas happens in the middle of summer, we still had the traditional northern-hemisphere hot roast turkey and baked vegetables for lunch. Crazy. These days I can happily report that many Australian families like mine now head straight for the fishmarkets and serve up a fabulous cold lunch of fresh seafood, crisp salads, and cold ham or turkey, instead of the hot roast.

But in my family, we still can't let go of the pudding. It's a winter dessert, and there are so many better choices available (fresh mangoes, strawberries & nectarines in a salad; a lovely chilled cheesecake; premium ice cream with homemade chocolate sauce and more fruit...), but still it appears on the table every Christmas Day. I've called for its demise but I always get outvoted. It doesn't even taste very good in my baking-elitist opinion.

What does this have to do with program management? Well, it took me several years to realise that the project charter I started out with at the beginning of a new project may not be the ideal scope & purpose for the project halfway through, or even towards the end. I found it all too easy to get wrapped up in the original goals, and the performance of my team, and the thousands of details that needed to be managed along the way. Sometimes we wouldn't have much contact with the end-customer until we got to beta testing, and in waterfall-ish projects it is extremely difficult to change direction at that point, once the customer feedback starts rolling in.

Eventually I realised the limitations of this approach, and started to think much more about what our customers really wanted from the software my team was delivering. I started suggesting some ideas to the product managers, and generally being a lot more helpful (much to their surprise) when they wanted to introduce changes to my projects. In agile environments this behaviour is a way of life, and I enjoy it much more. It's more difficult, because you have to be more broad-minded and adaptable, but I've found it results in software that generates much more positive feedback from customers, and that your whole team is much prouder to have worked on.

Keeping customer value in mind is vital at the program level, where you are responsible for producing strategic benefits from your company's investments. It is tough to keep coordinating the many changing parts of the program without losing momentum, especially as the reworking of one project's mission will almost certainly impact the other projects in the program. However, if you and the product managers are making the right choices, your customers will be delighted. Those delighted customers will result in revenue gains and a great reputation for your products. And once that happens, no one will miss Aunt Mabel's pudding.

The Baking Manifesto Part III

2009-01-17T21:16:00.000-08:00

We've covered "Collaboration and creativity over silos and cookie-cutting", and "Trust and a light touch over frequent temperature checks and overmixing". Now it's time to look at the third value of the Baking Manifesto:

Adapting to changing conditions over following a recipe

Allowing for change is the fundamental principle of the Agile methodology for software projects, and there's no reason you can't apply it at the program level as well. If the projects making up your program are embracing the agile values, then you'll definitely need to throw away your reliable program recipe, or you'll be one frustrated baker.

Mike Cohn sums it up nicely in his book "Agile Estimating and Planning" when he says "Knowing that a plan can be revised at the start of the next iteration shifts a team's focus from creating a perfect plan (an impossible goal) to creating a plan that's useful right now." You can use exactly the same approach for the program. You know that the various projects within the program are likely to change. You know what the status of these projects is now, and you should have a pretty good understanding of the key risks (those with both high probability and high impact). Once the project teams are working to the currently-useful program plan, you can look ahead and start to sketch out a few contingency plans for each of the high-risk areas of the sub-projects, and for the dependencies between the sub-projects.

You can cater for the uncertainty in your currently-useful program schedule by adding some extra project iterations as buffers, or you can create a few different versions of the schedule based on various worst-case scenarios. Start early preparations for enacting the contingency plans (e.g. investigate the feasibility of the different resourcing options you and your team have thought of; test all the assumptions that have been made about must-have vs nice-to-have program scope; probe those rigid project dependencies to see if they might actually have a bit of give, now that more is known about the program). It's best to do this at regular intervals throughout the program, rather than waiting until the inky shadow of the next giant risk comes creeping across your desk. But at the same time, you don't want to spend so much time drafting alternative plans that you neglect to manage the current, useful plan.

Having a few alternative plans in your apron pocket will get you in the mindset for expecting change, and being ready to deal with it. These contingency plans will need revision if and when the risks turn into real issues, but that's ok. The key thing you want is an early acceptance from yourself and your program stakeholders that the plan is likely to change, and that when it does you'll be ready to adapt quickly. You'll be dealing with all the changes that will happen in each project, plus the extra level of changes to the program itself. That requires a lot more flexibility than a single recipe, and the best way to manage that successfully is to always be ready to adjust quantities, substitute ingredients, and switch pans at a moment's notice.

In the next post we'll discuss the final value in the Baking Manifesto: "Delicious results your customers will love, over Aunt Mabel's Christmas pudding" (names have been changed to protect sensitive family members).

The Baking Manifesto Part II

2009-01-11T19:23:00.000-08:00

In my previous post, I introduced the Baking Manifesto - a set of 4 values inspired by the Agile Manifesto and, yes, baking. I briefly covered the first value "Collaboration and creativity over silos and cookie-cutting". Now for the second value...

Trust and a light touch over frequent temperature checks and thorough mixing

A well-known principle of baking is to not open the oven door too many times while your cake is baking. Doing so will cause the temperature to vary, and the cake will not rise evenly. Slamming the oven door after checking the cake is the ultimate "don't" - air will escape from the batter and your beautiful chocolate sponge or tangy moist lemon cake will implode to form a crater you could lose a Mars rover in.

The same goes for programs. If you're running a large program, there will most likely be a number of project managers managing parts of the program and reporting status, risks & issues to you. Let's assume you have a couple of senior-level project managers and one or two newbies. You could spend all of your time taking the temperature of each project - especially those run by the newbies - throughout the program, so you don't have to worry about someone taking a wrong step and jeopardising the program. You could go around slamming oven doors and rattling pans when you're not happy with progress, but that definitely won't have any sustainable positive effects on team morale or the status of the program.

Instead, try setting up some guidelines for everyone at the start of the program - including example reports, registers, etc - then gather the project managers together for regular status sharing sessions. You're trying to be agile, so there shouldn't be a huge stack of documents to wade through each meeting. Each project manager should be presenting a brief synopsis of their project - actual status compared with planned; the top 3 - 5 risks and issues; mitigation plans; and any other relevant news.

Trust your project managers to own their parts of the program and do a great job. A little bit of competitiveness is a common trait in good project managers, and they will rise to the challenge. Their job is to know a lot more than you about the details of each project. Coach the newbies during the early phases of the program, then step back a bit and let them test their wings. They will learn from what the seniors present and discuss, and you can apply a light guiding touch to both newbies and seniors as needed throughout the program. Of course, if you have an underperforming project manager, you'll need to step in and provide a greater level of mentoring (or more) to get them back on track - a topic for another day. But if your organisation is hiring the right talent, even the most junior project managers will quickly learn from their own mistakes, develop their own unique style and approach, and evolve into competent, experienced project managers before your eyes.

Overmixing is another baking "don't". It's tempting to keep on stirring until there are no more lumps, but that just makes for tough muffins. In the same way, keep your program meetings to a minimum, in terms of both participants and frequency. If you have a distributed team, it makes sense to get everyone together for a regular videoconference, so they can have some valuable face-to-virtual-face time. But if your teams are colocated, you should be able to get by with just the project managers attending the meetings, and maybe a senior tech lead or architect. Choose the frequency of the status meeting in accordance with the expected duration of the program. If it's a 12-month (or longer) program, every two or four weeks is a good frequency for status meetings. If it's a 3-month program, weekly meetings make sense.

Obviously you can't step so far back that the program goes off the rails. I tend to take ad-hoc deeper dives with individual project managers in between the main status meetings, especially if I'm concerned about a particular area. Or I'll set up quick weekly checkpoints for the high-risk or critical-path projects, to help identify and remove obstacles.

Trusting in your team and keeping your touch light will not only help your project managers own their projects and manage them with confidence; it will leave you more time to do the program management work you need to be doing - such as assessing the strategic value of your programs; keeping your stakeholders informed and engaged; and co-ordinating the dependencies between projects.

The Baking Manifesto

2009-01-02T21:02:00.000-08:00

Welcome to The Agile Program Manager's inaugural blog post. What makes this blog different to those other agile program management blogs? One word - baking. Today I present the guiding principles of my project & program management career, neatly captured in the Baking Manifesto. Inspired by the well-known Agile Manifesto, these are the core values I've been forming and adapting over the past eight years to boost the success of my software projects and programs.

Collaboration and creativity over silos and cookie-cutting
Trust and a light touch over frequent temperature checks and thorough mixing
Adapting to changing conditions over following a recipe
Delicious results your customers will love over Aunt Mabel's Christmas pudding

That is, while there is value in the items on the right for some programs, I value the items on the left more.

I know what you're thinking. "Is this just another lame analogy, or are there useful tips and lessons in the Baking Manifesto that could actually help me?" Read on!

Collaboration and creativity over silos and cookie-cutting

Years ago I knew of a project manager who spent most of his day staring at his computer screen, making infinitesimal adjustments to his project's Gantt chart until it was time to go home. He was rarely seen talking to the developers on his team, or to anyone else. His schedule may have been perfectly correct, but since he skipped over the part where you ask the team for their input in creating the schedule; omitted to tell them about the tasks they should be working on; and forgot to share any status updates with management, the team, or the customer, the schedule was useless. The project failed, and the project manager was politely shown the door.

Collaboration is one of the most important skills you'll need if you want to be a good project manager. To move up to program management, it is essential. The more you seek input from your team, your peers, your sponsors, your managers, and your customers, the stronger your project's performance will be. Collaboration helps establish buy-in to your project, makes your plans more accurate now and more adaptable later, builds positive relationships that will be helpful in future, and generates ideas you would not have thought of on your own. You can ask your team members for their opinions and still be a strong leader. You can confer with your peers and still be the guy in charge of the project. Too shy to collaborate? Ask your manager for specific communications training and support. Once you step away from the Gantt chart and start talking to people, you'll find out much more about how your projects are really going, and you'll also have a lot more fun.

Creativity might be seen as contrary to the disciplines of project- and program-management. If you've studied for the Project Management Institute's PMP Exam, or read their Standard for Program Management, you'll know how much value is placed on rote-learning the knowledge areas, process groups, inputs, outputs, tools, techniques.... I'm not saying all that stuff is bad - I think it provides a decent basic framework - but without a nice thick layer of creative thinking and experimentation on top of your textbook knowledge, you'll find yourself taking the same approach for each new project, managing your team in the same old way year after year, and submitting the same tired project reports until not even the CFO wants to read them anymore. Where's the flavour explosion in that?

So try to mix it up as often as possible, and maximise the chances of new ideas sprouting. Throw away those stodgy risk and change register templates, trial a new scheduling tool, send yourself off to a funky user conference, talk to your customers, subscribe to a new blog. And, just like collaborating, that generous frosting of creativity will make work a lot more fun. Seriously.

Time to whip up a batch of blueberry pancakes now, but in my next post we'll look at the second value in the Baking Manifesto - "Trust and a light touch over frequent temperature checks and thorough mixing". In the meantime, may your pastry be light and your egg wash golden.