Product Owner job

Product Owner should solve user problems instead of orchestrating stakeholder requirements and requests. I have seen users had no idea the solution they need was even possible. I remember asking users myself:

– what if we would built this instead?

– oh, is that possible? This would be so cool!

Why talent recruitment may be wrong idea..

A while ago I was asked by one very well known company to investigate how could they foster talent recruitment, in other words, attract more talents. The company is very well known world wide, has presence in Silicon Valley.

I did some research inside and outside; combined outcome with my own experience (of course). I presented it, we discussed it, but I came back home with feeling I am not satisfied with my suggestions. It was that feeling when you look at something and you understand it is wrong, but you cannot tell what exactly. Recently I was able to do 2+2, well, actually 2+2+2.

One of the first things I did, I have asked Agile community of their thoughts about The Company. They told that company was sexy, but now it is just yet-another-company. Well, it is still seen among most wanted, but it looks like “wanted” of these companies are not very impressive. Guys were aware of some senior (leader) people leaving The Company due to recent changes (very reasonable changes, actually).

Before doing the math let’s investigate “talent recruitment” activity as such. In my world it implies two things:

• assumption, that The Company has need for talents
• assumption, that attraction is enough talent will chose to work for The Company (of course, attraction means awareness and proper presentation and employer sell process)

At this point I would like not question first assumption, but I would rather focus on hires that would fit to particular team or bring required skills to solve The Problem – focus on very particular and precise problem(s).

Now, the second hypothesis. It is not a secret any more that these days talent is choosing employer. Of course, afterwards, hiring review (and sales) process starts and company evaluates the fit. In case sales process would be detached from reality, candidate would leave The Company shortly. Smart people smell crap quickly. Let me suggest another example of supply meeting the demand. Toyota produces Lexus and Toyota cars for different audiences. You could sell pimped Toyota to Lexus buyer, but month after he or she would realize that is not what he really wants and would sell it.

One thing I have not mentioned yet on purpose until now: the change in The Company has impacted (huge decrease of) autonomy. Remember the holy trinity of Mastery, Autonomy and Purpose? While autonomy The Company employees left with is way greater than most companies in the world, still, it is not perceived as wow anymore by the market. And, probably, market has not heard about any new wow proposition. Probably, there is none.

So here is the thing, here is the math. I am not sure that “how to attract more talents” is the right goal. Asking this leads to wrong actions. Instead, the task should be “how to become a Lexus”, so that Lexus buyers would make decision to consider The Option. In real world The Company is among best companies, but apparently, world class talents  are chasing for a bit higher hallmark. The question should be “how to become sexy again”. Exercise of talent attraction may be the right tasks, but only after preconditions are met. Until then, attraction will result into something, but not something tremendous.

Once holy trinity is similar (e.g. Facebook, Google, Uber), the fight will transfer into compensation or “sales” and strategy level.

Again, all the math above is based on the assumption, that The Company needs talents. Maybe talents are not needed to solve their challenges and problems.

Does this resonate to your experience? Please share your experience and thoughts about talent recruitment hype.

Dear Scrum Product Owner…

Product Owners shouldn’t accept sprint increment (quality) based on trust. Instead they should accept based on information provided

Command and control is not so bad in Agile

Actually control in Agile is good and necessary. It is. Yes, it is. I said – it is. Trust me. Don’t you? Good, then let me share my thoughts about when and what control is good.

First of all, I have noticed that very often members of Agile Teams are trying to defeat control, because control is Evil. Because Agile Team is Self-Organized and therefore they should decide almost everything. Wrong!

Responsibilities in Agile teams

I hear (Agile) people saying that no one is looking into security, because no one cares or that they have bugs, because their managers are not hiring testers.

Companies which decide to take transformation path to Agile are often worried about which role is responsible for what. They do that, because they used to control things. And they are used to control, because otherwise things are not get done properly or on time. Agile “gurus” responds them: “Let them self-organize! They can handle it. You do not need to control!”. Those managers who believed and decided to try it out (because Agile says experiment!) saw how team simply fails bad and then loses trust in Agile. Sometimes they think Agile is not for them, sometimes they realize that they need help.

Documentation in Agile

“We are not writing documentation! We are Agile!” – scream they.

“We are Agile, we don’t write useless documentation” – Agile people say. “We don’t write documentation – we are Agile” – other people hear.

What a heck is this? How did we get there? Maybe we should start saying “We are Agile, we create useful documentation”. Maybe then everyone will understand that documentation in Agile takes very important part.

How and why create cross-functional teams

If you want to read why you should possibly want to build cross-functional teams, then go to the bottom of the post.

 It is not easy to build cross-functional teams, but that’s something you know already right?

So you are heading to apply Scrum and most likely you have a good reason to do that. You either are sure that this is going to give you value or you want experiment. Next thing you need to do is place all different kind of specialist to the Scrum team(s) and voila! Next thing you are sure about it that is not going to work and you are right.

Finding a Scrum Master for a team

If you are reading this post, I assume that you are convinced or at least willing to try dedicated Scrum Master for your team. You are looking at various options: hire from outside; pick from inside; let team choose by themselves; nominate one by yourself (if you are a manager). Which one is best? How to know if person from inside is going to be the right person? Let’s go through every option.