Google’s Project Management Certificate, introduced in July 2020, caught my eye immediately for several reasons.

Firstly, I liked that it would be a monthly subscription type of a course. Secondly, Google was clearly addressing their talent gap with the course, similar to Infinum Academy.

The most convincing reason I wanted to take the course is that strong emphasis is placed on studying the role of a project manager as a blend of several roles, which reflects what we have been seeing in the last few years as a development agency.

As stated above, there are six chapters that need to be completed in order to get the Google Project Management certificate. Each of them is explained with a video starring Google employees who share their (usually somewhat inspirational) stories of how they came to work at Google, some of the challenges they faced, and what they liked about their role.

The videos are well-produced, and the content is excellent. Video material is accompanied by some written resources, summaries, and glossaries. Knowledge adoption is tested through tests and practical assignments, like writing an escalation email or creating a Gantt chart. The assignments are then peer-reviewed.

During the course, a number of documents are created that can serve project managers as templates for their future work. Also, the suggested additional reading is quite good.

There is an order to the chapters, but you do not have to follow it. However, you can’t proceed to the last chapter until you’ve completed all of the previous ones.

As the title suggests, this chapter covers the foundations of project management, the project lifecycle, and the traits and skills expected from a project manager. There’s also an insightful part on change management.

Here is where the work begins. Mostly based on classical project management theory, it covers everything from budgeting and costs to creating different charts and documentation. It also highlights the importance of this phase of the project.

This chapter covers estimates, budgets, and milestones by digging deeper into the topic. It also explores the tools for tracking and maintaining a project. Kudos to Google for mentioning a variety of tools here, but I hope they add Productive to the list as well.

Building on the previous chapter, your “decisions” take center stage in this chapter. The topics discussed include communication, dependencies, quality, and continuous improvement, with a section dedicated to closing a project.

A chapter dedicated to everything Agile! It gives course takers a sense of what Agile is and how it is practiced. A lot of the stuff is mentioned previously throughout the course but in a different context.

This chapter is a practical culmination of all previous chapters, focused on kickstarting a career in project management, setting up a LinkedIn profile, and looking for a job that fits the course taker’s newly acquired skills.

Several of us from the project management team completed the course. As expected, junior project managers gained the most value from the course. While there is nothing groundbreaking in the course itself, it provides a very good breakdown of the project manager role in modern IT companies. It also gives an overview of other Agile frameworks and how traditional project management fits into them.

Senior project managers will get validation on their own work practices and process even if what they have in place is not as formal as presented by Google, like creating a Stakeholder map. Seniors will also be glad that the course acknowledges the shift towards the diversity of roles currently expected from a project manager – from the formal ones of scrum master, product owner, and delivery manager to the more flexible ones of being a mediator, facilitator, motivator etc.

While mostly rooted in today’s most popular frameworks and practices, some of the content is Google-specific, such as parts of the theory, naming, and definitions. This is expected as they are primarily shaping the talent they are looking to hire. Also, there is insight into Google’s agile-up-to-a-point work organizations, a trend we have seen in the last few years in many companies.

That being said, the course is in fact advertised as a breakdown so it would be foolish to expect more depth from a $39 course, compared to the PMP or PMI-ACP courses for example, both of which are referenced in Google’s course. Still, I was expecting more focus on Agile and perhaps a fresh perspective on the core project management postulates.

Finally, call me biased, but the biggest downside in terms of content was Google’s awfully wrong description of scrum in rugby: “Scrum refers to a formation in rugby where all of the players on the team lean forward, lock their heads together, and then work as one unit to try and gain precious yards towards the scoring line.” Here’s a more accurate description of what rugby and project management have in common.

Overall, I would recommend the Google Project Management Certificate course both to new and old project managers. For juniors, it is an exciting blend of theoretical and practical examples from Google, touching on everything that is important in our work, to say the least.

From a more senior perspective, I enjoyed the emphasis put on the team, project communication, and creating proper documentation – things worth reminding yourself of every once in a while.

Oh and also, it’s a great way to refresh your LinkedIn profile and make Google’s headhunters’ job easier.

Seven years ago, when I started my journey as a project manager at Infinum, I wasn’t sure where it would take me.

Since then, I have shape-shifted into a scrum master, product owner, and agile coach, depending on the project’s needs. The software industry changes fast, and it’s either adapt and learn or get left behind.

Along the way, I learned a few lessons that helped me adjust to this ever-changing landscape and significantly impacted the way I perform my day-to-day project management duties.

Surprisingly, most of these lessons originated from rugby.

In rugby, I played a forward. Becoming a project manager after that was easy. Of course, my teammates’ roles changed, and the framework changed, but what made my team excel and deliver value remained the same.

Rugby as a sport emphasizes team values. Its basic concepts are “communication” and “support”, while the game elements of ruck, maul, lineout, and scrum require players to create formations. There are 15 players on the pitch, and each position has a role. Each of those roles can achieve peak performance only if the other roles are there to support, encourage, and assist.

Project teams function in the same way. Each member has their responsibilities, but only with the support of other team members can the whole team excel.

This lesson was a hard one.

On the days you don’t feel like it; when your energy and willpower are in the gutter. When you feel everything is stacked against you – that’s when you need to show up for training and show up for the game. The beautiful thing about being part of a team – be it a rugby team or a project team, is that you can count on your teammates to help you through this.

Whether it is something simple like a stand-up you don’t feel like attending or a gut-wrenching escalation meeting, you must show up. Showing up reflects the responsibility and commitment you have towards the team and the work. The great Steven Hawking said it best: “Just showing up is half the battle.”

During training, you work on elements from the game, and each game is a demonstration of what you worked on. Whether you win or lose, it ends with a retrospective. The whole team participates in analyzing what we did good and what should be improved both on a team level and individually. In the first training session after the game, we start working on the same elements but incorporate the feedback from the game.

Sounds familiar, right? The key point for me was learning the value of listening, accepting, and acting on the feedback you receive. It’s that feedback that shows you where improvements need to be made.

The third half is the time after the game when players of both teams grab a drink, usually together. It’s about team building, networking, getting to know your teammates, but also about getting to know others, learning about their practices, and sharing your own.

In the same way, getting to know your project team is important, getting to know other teams on the project is important, and sharing experiences and processes between two projects/product teams is essential to improving your way of working not just within the project team but the company as a whole.

Self-organizing teams are a key concept in the agile mindset. It is also one of the agile concepts that a lot of companies struggle with.

Rugby teams are a very good example of self-organization. Each rugby team is divided based on their position: forwards from 1 to 8 or backs from 9 to 15. While each position is clearly defined, it’s not limiting; the way backs and forwards accomplish the strategy largely depends on their preferences. Again, collaboration and efficiency are key.

This applies to scrum teams almost exactly; while the product vision comes from product owners, the development team decides on the details of building that vision.

Rugby remains a big part of my life but I never thought it would be a big part of my current career, too.

The lessons rugby taught me can probably be learned through different sports, activities, and job positions, but these made it easier for me to embrace the agile approach and to fit into different product teams and cultures.

If they resonate with you, perhaps the project manager/product owner/scrum master career paths are what you should be pursuing. It’s either that or you’re into rugby, and I’d be happy to discuss either during the third half.

Story points in agile often feel like the extra pieces of an Ikea wardrobe that you are left with after you finished the assembly. The wardrobe is there, it stands straight, the drawers open smoothly, but you are left with a feeling of doubt. Should the pieces have been used somewhere? Somewhere important?

Similarly, your product is moving along according to plan, you are using scrum, all of the artifacts and ceremonies are there, but you are not using story points. Should you be The question sparks constant debate and there are as many opinions on the matter as there are JavaScript frameworks.

However, the lack of consensus on their value is due to a huge variety of use cases. Different agile teams and organizations may use them in completely different ways. This article tries to provide some insights into the matter and break down the benefits of using story points in project management.

When a project is set in motion, the development team commits to a described block of work, also called a story. The team is then asked to give an estimate in hours or days to see if it fits the iteration they are working in.

By that point, the story should have already been refined to such an extent that all of the foreseen complexities and difficulties are – resolved, accepted, or eliminated (similar to ROAM). These complexities can include anything that might affect the outcome of the delivery, for example depending on a third-party software component, a complicated quality assurance procedure, lack of domain knowledge, vacation time, a missing flow, or just an especially large and complex chunk of work.

When taking on a story for development, the Dev Team is committing to deliver it in a fixed time frame – a sprint, release, or whatever other cycle they are working by. This is where one of the common misconceptions appears.

If a five-person team can deliver stories worth 50 story points in one sprint, does it mean that one story point can be calculated as 50 SP divided by the number of working hours?

No, it doesn’t and it shouldn’t. Yet we all know this happens often.

A story point can have different “weight” from person to person. However, in cross-functional teams, the number of story points committed to a cycle can vary greatly depending on the type of work and team composition. This does not mean that story points are useless from the perspective of a development team.

Hour estimates deal with the uncertainties and complexities of a task in a way that they increase the total amount of time needed for implementation.

The problem with that approach is that not all complexities can be handled with time. We add buffers and give out ranged estimates, but after a certain point the message should simply be “we are not sure”.

When stakeholders see a large number next to a work item, first they assume it’s hours or something that can be translated into hours. They recognize it as complex, requiring a lot of effort, but they also see a commitment to deliver within a limited timeframe.

Ideally, story points should bridge the gap in the Dev Team – Scrum master – Product Owner – Stakeholders communication chain. They provide a new criterion for describing a set of tasks, and focus not only on the estimated time needed to complete it, but on how demanding it is.

Let’s illustrate why numbers are a problem with an extremely simplified example. Most people in software development have probably been in this kind of situation at some point.

The development team delivered a total of 34 story points in the last sprint and they closed off 34 work items. Planning the next sprint with the stakeholders/product owner, you come upon a work item in the backlog that was estimated at 34SP at some point. It organically comes to mind that this could fit perfectly into the next sprint, right? Wrong. It might, but it might not.

Unless your environment is a high-functioning, development-oriented, agile organisation, using numbers for story points might become troublesome. You can Fibonacci all day but explaining that it’s about proportions, not the value itself, and that 5 SP is not really five of anything, will not intuitively make sense to most people.

It may be helpful to use T-shirt sizes (S, M, L, XL, XXL), although some pitfalls apply here as well. Still, it seems to cause less confusion than SP numbers.

If your use of story points in the form of numbers gives the misleading impression of certainty and commitment, then change them to whatever gets the message of complexity across, even if it’s simply an all-caps statement saying: THIS HERE IS COMPLICATED!

You can also create your own framework, for example range the complexity levels as foes from Lord of the Rings and their difficulty to defeat:

The way to work with this is to break down any Sauron-level stories to Trolls or simpler if possible.

Scrum Masters need story points to create velocity charts. Besides using them to indicate team performance and productivity, Scrum Masters limit the work committed in a cycle based on the velocity from previous cycles. They calculate velocity because they are often asked when and how much the development team can deliver.

For this to have any practical value, a number of factors need to remain constant, like team size, team composition, domain knowledge, etc. (Cross-platform teams and an agency setup can make this consistency hard to achieve, but that’s a different topic.) Without consistency, velocity charts are just a divination tool, sort of like an astrological chart for development team deliveries.

The people asking “when and how much” are the Product Owner and the Stakeholders. Now there is an entangled web of managing expectations, adding business value, keeping the product maintainable and scalable while having a clear and visible plan for implementation. It’s a continuous loop where visibility and transparency are the key to a successful relationship and finally, successful product development.

These can be easily picked up for implementation in the next development cycle. Further, we give the stakeholders a clear overview of what can be immediately prioritized for development and what needs to be ironed out.

Story points are a tool that should reduce miscommunication and misunderstandings. They should also help draw attention to those stories that need more work before you can consider development. That is the key to the effective use of story points – they shift the focus from what can be delivered and when, to why the complexity is so high and how PO’s can help reduce it.

Hopefully, this clarifies some of the aspects of using story points in the agile framework. How these relate to the actual effort put in for each step is a whole different story to tell.

It seems there’s a swarm of IT/tech/startup conferences popping up all over the globe. Choosing which conference to attend can often prove to be a challenge. At the end of the day, you’ll probably settle for the best ratio of content and time, as when going to a music festival.

Keeping that in mind, we decided to visit The Next Web conference in Amsterdam. For the line-up, of course. The historical heritage, space cookies and the red-light district had nothing to do with it, seriously!

The conference took place between May 27th and 29th, and the speaker list was jam-packed with big names. The likes of Google, Facebook, Reddit, Basecamp and other industry leaders were all there. All the companies that built an entire industry were poised to speak about Digital Innovation at a conference called The Next Web.

C’mon, this must be good!

I was imagining presentations along the lines of Amazon’s CTO announcing a concept of a fully functional robotic velociraptor that walks the streets while streaming the whole thing live on Facebook. Online users could connect to it through Oculus Rift to wreak havoc and vengeance against FOX for canceling their favorite TV show.

After the terror and mayhem ends, everyone starts up Google Now trying to remember where their autonomous vehicle parked itself.

My expectations may have been a bit unrealistic (yet plausible!), but I did expect at least a sneak peek into what all these tech R&D departments are up to. So, what did we see?

We’re sad to say robotic velociraptors were nowhere to be seen. Google and Facebook had rather bland product development presentations, while Amazon’s CTO and Microsoft’s Principal Researcher both gave technical but engaging talks. But there were a few standouts.

Personally, I’d say the show was stolen by some names you probably all know of – Gary Vaynerchuk, Ryan Leslie and Casey Neistat. These guys fall into a whole different category of speakers, and rightly so – they’re entertainers at their core.

They all shared invaluable entrepreneurial advice and warnings, and it was evident they were talking from their personal experiences. The emotions were what kept the audience nailed to their seats.

Gary V. faced the startup-filled audience by conveying a brutally honest statement. “Most of you will fail, not all of us are cut out to be entrepreneurs“, he said. Startups today focus on attracting investors instead of focusing on monetization. It all results in an unsustainable environment.

But it wasn’t all pitfalls and doom talk, there is a pot of gold at the end of the rainbow. To reach it, according to Gary, you must be honest with yourself, admit your shortcomings, embrace your flaws and become better for it. This will culminate in realistic and achievable expectations.

And there I was, expecting robotic dinosaurs. “He’s talking about me!”, a sharp thought pierced through my brain. Don’t you love it when you can relate with the speaker? Gary left the stage with a standing ovation.

The conference was brimming with startups, a couple of which grabbed my attention. There was an interesting team from France that was playing around with augmented reality called Augment. We met a cool team from New York that made Kya – to help gather relevant data for publishers.

There was also a Dutch team that made Nupky – their device will finally turn DJs into musicians (bring on the hate). There was a whole lot more of interesting ideas and products and some extremely hard to pronounce names. Each time I’d see a puzzling name I would comfort myself by thinking “I’m just not Dutch enough”.

When I look back, this spectacularly organized conference (with light shows, Morgan Freeman, standup roasts, video walls, etc.) did in a way achieve what all conferences are meant to do. It brought people from the industry together in one place and allowed them to interact.

There were a couple of amazing speakers, startups got to tell their story to anyone who would listen, and some business cards got exchanged. Just being a part of such an intense environment every once in a while has a refreshing effect. Intense, but refreshing.

If you’re looking for a conference that will take you to the bleeding edge of technology – this may not be up your alley. But if you are an aspiring entrepreneur, a startup, an agency, or you’d just like to exchange experiences, this may very well be the place to promote yourself and what you do.

Don’t get me wrong, you will have fun and come out wiser – but without those robot dinosaurs, you came for in the first place.