I’m running a little survey – 5 minutes of your time – about the people and roles who decide what should be done, or perhaps what should be built. The people who are often called Product Owners or Product Managers, and often Business Analysts, perhaps Requirements enigneers or… a myriad of other titles. I’m generically calling these people Product Leaders or Product Authorities.
Anyway, if you can spare me 5 minutes it would be grate to have your answers – survey is here, just a few questions.
I recently stumbled across David Rogers’ book The Digital Transformation Roadmap and found myself nodding in agreement with page after page. Many of the points and arguments Rogers advances are expressed in my own Continuous Digital, I see two differences. First off Rogers is an established academic at Columbia Business School, so he approaches the topic with rigour. Second, he tackles the subject from a digital business starting point, Continuous Digital grew out of the agile and #NoProjects movements. Still, they end in the same place.
One of his models keeps coming up in my discussions with Product Leaders again and again, he calls it the Rogers Curve. Like I do in Continuous Digital he points out that the venture capital industry funds technology products very differently to corporations. A corporation minimises risk by doing lots of up front research, validation and planning. Then, if everything checks out authorises big expensive projects. When things go wrong (because the research missed something, validation was flawed, plans were too optimistic, delivery was more difficult than expected, or, importantly, the time spent making sure the money wasn’t misspent delays the work so much it has lost value) then it is difficult to cancel work because the momentum is high.
Conversely, venture capital firms invest far smaller sums of money on far less evidence, research and planning. Additional funding is only given if ventures make progress on validating the model and delivering. VC firms offset risk by placing many “small bets” which they expect to lose. As long as a few bets succeed big they will make money overall even if they lose most of the time.
In Continuous Digital I argue that all technology work should adopt this model. Rogers suggests something slightly different. His Rogers Curve combines the two. He says: when uncertainty is low then use the traditional project model with the upfront validation. However, when uncertainty is high then use the VC model.
Uncertainty might come from using a new technology, entering a new market, creating a new product for an existing market, or some other source. Naturally, certainty comes when none of these is true. Which begs the question: “why bother?”
Remember that much uncertainty is actually risk. According to economists: profit is the return for risk. If you eliminate the risk then eliminate the profit.
Imagine for a moment you see a market opportunity. You see that existing technologies can be repurposed to meet this opportunity. You easily ascertain that potential customers want the product and will pay. Best of all, you see that little work is needed to seize this opportunity. The stars align. You are in business. But, if you can see this opportunity and how to fill it the chances are others can too. If they haven’t already done this then they can quickly copy you. You have no defence from competitors. No risk, no reward.
Back to the Rogers Curve. This provides a great way of looking at future work: do we feel safe? Yes, then big up-front investment. Or do we feel uncertain, exposed to risk? In which case give it a little funding, review and refund often. And be ready to walk away.
One problem I do see with the curve is the “But we know” problem. Specifically, I remember one executive sitting opposite me and saying “We know what needs doing. We know who are customers are and what they want.” Needless to say they didn’t. The company became a lot more successful when they started acting as if they didn’t know (and sacked that executive.)
This happens all the time. People and companies are sure they know what is wanted – cognitive biases are at work. Version 2 technology rewrite projects are a classic example. These always have big problems. There is an assumption that the “only thing” version 2 needs to do is everything version 1 does, just on new technology. These projects always end up in trouble (but that is another post.)
Part of me thinks this curve is unnecessary because the little-and-often funding model will work in a certain world just as it works in the uncertain. But, corporations aren’t set up to work like that. Corporations are set up to fund and run big projects with lots of upfront work. In other words: corporations are not optimised at doing lots of small.
Jumping to a new model in one go is hard. Far better for the corporation to carve out some innovation money and a ring fenced a unit to spend the money. Call it an innovation unit, a lab, an incubator or whatever. Within this unit manage investments differently using a VC-style governance process. The money needed will be far less than one big traditional project to start with.
This unit can accept small innovative ideas with little market research, validation or planning. The minimally viable teams which are funded here are tasked not just to build the thing but to validate the ideas, exploring options, understand potential customers and everything else a start-up would do.
Now at this point some readers will be saying “We do that.” As Rogers points out, and I’ve seen myself, companies do do this but only sometimes. They don’t do it systematically. Nor do they do it repeatedly. Running these types of initiative, and more importantly governing them, is itself a skill set and process which needs developing itself.
Many companies can point to instances of innovative products managed in an innovative way. But such initiatives have to fight through a system which is designed to stop them. They succeed despite the system not because of the system. How much more successful could the company be if it created support mechanisms?
Last time I described how to estimate value on story cards. Now, lets talk benefits. Ultimately, the real value of this game is the conversations it creates. But along the way there are plenty of other benefits. The licensed dissent the game allows creates many insights and ideas.
The most obvious benefit of Value Poker is simply: at the end of the game you have a value based priority order. A team could, simply, take the highest value story and start work on it, deliver it and move on to the second highest. What could be better?
But actually, having value on the cards brings many other benefits and creates many options. For a start, having thought about the value of individual pieces ones perspective on the work to be done changes. What looked like a large chunk of work, a single monolithic product, might look like a stream of valuable features.
Value beats how-long
Moving the conversation away from “how long will it take” to “what value will it create” provides a whole new perspective. One which many have never appreciated before.
Rather than simply start at the highest value and work down conversations about the order of work become more than just technical “A depends on B.” One can think of value dependencies: customers can only get high value A they also have low value D. In which case, is D really a distinct thing, or is it part of A?
Both technical and business dependencies are exposed. All sides get to see why doing the most obvious thing might not be the right thing to do. The team might consider how else they may unlock the high value story without the need for the low value story. Maybe a subset of low-value D should be included in A. And maybe the rest of D isn’t worth doing.
Sometimes these insights only appear because teams are able to be adversarial. In most work environments people show respect. If a Product Leader ask for something few would openly say “That is pointless” or “Why would you do that?” but when playing Dragon’s Den people are allowed to openly question and think-outside-the-box. Indeed, since many have seen the game show people naturally fall into the roles and need little encouragement to challenge ideas. It becomes easy for a lowly engineer to say “I don’t see the market for this” or “Why would I buy this when product XYZ does that?”
Better than Word and PowerPoint
This in turn leads to two more benefits. First the Product Leaders need to be clear about what they want, why they want is and why they see value. They can’t hide behind PowerPoint charts or long business plans, they need to explain their point and defend their position in real-time. Product people are made to up their game.
People sometimes say to me “These two stories can’t be compared, they are like apples and lemons.” But money – even fantasy money – is a great leveller, it measures such asymmetric things. After all, the money you get paid for labouring over a hot keyboard each day can be used to pay your rent, buy a beer or take a holiday. How else could you compare the value of having a roof over your head with drinking beer?
This approach allows everyone involved to have a say. All the brain power in the room, all the knowledge, all the neurodiversity, can be exercised and used. New ideas, start flowing. Dragons and Product Leaders frequently see new or missing features which could be included enhancing innovation benefits.
In one game the Product Leads were proposing an app based around lunch time food trucks. They pitched story after story to the Dragons who gave it low value. The idea didn’t fly. After a quick consultation the entrepreneurs switched from pitching stories with benefit to food truck operators and pitched on Hungry Jo customers. The valuations rocketed. This is where the value was.
With all the discussion, the challenge, the reply, the adjustment something else happens: everyone builds a great shared understanding of what the product is supposed to do, how the entrepreneurs see it being used and who the target audience is. It becomes a great way to understand requirements and specification – far better than reading a dry document or even a PowerPoint presentation. This is why even playing this game with the engineering team can be highly rewarding.
Scheduling to maximise value
Believe it, or not, giving the stories a value can also help with scheduling – even without effort estimates. Once a story has a value one can ask “If this story is work 100,000bp today, what is it worth next month? in six months? in a year?” If the value never changes then the story can safely be postponed indefinitely because the value is always there. If on the other hand the values falls rapidly then the story needs doing soon. Sometimes, there might be more total value from doing a low value story (which will loose value soon) before doing a high value story which will hold its value.
Some readers will notice this is the start of a cost-of-delay conversation. One might now start to talk about Time-Value Profiles. Equally, only when you have value on individual work items can you really start doing cost-benefit, and biggest-bang-for-your-buck, analysis.
Finally, one big benefit I hope you’ve realised along the way: this game is a lot of fun. Not only does it help teams understand but it helps teams bond.
Want to play?
If you would like me to run this game for your company or your user group or meetup please get in touch.
How often has someone on your team said “We should prioritise by business value” ?
How often have you heard someone say “We should do the biggest bang for the buck” ? – “lets find the quick wins which deliver the most value” or “Lets do the 20% that delivers 80% of the value.” The more studious people may call it “cost-benefit analysis” but it amounts to the same thing.
Yet while teams are quick to assign effort estimates – hours, days, story point or some other unit of measurement – very few teams add a value figure. When you think about it – and you only need a moment here – how can you do cost benefit analysis if you only know the cost? Without a number any attempt to “prioritise using business value” is likely to end up in decibel prioritisation, he who shouts loudest wins.
In fact, it is quite easy to estimate value in the same way we estimate effort. I’ve started including this in my product leader training workshops a few years ago and have seen game-changing results when used with clients. In one case estimating value allowed a client to remove more work in two hours than the team had delivered in two sprints.
Here I’ll describe how to play the game, the next post will describe the benefits and how to exploit values once you have them.
In the past I’ve improvised with value poker cards but the good folk at Agile Stationery have created a dedicated deck with 6 colour coded sets of cards.
I like to set the game up like the TV show Dragon’s Den – Shark’s Tank in the USA and other names in other countries. On TV four or five investor “Dragons” sit on one side of the room while a series of entrepreneurs (usually in pairs) pitch their product for investment. After the pitch the Dragons get to quiz the entrepreneurs and, after a little negotiation, may decide to invest in the product.
In my version the entrepreneurs are played by a pair of product people – these might be Product Managers, Product Owners, Business Analysts or someone else who works on the “what should be build” question. They start by pitching the product, or if the product exists, the goals of the next increment.
On the other side of the room sit my Dragons. These might be senior managers, other product leaders, actual customers or the engineering team who will build the product. Each role brings its own take on what is happening and adds value so don’t feel that you don’t have the right people.
As in the TV show the Dragon’s listen to the pitch and ask questions. Once everyone understands the product – or increment – is going to do the game differs a little from the TV show. Now the product leaders switch to pitching individuals stories – I say stories but these might be epics, features, functions, capabilities, or whatever the unit of work is that your team use. I’ll call them stories for now.
I take one of these stories – one I think is low value, preferably the lowest value. I hold it up and read it to everyone. Next I take a pen and write “10,000bp” on it, I tell everyone that this story is worth 10,000 business points – sometimes I invent a currency on the fly, perhaps the London Dollar or the Swedish Franc. It is important that the currency is not real, if it was people would argue about the valuation but it is the ratio between values on stories that is important not the actual number itself. Finally, I post the card where it can be clearly seen – on a wall, whiteboard or flip chart.
This done I hand each dragon a set of value poker cards. Each set contains about a dozen cards ranging in value from zero to one million.
Switching back to the entrepreneurs, one reads out the story, adds any description they think helps and the dragons reply with questions. When everyone has a good understanding of what the story is I ask the dragons to put a value on it.
As with planning poker dragons are asked to select up one playing card to indicate the value they put on the story but initially keep it secret. I count down, “3, 2, 1 – show ’em” – the dragons reveal their cards.
If there is a wide variation in votes – say three people vote around the 1,000bp mark and one 10,000bp we might have a discussion followed by a revote. More often than not I simply average the scores and write the value on the story card. For example, if four Dragons have voted 500, 1000, 2000 and 10,000 I might write “3,375bp” on the card. I then post the card on the wall relative to the others. So, a 3,375 card would be below a 10,000 card.
Usually I will impose a No Duplicate Values rule so if the next card also comes out at 3,375 I’ll ask the Dragons “Higher or lower?” We’ll adjust the value a little, say up 3,500 and place it higher.
We keep going through all the stories the entrepreneurs wish to value. Usually the second product leader will be selecting the stories they think will get a high value and feed them to the first. Sometimes they will write out new stories to cover ideas which have come up during the game play.
At the most basic levels the values suggest the order of work. Yet actually, as I’ll discuss next time, there are a lot of conversations that can now be had which were not possible before.
One time I did this exercise with a client team. The Product Lead from my team had already divided the stories into Must, Should and Could and the clients were asked to value only the Musts. Still, several stories came out with zero value. The Product Lead might have seen them as must haves but the client didn’t give them any value. Sadly, those stories represented more work than the engineering team had done in total over the last few sprints.
Next time I’ll write more about the benefit of putting value on your stories.
In addition, to Milton Keynes tomorrow I have tentative plans to run this session at events in London and Oxford later in the year, more details to follow.
I have happy memories of the days when was doing my masters degree and I would be among the first into the University library. After my morning swim I’d breakfast at the cafe opposite the library and when it opened I’d be straight in. Up to the top where I would sit for the next 3 or 4 hours completely absorbed in my studies. Reading, writing assignments and later my dissertation. I was working towards something and had complete focus. I would enter the fabled state of flow.
While flow is hard to define its an idea that occurs both personal level – as I just described – and at the organization level. Personal flow is hard enough to come about but organizational flow is an order of magnitude harder. So much more needs to be co-ordinated. You need a flow friendly system, it rarely happens my accident.
Digital tools make flow both harder to achieve and more important. The constant stream of interrupts, e-mail, WhatsApp, notification, updates and so on, makes flow more elusive. But when machines do most of the “heavy lifting” work what remains requires human thinking. Focus and flow.
If machines companies are to get the most out of their machines the machines too need to enter a state of flow. If they are regularly stalling, maybe because they run out of parts, something fails or another human intervention is needed then they will not deliver their maximum return on investment. We, the humans, need to engine flow for the machines.
That’s why the Featureban game in the video is so important. It helps us understand the process of work, the work flow. Its kind of a throw back to the days of “time and motion men.” But really what we are doing is debugging the work system and keeping it, well, flowing. The game illustrates what happens when things go wrong and how we should respond – which can be counter intuitive.
For example, consider the players in the video: each one an expert agile/kanban coach who understands how problems arise. But it doesn’t require much before these players have created a mess. Its possible the mess would have been even bigger if the players were not such experts!
There is little anyone person can do to fix the problems. (If you want another illustration watch the old HP Stockless Production video also on my channel.)
Also notice that once Mike changes the rules of the system everyone does better. The rule changes, limiting WIP, are counter intuitive to many people but they work. Throughput is increased, output rises, and we can reason about the system.
The is also a socio-technical aspect here – as Russ Lewis points out near the end. In the first round when things aren’t going well a lot of dark humour passes between the players. I’ve worked in many companies like this: things aren’t going well and such humour is the coping mechanism for people who don’t feel in control. Actually, in the video the players are often channeling real-life complaints made by staff and management edicts which make things worse.
A lot of this dark humour replaces serious conversation about how the team could do better. The team feel powerless to change things so they don’t.
In the second round there is less humour but a lot more productive discussion as team members seek to work together to improve flow, increase output and resolve difficulties. Good flow leads to better flow. Humour gives way to satisfaction at a job well done.
3 ways to learn about flow
1. Flow may be hard to define but you know it when you see it. If you haven’t watched it yet what are you waiting for? The Featureban flow experience.
2. Now I’m please to announce that the template we used to play Featureban is now available in KanbanZone and is free to use. I’ll post instructions soon but I think you can probably work it out yourself.
3. Finally, join my online Featureban Flow Experience game on June 24th (code “ABlog20” gets you a healthy discount).
Every team is in a search for flow, achieving flow requires and a view of work-in-progress – WIP – and frequently the use of work-in-progress-limit. Identification and removal of blocks and bottlenecks isn’t enough, one needs to engineer them out.
Easier said than done? – I’m glad to unveil a new video to help illustrate these ideas and a short online workshop next month for people to learn by doing.
For both I have to thank Mike Burrows for inventing a game called Featureban. The game broadly models a Kanban system and shows how work becomes marooned and how WIP-limits can help address the problem.
Mike’s original Featureban game is a physical game (download it here), I created an online version which I’ve run a few times with clients. With the help of the good people at KanbanZone, Mike and I recorded a game last month and this is the video which is now free to watch: Featureban Flow Experience.
I’m running the Featureban workshop again in a few weeks, use the code ABlog20 to get a discount on the tickets.
Watching the video after the event reveals lessons which were easy to miss at the time. What I find particularly interesting is that the game is played by four experienced agile coaches but it still very quickly descends into a mess. Even in the second iteration when WIP limits are imposed the coaches find it difficult to work in the best way – even though they all know how to!
This shows how workers are often prisoners to the system they work within. The rules, and expectations create constrains. Changing the rules, actually imposing stricter rules, encourages people to co-ordinate work more closely.
Anyway, watch the video and draw your own lessons. Better still join me in a few weeks time – once you’ve played you will want to play it with your colleagues.
By the way, we are playing using a visual board called KanbanZone – perhaps the only visual tool I actually like! We will soon be making a free Featureban template available on KanbanZone. If you sign up with my link then you will get a free trial and can play the game yourself.
Small, small, small – I have spent a lot of my career arguing for small: small tasks, small user stories, small teams, small releases, small funding increments, small “projects”. I argue we should get good at small and optimise our systems for doing lots of small. I can justify my arguments – Project Myopia or Diseconomies of Scale. Small makes sense.
But…
While focusing on small is good for delivery it creates other problems. In truth, no solution is ever without consequences and few have no negative consequences, all we can strive for is more positive consequences than negative.
It is not enough to get good at small in delivery, one needs to couple that with an understanding of what is commonly called the bigger picture and which I prefer to think of as the broader picture.
The failure to situate small in the broader context underlies many of the problems we see in the work place today. Take work management, ignoring the broad leads to micro-management, disempowered staff, frustrated employees and collaboration failure.
Product Owners – I include Product Managers here – are failing because they are failing to see the broader picture: what is the problem we are trying to solve? how can we bring value to customers?
Product people are too often too focused on features. While I’ve recently seen some point the finger of blame at product owners/managers I think they are only responding to their environment. Companies are operating feature factors and sales are made on features, people think more when they should think better. Product people need to get out and meet customers and bring what they learn back to they can try and change the inside.
The feature, feature, feature attitude is also behind the backlog fetish which leads to backlogs stuffed full of ideas which are never, ever, going to be implements.
The discussion needs to be broadened. We need to get away from quick-wins and features, we need to think more broadly. We need to think about the big things: goals, objectives, purpose and even meaning.
Post pandemic it is common to hear of people seeking meaning in their work, no wonder so many people are dropping out of the workforce when the best they are offered is “more stuff to do.” In looking at broader goals we also need to recognise goals within goals, we need to uncover the hierarchy of (possibly competing) goals, call them out and work with them.
Thats is why I am keen to emphasise outcomes over outputs and its why its tempting to think of a great big funnel containing a machine for breaking the big into small (or Rock Crushing as my old friend Shane Hastie would put it.)
The challenge is to combine the need to focus on the small for delivery while also being able to think broadly. In part it is this challenge that has caused me to focus more on agility over agile.
Another part of the solution is iteration: we spend a lot of our time in the small focusing on delivery, but from time to time we surface and consider the wider context. Thats why I embrace the OKR cycle, it gives everyone a chance to understand both and take part in both discussions.
Underlying so much of my work over the years has been a desire to remove intermediate pieces: like having a coder speak directly to a user rather than through a BA, its one of my objections to projects (which claim to show the big picture but actually represent a restricted view), its lurking in my dislike of estimates, and its part of my dislike of backlogs.
Asking people to carry the broad picture in their minds while working in the small is asking a lot. Thats why the cycle of thinking broad, setting goals, then switching into narrow mode for delivery works so well. Its fair, it includes everyone and it gives everyone the reason why we do what we do.
In short, we need to think broadly when deciding “what is the right thing to do”, then switch into the small to deliver. Importantly, we need to share not just that thinking but also the discussion. Everyone has a right to be heard.
If I may paraphrase the late Madeleine Albright: “What really troubles me is that agile is getting a bad name because it is identified with imposition and occupation. I’m for agile, but imposing agile is an oxymoron. People have to choose agile, and it has to come up from below.” (Albright was talking about democracy not agile, if like me you associate agile with democracy the sentiment is no surprise.)
I’ve spent much of the last 20 years helping companies and teams adopt agile. A lot of people are cynical about agile today but I still see benefits. A lot of the cynicism comes because all agile initiatives are flawed – every single one.
Whether you call it agile transformation, agile initiative, agile change or simply agile adoption all are flawed. While I like to claim success for many of the companies I’ve worked with I also see flaws in my successes.
Some agile transformations are flawed in conception. I’ve worked on a couple of these and find them soul destroying. Typically change driven from the top, a big consultancy is probably involved, there may be a roll-out plan and success is measured on some kind of “maturity assessment” – are you doing stand-ups? do you have a product owner? is your backlog burning down?
These kind of agile transformations focus on “doing agile” rather than being agile and achieving agility. I feel sorry for everyone involved but what are senior leaders supposed to do? Imagine you are the CEO of a legacy bank: you know agile is good, you know all the other banks are trying it, and you know digital transformation depends on agile transformation but what can you do? You have little choice but to call in a big consultancy and impose it top-down.
The other kind of flawed agile transformation is, to borrow a phrase from Amy Edmondson, “the right kind of wrong.” These are flawed by success, although it might not feel like that. It is hard to recognise and harder to live through. I’ve seen plenty of these too and, if I think about it, some of these flawed initiatives were my greatest successes.
Be agile to be agile
It is because agile transformations efforts are flawed that we practice agile. Agile is not the end state, it is the way you operate. There is no final, fixed, state.
It was Jutta Eckstein who I first heard describe agile as a problem detector. While some agile tools make things better as soon as applied them other help you see the problems you face. There might be an agile tool to help with the problem or you might need to fix it yourself. This is especially true at the level of the organization, Agile OKRs make this really clear.
Agile transformations which work well are flawed because success breeds success: each success lifts you higher and you can see more problems. A successful team will want to make more change. Remember by maxim: “The only thing you can do wrong in agile it doing it the same as you did 3 months ago.”
Before long successful teams find changes are needed beyond the team. Maybe the marketing department needs to forget about annual big launches, maybe the HR department needs to change bonus systems and so on. The successful agile teams sees the initiative as flawed because they need more.
At the same time, people in those other groups might be seeing the successful agile team and want to copy them. But because they face their own obstacles they can’t.
To those on the periphery of these teams – typically managers – this can look like conflict, tension, complaining, and even agile failure.
Whats happening here is learning: agile is learning. When teams are successful they don’t just learn about sprints and WIP limits, they learn what else needs changing to be more successful.
It is actually good that they see failure because failure is a great motivator for change. When something is a success why change? When something fails then fix it! Inside those problems are opportunities to be even better.
Agile OKRs
Which brings us to OKRs, and specifically Agile OKRs. One of the reasons, despite myself, that I like came to like adding OKRs to agile: because they open up new vistas to see and address problems, and thereby enhance agility.
I have been talking about OKRs as “just in time story generators” for some time, increasingly I see them as change drivers. Adding OKRs to agile doesn’t solve problems overnight, but it does make some problems clearer, like the run away backlog. Working with Agile OKRs means ensuring OKRs are set bottom-up, which demands that leaders are clear about strategy. Too often leaders aren’t clear about strategy – sometimes because they don’t have one. Agile OKRs allow us to address that problem.
The challenge is to keep the faith and keep working to fix your flawed agile transformation. It is in being agile that we become agile. Which is pretty much democracy.
I’ve long seen two big problems with Product Owners.
First, Product Owners don’t talk to customers as often as they should.
Second, the Product Owner role is frequently set up to be little more than a Backlog Administrator.
Now these two problems aren’t completely unrelated. If you are simply a Backlog Administrator what is the point of talking to customers?
For a while now I’ve taken a broad interpretation of the Product Owner role. Yes, it was introduced by Scrum, and Scrum defines a very powerful Product Owner (which I agree with). But, the Product Owner role has become a general term for “the one who should decides what needs doing next.” Simultaneously the role has become undermined and very few Product Owners seem to have the power to decide much more than the next couple of items.
The Product Owner role seems to make Product Managers and Business Analysts nervous. It shouldn’t, both Product Managers and Business Analysts are types of Product Owner. After all, while the Scrum definition calls for a powerful PO it says little about how the Product Owner knows what they need to know to make decisions. In my book – and yes, I cover this in Art of Agile Product Ownership – that knowledge usually comes from being a Product Manager or Business Analyst.
Recently I’ve been taking talking to my subscriber base and the issue of Product Owner comes up again and again. While nobody thinks Product Owners should be Backlog Administrators most Product Owners in the wild are just that, Backlog Administrators.
In some cases people think it is because of their situation. “In the public sector Product Owners are not honoured…”, “In Germany, Product Owners are not valued”, “In the outsourced development market the contract ties the PO’s hands.”
Actually, its everywhere. Product Ownership are failing everywhere.
In many cases I’ve seen Product Owners who are “battlefield promotions”. A coder is picked to be Product Owner on the grounds that Scrum demands a product owner and they are “The best coder” (or perhaps the worst), “they understand the system”, “its a technology project” or some other weak criteria. Real power continues to be vested elsewhere.
In other cases the Product Owner comes from “the business side” and has little understanding of the technology, how technology teams work or what is expected of them. Consequently the technology group run circles round the Product Owner.
There is a reoccurring tendency for Product Owners to become the Product Dogsbody and pick up the things that nobody else wants to do. Other times the Product Owner is seen as the team leader by those outside the team, however they hold little real sway inside the team (because they are a Dogsbody, Backlog Administrator, coder who is acting up or new to technology).
But the thing is: we can’t blame the Product Owner for any of this. They have been set up to fail by people who don’t understand or respect the Product Owner role, real power is withheld from the PO. Possibly because giving the PO power can seem like reducing ones own power.
As a result the role as an operational necessity (because Scrum or SAFe say there should be one) rather than the Strategic Role which is should be.
Perhaps one mistake I’m making here is: using the term Product Owner. Perhaps it is too connected with Scrum, and in the same way that Scrum has been devalued maybe Product Owner has too.
So, how do we fix this?
I’m not sure. Perhaps we should dump the title Product Owner, maybe everyone should use Product Manager – although that title too is misunderstood. Product Leader could be an option but I’ve also heard complains about that. Product Expert? Product Analyst? Product Person? – would any other name help?
In the past I’ve run a Strategic Product Owner workshop which aims to give POs the skills to operate more strategically. But for this to happen someone at a more senior level has to ask for the workshop and ask POs to be more strategic.
One option, is for Product Owners to meet customers. This will both inform their decision making and give them the legitimacy that comes from customer contact.
A brave PO can simply start thinking and acting more strategically, they can put themselves in the driving seat and start making decisions. While I think this would often work it requires a brave person who is willing to risk their job. (And please, meet some customers before you grab the controls!)
Ultimately the good, knowledgable, powerful, product people are key to achieving agility, failure to give such leaders power puts limits on success.
I see no-code and low-code (or is is locode?) advertised and sold as a good thing. The “replace the programmer” movement has long existed. But it scares the hell out of me – let me tell you why and maybe you can tell me why I’m wrong.
In many ways ERP systems are the original no-code platforms. They are sold as “no coding required, just configuration”. Over the years I’ve worked with many clients who have, or are building, such systems. SAP, Oracle and Dynamics are the best known but there are many of others like Agresso and several descendants of PickOS (e.g. Rocket) which are similar.
Like no-code/low-code, these systems claim configuration is all that you need. While you might be able to programme these systems if you really need too (SAP has the Cobol ABAP language, while Microsoft offer X++ for Dynamics) they aren’t sold or marketed that way. But this is where the problems start.
Configuration is more than just clicking on settings and navigating down to a checkbox. You are instructing a machine how to work and those configurations need testing. While you can safely assume the system knows how to calculate 15% sales tax on a transaction is it applying the rules correctly? What about exemptions? And, in the case of VAT, the location?
As I’ve said before, this creates at least a cultural problem because the people who “configure” these systems (which might mean using ABAP, X++, table configuration, SQL like rules and more) don’t consider themselves programmers. That in turn means they shun things like testing, source code control, versioning and ideas like cohesion, coupling and abstraction.
In fact, some of the systems I’ve just mentioned don’t even support these ideas. When I first encountered SAP I tried to have a conversation with a “consultant” (not a programmer note) and discuss versioning. I failed, the gap between their model of the (SAP) world and mine was so different we were speaking different languages.
I’m told SAP has got better but in some no-code ERP systems there is no concept of exporting configuration. You can create and test your changes on one machine but if you want the same thing on another you have to go and repeat your pointing and clicking. This just seems brain-dead to me.
This might all work in the small but as your solution grows and grows, as you need to make changes in many places, it becomes more complex. And since there is no source to control and no concept of versioning how do you go backwards? What if your configuration is wrong and you need roll-back? Go and reverse your point and click.
This also bodes badly for testing. As the rules and options get more complex you will want to test them to make sure all the changes work together as intended. How do you replicate them to a new system? – if you are lucky they are all in an XML configuration file but now you are back to source code control which is foreign to many non-programmers. Worse still, because these system have few options for “unit testing” (or just small tests), you tend to need to test the whole thing which makes tests more complicated to create, slower to run, and less useful.
Next think about recovery: what if your machine is hacked or just fails? Even if you can move the configuration to another machine how many of your systems are dependent on the name of the original? – after all, machine name is a configuration option, your non-programmers probably haven’t abstracted it and worst of all, you have to manually find and change every example.
Perhaps worst of all, your configuration, your solution, is very very dependent on your platform. In my younger days I ported C++ from Unix to Windows and back. It could be tough but you could do it. Try porting your no-code solution to another platform. No-code means lock-in.
Many of the practices which make programming into software engineering are about creating a road back: version control, source control, build, deploy and, of course, tests. The problem is that when no-code solutions throw away code they may be throwing away all of these things too.
So, am I irrational to worry about no-code and low-code? – if some no-code/low-code advocate would like to explain to me how these problems are addressed I’d love to hear from you.
