I have no idea what I’m doing.

I was staring at the computer screen feeling frustrated, anxious, and stuck.

How am I supposed to plan a project when I don’t know in detail what we’re expected to deliver? How am I supposed to know the cost and resources required? What do you mean we can’t extend the deadline or increase the costs even if the requirements change??

A year ago I was assigned for a project that I was expected to plan and lead by following agile project management principles, techniques and methodology. Have I managed high level projects before? Oh yes, love it! The problem was that at that point I didn’t even know what agile was. And when I did…

Oh how I hated agile. 

It defied my logic. It defied all the past experience and skills I had gained during the years running projects. Every fiber of my body was against it. I was thrown into a situation where I felt confused, incompetent and stupid.

But then I did what I always do: I took a deep breath, calmed down and saw it as an opportunity for growth. Not as a threat to my self-worth.

So I was brilliant and smashed it?

Ha.

Absolutely not. 

I was dreadful, trying to scrape my way through the milestones. Trying not to disappoint anyone. Trying to figure out everything on my own – a big mistake.

That’s why I want to share with you the painful lessons I learned during the past year running my first ever agile project so you’ll be able to avoid the same errors I did.

7 painful lessons I learned in a year of agile project management:

1.Admit you have no idea what agile is.

As an achiever I was too proud to confess I didn’t get the whole thing even after googling and watching a couple of videos. I assumed it was just another style of project management. Sure I can do it. How hard can it possibly be?

Ouch. Fell flat on my face.

2. Don’t assume other people get it either

If you don’t want your project to fail, stakeholder and management buy-in is essential. Remember when I said I was too proud to say I didn’t get agile in the beginning? They probably are as well.

By assuming they get it, you will end up with push back and unmet expectations. Don’t only explain what agile is, but WHY it is a better way to manage that particular project. Make it clear for them that what you’re delivering is not the perfect solution, but agile is a step by step approach to incrementally deliver a good enough solution that business needs when it needs it.

Make them participate in your workshops, address their issues and concerns, be transparent and – most importantly – listen. Keep them in the loop. Under-promise, then over-deliver.

This applies to your team as well: do they get it?

3. Once you admit it, get a proper training for your specific role

Even though powerpoints, videos, and workshops are helpful, nothing beats an official training for your specific role. I just finished last week a five day intensive Agile project manager training course – a year after I started the whole thing.

How I wished I had done it since the beginning. My life would have been so much smoother if I had got the foundations right.

4. It’s all about the mindset and getting out of your comfort zone

Agile really screws up with your brain if you’ve done only traditional project management before. It makes you feel uncomfortable – roles are different, way you plan is different and you need to give up the day to day control. Insecurity you need to deal with is huge as plan changes constantly.

Mistake I did was that I kept comparing both styles and mumbling in my head how much easier it would be to do it the old way.

The old way?? Burgh…

Forget what you learned in the past and listen with an open mind.

5. Prioritize properly in a specific timeframe following MoSCoW

In agile, extending the deadline is not an option. You need to deliver on time, be on budget and never compromise the quality. What changes is the scope of requirements.

Did I do prioritization properly? Yes and no – I knew when something was a must for the whole project, but what I didn’t realize was that even if some things are a must in long term, they are not a must right now. It meant that the team didn’t know what the real, time sensitive priority was.

• Must: what is absolutely vital right now. Good question to ask: if I would tell you two days before launch that we can’t go live with it, what would you do? If the answer is “go live anyway” then it’s not a must.
• Should: very important, but not vital. Good question to ask: is it vital or just painful?If the answer is “painful” then it’s not a must. It’s a should.
• Could: nice to have. Might become painful in the future, but right now it’s nice to have.
• Won’t right now: out of scope. This is all the fluffy bells and whistles stuff.

6. If a new requirement is added, other one needs to go. Watch out for the “quick ones”

I can be charming. I can be annoying. Long way short, it’s tough to tell me no.

Instead of making sure that the team focused on delivering the essential (what was promised), I was guilty of adding improvements and new stakeholder requirements on top, therefore endangering the project.

So when your team tells you that you’re not likely to deliver on time – a sacrilege in the world of agile meaning project failure – believe me: it’s never the team.

The fault is always in the planning and prioritization. Every meeting or “quick fix” adds up and takes time from what really matters – musts.

7. Have mutual respect and communicate openly – and often!

For an open, transparent culture: show mutual respect. When you feel like you’re heard, your opinion matters and you are respected, working becomes fun. You can be yourself, have some banter and talk openly of issues you are facing.

However tempting it may be, don’t skip the meetings where you’re required. Be transparent: have project information where everyone involved can see it. If there’s an issue – communicate it clearly. Most of the issues I’ve faced were due to lack of communication or miscommunication.

Always remember: Bad news are not like cheese. They don’t get any better with time.

Still a long way to go

I’m still trying to figure out the best way to “do” agile and keep making mistakes. When I observe some of my more experienced colleagues, I realize how painfully far from excellence I still am.

Do I regret this challenging journey?

Absolutely not. It hasn’t only made me grow as a person, but I’ve discovered a new way to deliver value for business faster with my team working in a more collaborative way. It stops us getting stuck working on something for years that business doesn’t really need. I can’t wait to learn more lessons in the next few years!

Also, I might not have the full expertise yet, but what I DO have is an awesome team who is patient, exceeds expectations, and stands by me through everything while we’re figuring this out together. And for that I’m very grateful.

So what are you waiting for? Go for it.

It’s tough, but 100% worth it. Remember that no amount of agile training courses, books or powerpoints can ever prepare you for the reality. Learn your foundations and then start running.

You can do it if I could 😉

Best of luck,

Pauliina

Ps. If you found this helpful in anyway, please do like this or share your thoughts in comments 🙂 Would really appreciate it!

[This is part of my challenge to share one personal failure per week to help you see you’re not alone: we all fail. I hope this will help you to get unstuck and succeed in life 🙂 ]

Related: 10 most annoying things you should NOT do if “it’s urgent”

Related: 4 Painful lessons I learned in project reviews