Finding the Project Management Gene

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":

1. They have technical smarts
2. They are blessed with above-average emotional intelligence
3. They have good planning & execution skills
4. They are able to adapt to changing circumstances quickly
5. 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

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

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

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

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"

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

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.