The word “team” invokes very positive feelings in people. We associate it with working together towards a shared goal, as in sports. But if we look at the way these groups work in most workplaces, we often find that they really don’t match with what the literature means with a real team.

There are two primary ways to coordinate the collaboration inside a group of people working towards a shared product – workgroup and team. It’s a spectrum, to be precise, but we’ll look at the extremes. I’m also including a “bad workgroup” column, to emphasize that I’m trying to compare two good approaches for organizing groups, rather than “team trumps all others”.

Please keep in mind that in the table below I am talking about the same group. In all columns, we have a group with the same external purpose, the same members, and the same externally recognized leader/manager. We will also assume that the group is small, because teamwork does get difficult with group sizes exceeding 9. The only thing that differs is the way the group organizes and operates internally.

I decided to turn off commenting on this website, because 1) there were so few comments anyways, 2) I really didn't need one more place to keep track of, and 3) there were tens of thousands of spam messages waiting for "moderation" (i.e. deletion).

This blog is more a collection of things I want to share more permanently. I will post regularly to LinkedIn and Twitter, too, so the conversation on those posts is better held there.

I hope you understand.

The traditional project approach has three core roles - the Customer, the Project Manager, and the Project Team. Similarly, Scrum has three roles - the Product Owner (PO), the Development Team, and the ScrumMaster.

It’s easy to see that the Customer and the Product Owner map rather nicely, since both have the money and the business need. Also the Project Team and the Development Team map nicely, since they are the people who have the skills to create the product needed by the business. 

The last one is a bit trickier. It’s easy to think that they map nicely, too. But they really map only in the goal of that role - both roles want the project to succeed. But other than that, they are the two opposite sides of the “project leadership coin”.

There seems to be a perception that a "servant leader" equates closely to the classic image of Jeeves, the british gentleman servant, or something alike.

My perception is quite different.

Servant

I'm going to start with the first word first. This may be a little badly chosen word, at least in English (I don't know about the translations to other languages). A better word might be "service", "serving", or "host" (as suggested by some).

To write perfect user stories, the do this:

Step 1: Ask users what they need from the software and why.

Step 2: Look at the most common answers and try to express them in the form “<someone> can <do something they need>, in order to <main benefit>”. At this point, only write a small number of stories, like 20–50, so that each story is “an epic”, big and unclear, but captures an essential need for some user or group of users. In some way, validate with users that you’ve understood them.

First of all, welcome to my new website!

Or more precisely, the same website, but with a new appearance. So it just looks new. But anyways, welcome!

Thanks all the people who actually made it happen - you know who you are.

“How does the PM role translate to Scrum?” is one of the more typical questions in my Scrum courses. Here’s the results of one such exercise that we did with the participants to find an answer. 

As can be seen, a large chunk of typical project manager responsibilities become things Product Owners (green in the picture) are supposed to own, and another big chunk is for the Development Team (red). There’s a few splashes of blue (for ScrumMaster) and a sizeable number of items that Scrum is silent on (yellow). 

What is/was project manager anyways?

“Project” is an execution management structure. Projects are set up to deliver some target outcome, usually within specified timeline and budget. 

When you start to use Scrum (or any other Agile framework), it will suck. So you try to fix it. Your mindset will define which way you will go – either back to Waterfall or to actual Agile.

To understand what I mean, please imagine a project that seeks to deliver a customer a system they request for. At the end of the project, we find out that the customer doesn’t like the outcome, despite the fact that it matches their original request. 

Why did that happen?

Our brain seeks to understand why things happen around us they way they do. These explanations, for the scenario above, tend to fall into two primary beliefs for the cause: