First off - the entire guideline is free to read and accessible on Netguru’s website, right here. Big pros for this company to share their how-to knowledge for anyone on the web free of charge! We all know, it’s definitely not free to gain all of that insight and publish it in a form of a book. They could sell it, appreciate it!

I’ve read this book just recently - and I’ll post here my notes, insights, and general impressions.

The form

The entire guide can be read using the hosted e-book - website with chapters nicely structured and presented. I liked the way it looks, navigates, and overall typography. Reminds me of a famous Michael Hartl book, but in more minimalistic and clean form, like a Medium. Great Job!

Would it be possible to improve it to the next level? Sure, one thing I can imagine is to store where reader finished last time and mark chapters he has seen already. All of that using cookies, for example, to make it quick and easy. However, that would be the icing on a cake.

One of the things you should be aware of is that book is written by multiple authors. That effectively means, style of chapters tend to be a little different, but not to the point which makes it difficult to read.

The structure

The book has just five chapters, but if we remove the short introduction and summary, that leaves us with just three. I think that’s… well, not much, especially because they are really big, so one of the first things I’ve thought is that they could be split into smaller pieces.

The current structure is:

1. PM Superhero
2. Project Life Cycle
3. People in projects

And I can imagine something like this instead:

1. PM Superhero - it’s a great chapter name. I would leave their subchapters explaining what is the role of a PM, why it’s so challenging, and how to generally approach the idea of improvement.
2. Time Management - it already has three subchapters, so it silently pokes for its own place.
3. High-level planning - this is where I would place activities related to kick-off, knowing the customer, road mapping, handovers.
4. Scrum tips - all of the scrum related chapters could come here.
5. Elevate teams - all of the guidelines about leading and managing the project team.
6. Build partnerships - how to communicate with customers, educate, and work on relationships.

Obviously, this is just a suggestion of how I see it. Let’s talk now about the chapter internals!

PM Superhero

The first chapter with guideline content was pleasingly surprising to me, and make me totally want reading more. It also had the most eye-opening facts that I would like to share with you. To be honest, that was the best chapter.

I loved comic references, and the explanation of PM superpowers was really great. I’ll present one of the examples, and if you want to see more - just open Netguru’s PM guide!

So - what often happens in the team, is that there is a lurking problem that everyone is aware of, but no one want’s to admit it or speak about it openly. Netguru called it a Kryptonite, which you need to neutralize since it weakens the team. So how should you do it? You need to gather your strength and do the toughest thing, which no one wants to do - to “drag out the elephant out from the room by its ears” - and start the difficult conversation.

There may be emotions, tough statements, difficult questions. However, what happens afterward, is - like in the team of Avengers movie - after the fight, the team gathers, stands up, and moves toward reaching the next goal with doubled motivation. Love that idea and reference.

From other important topics, I was astonished by the idea of what could be the role of a PM in modern development teams. I always thought that PM’s role in a Scrum would be… well, a product owner. However, at the same time, I’m aware after working in a software house, that what usually happens is that it is better to have a product owner on the customer side - especially in a remote team with a huge time difference - product owner on the customer side will make it much easier to identify all of the tangled requirements spread between different stakeholders. Many times these people are so busy, that there is no way to reach them outside of their preferred time zone.

On the other hand, though, you as a software house company treat each project from a little different perspective. Customer - or partner - has their goal, but you, as a software company, have additional goals:

• Help to achieve the project goal, or more precisely - help to achieve the goal, which project is supposed to solve.
• Make money from that cooperation, which is a base and fundamental of software house business plan.

Using Scrum, Kanban, or any other framework in a good way, you will certainly help with the customer goal. But what about the goal of your software house? If it’s better for a PM to be a product owner though, how you can position such a person in your team and make it sense for Scrum?

And this is where Netguru showed me an obvious and simple answer - make your company PM a Scrum Master. That makes perfect sense to explain this person’s role in a project if she is not a product owner, and the company role is still the same. Really great idea!

Overall, this chapter is really good and covers plenty of similar and easy to understand ideas like the ones above. Certainly worth reading!

Project Life cycle

The second chapter explains a couple of difficult topics from a management perspective. For example, the concept of Sprint 0, estimations, ticket descriptions, and so on. Most of these tips were pretty straightforward to me and I didn’t feel like I’ve learned too many new ideas. Still - some of them are worth discussing.

When I passed my Scrum certifications some time ago, I remember how negatively everyone expressed about the concept of Sprint 0. However, I also felt that from a software house perspective it’s extremely risky to sign a contract for both customers and my company after just a couple of talks.

Not only it looks unprofessional for a customer who is probably not agile-educated, but it also generates unnecessary risks… just for a sake of being strict with the Scrum bible. What for? From Netguru’s perspective - treat Sprint 0 as an iteration to prepare for a full scrum team to join - make sure you understand the scope, rough estimates are provided, the product backlog is formulated for the first two iterations. That will pay off as soon as the team starts to work and you will realize where misunderstandings were placed, and where they were avoided that’s to this short planning phase.

Overall, it’s maybe not the most eye-opening chapter for me, but a solid recap certainly worth reading, especially for new PM in the business.

People in projects

My second favorite chapter, especially thanks to hitting two difficult topics which are rarely discussed in most agile manuals for software developers or project managers. That is:

• Agile and Scrum in remote teams, especially with the large time difference,
• Building partnership with your customer and educate them in agile ways.

Like most people who spent years in management, I’ll absolutely agree that the people factor is the one which is the most difficult to play within the software world. People are different and emotional intelligence is a skill that most IT guys didn’t ever bother to invest.

One of the challenges I think most teams struggle with - and which is also described in this book - is the fact that many agile teams (in the case of software houses, especially) are remote teams. Many times - with a huge time difference. That has plenty of issues involved:

• Suddenly, meetings became a pain. They are less effective, since meeting in person is always faster, easier, and you can read people right away. Secondly, long meetings are hard to achieve - how can you schedule two-hour sprint review and planning with a customer, when there is a 9 hour time difference between you and them? It’s really hard.
• If the entire team works in a single building, it’s easy to do a reality check from time to time and see how the work goes - in person. You, or a customer, will see with our own eyes, that “work is happening”. However, in a remote environment with the time difference - work is not so transparent. You need to overcommunicate your progress and make sure that work is easily visible for everyone.

However, the most important gradient to make it all work - is trust. Without it, there’s no chance you - as a PM - will make your team effective, and to make things worse, this will be quickly noticed by customers.

The second topic I wanted to briefly discuss is the idea of building partnership with your customer. I think this is really important. Too often companies forget that they actually need to listen - not only what customer says in terms of next goals or story ideas - but what they want to achieve, what is the benefit they are looking for from this product you’re building and the entire cooperation. It may turn out in the end, that you all agree that the feature you’re building is a great way to meet the product goals, but the product goal itself doesn’t seem to match well recent discussions you had with stakeholders. It may turn out that a recent product company bought a month ago, solves this goal entirely, and the product goal you’re about to build is outdated - but no one realized.

Making sure customer is not wasting money, even if you’d profit out of that, being patient, growing together and keep on improving - these are fundamentals of a partnership.

Summary

I enjoyed this book and I think it’s really great that Netguru published it for everyone to use for free. It can be clearly noticed that this company has learned a lot throughout the years, they established their own processes that they keep on improving and their business model works.

It’s a good book, worth reading for project managers and leaders, especially if you work in a similar business model (software house).