When it comes to ownership (be it Product Ownership or something else) it’s not about Truth OR Dare, it’s about Truth AND Dare.
First things first. Truth.
Don’t lie. Don’t lie about the status of your product, service, application, team, company, etc. Tell the truth and show which steps you’re taking to improve and which challenges are ahead.
Don’t make promises you can’t keep (so that in the future they become lies). Don’t sell products or services that you are not sure of that can be made. Don’t commit to finishing something by a certain date when you already know you won’t make it.
Walk the talk. Do what you say and say what you do.
“But Jaap, sometimes you need to take a risk, you need to be bold and take a change or you’ll end up nowhere!”
True, so Dare, dare to take a risk, dare to take that next step, dare to take that decision without having all the information.
And be open about it. Make sure it’s an educated risk you’re taking. Make your assumptions explicit. Describe your hypotheses and the ways to validate them. Now you’re also the owner of the consequences of your actions and that’s true ownership.
I got acquainted with the term Shifting Baseline Syndrome just last week. I think it pretty much sums up what’s happening with Agile. Let me explain.
Shifting Baseline Syndrome
Read more here, but the short definition of Shifting Baseline is that the change of a system is measured against previous baselines, which themselves have been changed over time from an even earlier state of that system. Of course that can be both positive and negative, as the baselines can go “up” or “down”.
The Shifting Baseline Syndrome comes from Daniel Pauly and was used to explain how scientist fail to identify the correct baseline for populations (in this case fish). Every new generation of scientists is brought up with a new baseline that’s normal to them but is actually lower than the one before, resulting in ever diminishing populations.
Agile’s Shifting Baseline Syndrome
In the case of Agile, I think the baseline is going down. And it’s going down pretty fast. For me the Agile Manifesto with clear values and principles is still the baseline for an Agile mindset. It’s simple to understand and in practice hard to implement, but that should not influence the baseline as is.
What I do recognise around me is that when implementing an agile mindset in organisations, corners are cut, the wine is watered down, etc. even with the argument tof being Agile about Agile.
Furthermore, with every new Agile Coach trained by a new generation of trainers and coaches Agile seems diluted. When the first trainer teaches 99% Agile instead of 100% and the next after does 99% again (99% of 99%), you can do the math, right? And we have lot of teachers and coaches these days. Just to give an example of one of the most used Agile ways of working, Scrum. Scrum.org has over 360K PSM I certificates sold, and almost 100K PSPO I certificates*.
I’m not saying that the math above holds true for everyone, but be honest to yourself. If you look around in your organisation where people say they are Agile, is that actually the case, looking at the Agile Manifesto?
And dear trainers and coaches, if you are perfectly honest, where do you cut corners or water down the Agile wine when teaching or coaching the values and principles?
or, Why I am more and more reluctant to call myself an Agile Coach
I absolutely love the simplicity of Agilemanifesto.org, its values and principles, especially when it comes to software development. With that being said, Agile is NOT a way of working. It is a way of looking at things, a set of values and principles that can be adjusted to or incorporated in the values and principles you want for your company.
Scrum is a framework, a guide for teams to organise their collaboration. I’m attracted to it because of the two explicit feedback loops both on the product and on the process. It helps teams to structure their work and gives a mandated trias politica of the what, why and how. I’m not a Scrum fanatic by the way. It is an instrument you can use if and when it is useful but should be dropped (or parts of it) when it doesn’t help.
Although Scrum = Agile, Agile != Scrum
Scrum is not the only way to organise your team(s) and with that your company, with the agile principles in mind. Furthermore, some of the values and principles are predominantly directed towards software development and it sometimes is hard to translate them to other parts of your business (marketing, procurement, that kind of thing). Agile provides a mindset of flexibility, of making the right and timely feedback loops are in place with the customer in mind.
Good you might say, so what’s wrong with Agile and the most used Agile way of working, Scrum?
Agile/Scrum is not…
A recipe, a silver bullet or a step by step playbook to solve all your problems. Actually, living by these values and principles usually makes all the problems you had before you adopted Agile more explicit and more painful!
An excuse to fuck everything up in the name of experimentation
An excuse for lack of accountability
A trend that should be followed blindly. Think!
A lack of deadlines
Something you can buy…
And with the last point, my main problem arises. The eco-system of companies, trainings, frameworks, scaling frameworks, coaches, certificates etc. has gone way out of hand.
A certificate is not a license to operate. Acing an exam doesn’t mean you know what you are doing. Too many rules (especially in scaling frameworks such as SAFe) kills a lot of the flexibility and agile values. I always get the shivers when somebody calls him or herself “Agilist”. Agile is nor a religion, although one could think that between frameworks a religious war is at hand, at least a war against waterfall. Waterfall is great!, at least in some contexts.
In my mind, the Agile eco-system is subject to a growing inflation. Having over 300K certified scrum masters doesn’t make the world better. Being a certified scrum master doesn’t make you a coach, let alone a good one. There are too many (training)companies, frameworks and Agilists around and its harder and harder to find people who actually know what they are doing. Calling myself an Agile Coach puts me in that eco-system and I’m not sure I want that anymore…
So, what’s the alternative?
I’m not sure yet. I do think there’s value in combining a flexible mindset with an understanding of several ways of working, to optimise collaboration, processes and organisations in order to make work better, have happier people and customers and to actually make some money. You need to combine a start-up, scale-up mentality with the understanding of some of the applicable rules of engagement from the “old” world. And brave leadership!
There has been a lot of talk about GIVING ownership. Management should let teams take ownership. Product Owners (with or without budget) should be able to make their own decisions. Let teams take controle over what and how to do things. Teams can organise themselves. The teams can fail, if they fail fast and learn, no problem. Dear management, please give ownership and controle to the teams.
These kind of things.
There’s not that much around about TAKING ownership.
What I see is that teams and Product Owners struggle with taking ownership. Teams do not really take ownership of their way of working and PO’s do not really take ownership of the product or service they’ve been given. As targets are not reached, management takes over again, Bye, bye ownership.
Let’s make things clear first. Ownership involves at least three things. Without them, you don’t own anything.
Means: budget, resources, tools, etc.
Authority: the mandate to actually take decisions, but also the recognition by the team(s) and management that you can
Necessity: an intrinsic or extrinsic need to solve the problems/reach the goals. Sometimes “it’s the job you choose” can be enough.
This M.A.N. comes with responsibilities and consequences and that’s where a lot of teams and PO’s fail. Management doesn’t really give it, but more importantly, teams and PO’s don’t really take it.
If you have been given the M.A.N. by management you are now responsible for the decisions (and their consequences) you make. Please realise that (to give a few examples):
You are also responsible for NOT making decisions and the consequence of NOT acting
You are responsible if you don’t know what to do or how to do things and therefore responsible for asking help
You are responsible for making the consequences of your decisions clear to everyone. In complex situations that also means the consequence of not knowing the outcome
As a team, you are responsible for your way of working, but also for regularly evaluations and changing things if it doesn’t work
If the route from A to B is unclear, choose a path, make the consequences of that path clear including what happens if it’s the wrong path, and then GO!
If you face a problem and you don’t know who the owner is, you are until you get it clear
Management: if you give ownership, make sure you actually hand the M.A.N. over. PO’s and teams: if you get ownership, make sure the M.A.N. is really given and then take it!
What do you see around you? How is ownership handed over? Does management let go? Do teams actually take it over? Let me know.
I see this slogan popping up in companies, some people even have it upon the wall in their workspace. I don’t believe it’s very healthy.
Sometimes it has been given to them by their managers as a way to work by. That’s even worse.
In endurance sports many people live by the “Be comfortable being uncomfortable” mindset. You cannot choose the circumstances on race day and you will be uncomfortable, so you better get used to uncomfortable situations during training. For those not into endurance sports, being uncomfortable, or even better, suffering, is part of the joy. As an ultrarunner myself, this way of thinking helps me to stay disciplined during training and resilient on race day.
In your workplace suffering or being uncomfortable should not be part of your daily routine. Of course everybody has their “off day”, or some parts of your job are not all fun, but suffering is something else.
When I start to feel uncomfortable at work it usually means something is wrong. It’s a warning sign. Maybe there’s too much stress, or I’m not comfortable dealing with a person, I’m working too long, that kind of thing. When somethings wrong, you need to change.
I’m not sure why managers would want their colleagues to be uncomfortable. Nobody ever becomes more productive being uncomfortable and it sure as hell doesn’t help the working environment. You won’t win any “Great Place To Work” trophies.
I’m curious. Any other unhealthy slogan’s you’ve seen in your working environment? Let me know!
In the last couple of months I have given several talks and workshops next to my freelance assignments. Topics have been Complex Problem Solving, Agile/Scrum for managent and Scrum workshops.
Usually the question of payment comes up. “What’s your fee?” “What do you want for it?” That kind of questions. For these kind of talks or workshops I do the following:
“Pay what it’s worth to you and your organisation.”
I will do the talk or give the workshop and afterwards you tell me what it was worth and how much you want to pay for it. It’s like the Value for Value Model as described by Adam Curry and John C. Dvorak in their podcast No Agenda.
My experiences so far:
Everyone really likes the idea. They give back that it made them think on the actual value. It also made them think what (hourly) rates they themselves are using or would use in these cases.
I’ve not been let down. I mean, everyone has payed a reasonable fee compared to the time spend (if compared to my rate as a freelancer).
I do lose money on it, compared to the total time needed for it. Considering preparation, travel time, taking a day of “normal” work therefore missing what I could have earned in that time.
More importantly, I’ve had a lot of fun discussing the concept and seeing the reactions to it! People are really surprised by this!
For me this is really what value is about. As a company you can decide upfront what something is worth or what users should pay for your products or services. At the end, the user decides and should pay what it’s worth. To be fare, there are risks. For me as well. My family and I need to eat :). So, I’m not changing my fee as a freelancer to this model (although I would love to). I am willing to lose money for these kind of talks and workshops, just to make other’s think and see what happens…
What do you think? Could this be something for you? Please let me know!
Some lessons you learn the fun/hard way. In other words, your children teach you. Anybody with kids recognises the following conversation.
You: Can you please put on your shoes?
You: Put your shoes on!
Kid: But you asked me and…
You: PUT YOUR G#$%& SHO…
Technically, No!, was a valid answer. And your kid reminded you of that. But, that’s not the answer you wanted. The answer you wanted was Yes!, with the “voluntary” follow up action of actually putting on the shoes.
Asking your team to do something and the answer “No” is not the answer you want nor accept?
Proposing a new way of working and the team does not agree and you already are putting it in play?
Asking people to follow new guidelines when they are actually mandatory?
Giving advise that should be followed?
Giving several choices but only one of the options is correct?
And? How do your colleagues react? Internally probably the same way as your kids, they just won’t say. It’s a full fledged feeling of injustice. You think you are given a choice, but actually you aren’t. You were told what to do, but in a “nice” way or something. Nobody likes this.
So what is the solution? Stopit! Stop asking when it’s not a question! It could be that your kids are too small to think for themselves. That means you need to tell them instead of asking. Your team members and co-workers are professionals, they can think for themselves. Only tell your co-workers what to do when it comes to the big picture (strategy, values etc.). Give them the Why and some of the What. Let them figure out the How for themselves.
Chokes me up every time. Explains it all. Well almost.
This week, we used this video at the start of a kickoff meeting with a new team. We used it for inspiration on how to work together, to establish a WoW (no, not World of Warcraft), Way of Working, without too many rules, regulations, processes, measurements and accountability.
After showing the video, everyone was silent for a minute. Then, two things happened. Everyone in the room got in the right spirit. Secondly, there were some questions of course, especially about accountability.
Actually, from my point of view, the best question was about the difference between the relay-team and real life. In real-life, different team members actually have different skills and things they are working on. So how will runner 1 learn about the work of runner 3 if they are working on different things? Or better what if the team is a triathlon team where swimmer 1 needs to know what runner 3 is doing? Any thoughts?
During my years as a trainer, consultant, manager and facilitator, I’ve found, received and used several YouTube video’s that explained what I wanted to get across way better than I ever could myself.
These video’s explain topics such as change, time & process management, what to do and what not to do, how to stop bad habits and pick up good ones etc. and so on. I consider them classics and must sees for every professional. As they say, a picture says more than a thousand words. Well, these videos have both.
All of you probably have seen some of them and some of you probably have seen all of them. If we would just follow up their advise.