Ola Sundvall

Tag: Value creation

  • The ‘start from a blank paper’ curse

    It aint what you might believe at first – a super-trendy writing about how to start blogging. It’s far more boring than that. This piece could also be headlined with something like “How to overcome the lingual glitch between IT and the rest” (though I realize I don’t have any clear answers, after reviewing this mess).

    This reasoning might seem a bit over-due, old school or even obsolete in the era of furious Product-Management-with-an-agile-foundation, but it will never stop being relevant. Why? Because old truths are boring but often more persistent than we actually want them to be.

    I will elaborate on one of the most overlooked phenomena that has existed even since human started to build things that in some way does human work for her – namely managing of requirements. I find it kinda strange that this discipline so often is regarded as a certain discipline, hosted outside a production workflow och outside a development project and populated by specialists that is regarded as a really special sort of nerds. The competence field QA is also often perceived as a bit self-generating and my experience is that it often is slipping around above or around the project or maintenance teams it is supposed to be integrated in*, similar to “the process team” that makes process management a work on its own merits, often regarded as self-generating as well.

    From time to time I have been involved in discussions with business representants and in the context of trying to understands the needs and what problem they want IT to solve. Many times we have been sitting with an existing solution that fits the needs ok but not fully, and trying to improve functionality already decided and designed by a third part, the vendor of a system, may it be a cots, may it be quite a specialized product (in earlier days often named service, but product is a more popular term nowadays, yet another thing to explore in a future post…).

    A repeating thing that has showed in these contexts is that the business side often have difficulties in formulating requirements so they are easy to digest for the IT people trying to technically solve the issues. Once we took it so far that we arranged educations for the business stakeholders, eg. mostly process leaders (might today be replaced by Product Owners), where we let our very dedicated and skilled requirements analyst teach requirements management to the participants. This turned out quite well for some time (not that long that we’d wished though), and lead to a little bit deeper understanding on the business side for the need of a common language when having the specifying dialogues.

    BUT – the error I think we made then was to assume the starting point too late than what we should have** – because we didn’t explore the need for the requirement to occur in the first place. Business needs is the focal point one should start looking into instead of starting a change or request journey with trying to state a requirement that might be quite intangible if the needs aren’t clarified. I have seen agile profiles in different feeds emphasizing the need discussion, but I have never seen it being more than a fragment in the never ending flood of talk-about-how-to-work platitudes. This should be a success factor in both easing the need for translation but also a possible lever for the business side to actually take more active part in the early phase of a change tickets journey in the code-crunching machinery. It has also the potential of easing the often (always) cumbersome with prioritizing a backlog, since it should be much more obvious how needs are weighed towards each other than bad formulated user stories or features with unclear business value. It also has the potential to give a clearer definition of done, if you originate from the need instead of a lingo-feature description.

    BUT – isn’t this already what all agile how to’s and agile descriptions always have told us in DoD and DoR’s explanations??

    OF COURSE – I’m not trying to come up with some new fresh ideas here, I’m just (as always) trying to point out what already exists.

    BUT – try, just try to give a business representative the explanation of DoD found here of even DoR found here, and you will get this “do I dare to question this mumbo-jumbo without being classified as an idiot” face in return. We really do need to be able to talk about needs (and in second-hand requirements) with the business side with being so centric about the IT-side lingo which is held so dearly by too many.

    Tying the ropes:
    Regarding the headline of this post: I somehow feel that I need to get back to this in order to tie this story together. One of the most common and I guess classic mistakes organizations do when it comes to management of requirements is the silly “You just can start from a blank paper” prompt, given by IT to business. It is often ditched quite quickly, since everybody knows that they need some kind of facilitation or guiding, because the present state is needed as input value, as well as different conditions and constraints that limits what actually is possible to describe if the user story is supposed to be meaningful and valuable.

    For reference:
    The explanation of what a user story is supposed to be is actually more or less good, but often overlooked and not fully embraced (or understood, or correct interpreted) by all in the processes, making it necessary to reflect over when uncertainties are spotted.

    To be continued:
    *) The QA experts should have more of a more tangible, facilitating role in the organizations they serve than they have, since their traces most often is a trove of hard-to-answer questions in the WoW-section of the endless Confluence library – for every team to invent and solve independently.

    **) This urges me to write about the real life cycle of a change or new-feature ticket in a teams workflow. Will do this as soon as possible.

  • Web3 and all of my questions, #2

    Photo by Shubham Dhage on Unsplash

    So I challenged myself to understand web3 a bit more in depth, described in the former post. I also felt a need to ponder a bit around the financial and/or business model parts. Please enjoy.

    Money or currency, in the meaning of being a representative for a certain value, is based on trust. If not trust for the actual currency can be reached, the value [of the currency] can’t be persistent. There is a reason that currency in the form we know and have defined it, is centralistic by nature since it is mostly structures in the form of regimes (nation states and central administrations) that has been (able to) guaranteeing the currency’s value by promising law and order, personal security and much more.

    We do have plenty of reasons to dive into history to see if there are traces of not centrally guaranteed currencies and to see what has been their trust attributes. Maybe I put this up on my todo list, but it feel like research best made by somebody with better knowledge in this

    What you need to manage in order to get DAO/Dapp adaption to broaden, stay and become a new norm
    Our current economic paradigm that is driving towards eternal growth, has also paved the way for centralistic and linear value creation for a very long time. The model of legal entities with limited liability as ownership model has the centralistic approach as a foundation: a possibly scattered association of owners put the entire responsibility for growth (=success) on one single role: the CEO, or Chief Executive Officer, if everything is done correctly according to the model. The owners are only to put requirements on return of the investment made.

    The limitation of liability in turn has its own limitations: the requirements are unavoidably to be formulated by the board, which is populated by the owners of the biggest shares of the company. This makes the owning more of a passive expectation (and belief or hope) on returns for the owners of small shares = less attractive from an impact possibility perspective. With all trust for success put on one role – the CEO – the risk for failure is bigger. On the other hand, with the right CEO in charge, the capability to achieve success increases largely.

    The conclusion is obvious: the centralistic nature och the Ltd company is unbalanced, which is its biggest strength as well as its weakness since the economic paradigm we have made the norm for centuries is based on growth of invested capital being the only thing that matters in the end.

    This is as I see it the biggest challenge for a DAO, at least as long as the DAO need to exist and justify its existence in a paradigm based on returns of investments.
    A fully decentralized DAO is also risking to be slowed down by the need for consensus, especially if the decisions to be made that are put in the ledger are on a very detailed and operative level. Here it is super important to find a decent balance between deciding and doing, so that momentum always is assured.

    Ways to keep DAO’s secured from intervention from big web2 enterprises is another area to explore since the web2 traditional entities have no interest in DAO’s if they don’t add on to capitalization of the web2 company in question. Ways to prevent web2 companies hijacking of DAO’s and Dapp’s and other web3 artefacts are essential as this is already ongoing.
    Reaching a critical mass of real web3 adoption in the real world is the only way to get things to happen and the ultimate questions to ask are:

    1. How should the incentives look like in order to get people to invest in web3 so that perseverance is reached as well as real competition to the traditional growth modell?
    2. How should web3 applications survive on their own means as long as the traditional growth model is the norm?
    3. How should an alternative economic model look like that can act as an alternative so attractive, that it in long term outperforms the traditional growth model, so the traditional growth model becomes obsolete? I have seen numbers around 70 years for a new economic model to replace an existent.

    There is an obvious risk that web3 becomes a vision entrapped in the large-scale enterprises of tech companies that harbor blockchain architecture in their cloud service infrastructure – would this then become a “real” decentralized architecture, or is it just web3 running on web2, and is this even a problem? I would say it can be.

    Maybe an alternative, decentralized-native infrastructure is the future. (One of) the big question(s) is how this will be payed for, and who would take the challenge, and risk, to invest in it?

  • Web3 and all of my questions

    Photo by GuerrillaBuzz on Unsplash

    I tried to dive in to the web3 universe, as I for quite a long time have heard that web3 is the future, that it can change how we live and work and that it is important for everyone to learn more about this. Until now I have bought this wholeheartedly, but also been wondering a bit why this doesn’t seem to lift off. Here in this first pondering I try to sort a bunch of reflections and questions from the more technical point of view.

    I can’t refrain from comparing the web3 ideas with a concept that maybe became more rebellious than it deserved – but it was founded on an idea of true decentralization – namely the BitTorrent protocol. Some of you might think that I’m totally out in the wild, but I’m fully aware of that BitTorrent is a file transfer protocol, and that web3 is more of a way to verify transactions that represent different purposes and has the potential to serve an infinite number of applications, it’s only the imagination that sets limits for what you actually can use web3 for. My comparison is around the decentralization idea and the absence of a centralized ownership and with that the following of one-sided determination of terms (the one who takes the (financial) risks is also the one who owns the terms).

    When individuals started to share big files with the BitTorrent protocol, nodes were growing like fungi out of the internet soil – it grew rapidly to a pirate-ish life style where the most credited were the one who hoarded hard disks and seeded like crazy, and the famous site Pirate Bay acted like a hub for a big part of this traffic – though there were a lot of sites doing the same, some with more specialized themes regarding content. I’m targeting the nodes in this comparison, since they were truly decentralized and also anonymous, since it was the indexing site, acting as a central hub and search spot collecting torrent files and in this architecture being the lever for increased and continued sharing. Nowadays torrent sharing is still active, but maybe more in the open source community where operating systems and large program files can be distributed in a way that optimizes net load and utilization.

    A weakness in this model was that not so popular files could take ages to download due to too few seeders, maybe also with too poor upload speeds. This revealed a lack of robustness – what happens when too many nodes shut down for whatever reasons and the seeders numbers decline? The availability of the asset is suddenly jeopardized, and there is no one who grants availability – what to do then? In the pirating context it was law enforcers that chased down the model to decline in parallell with the development of streaming services, making the decentralized model more centralized and more web2-ish, but the reasoning about robustness could and should be applied on the web3 idea as well in order to reflect over success factor that need to be in place somehow.

    Decentralized infrastructure – how to reach a sufficient level of perseverance, so a sufficient level of trust can be reached? What criteria do a currency need to fulfill in order to be regarded as perseverant and trustworthy?
    Which fundamental criteria is possible to set aside if one tries to imagine an existence beyond our present economic model* that postulates eternal growth, with return on investment as norm for success?

    Blockchain technology on a node published on the internet isn’t as easy to set up for a private person as a BitTorrent seed, It requires a database and some code that can do the work blockchain nodes do (where verifying transaction data is core business). Therefore we shouldn’t expect everyone who has a computer on an internet connection to be an enthusiast in hosting Blockchain nodes. This instead leads to an emergence of startups, offering robust and reliable blockchain support as a service. And this in turn, leads me to turn the page to the next post, pondering on the economical and business model aspects of web3.

    *) I imagine our present economic model as having two pillars, where one is exchanging time and effort with currencies or money, the other is investing in ideas in order to make the value of the investment grow. More about this in a coming post

  • Everything is production, really

    Photo by Arseny Togulev on Unsplash

    If I should summarize my work life so far, the common denominator for everything I have been in, made, or contributed to is

    Production

    How can that be?

    It might sound far fetched, but I can (actually) argue for this. If we look at value creation which could be another term to compete with production, I see that the process (or processes) that we draw to describe flow of value are similar – so similar so it’s more of a matter of self-identification that make you feel what sort of work you do – though I would say that you produce something in any case, because production without creation of value is non-existent (though some organizations surely do it, unfortunately).

    I will put up some theses to prove my point:

    1. Input and output (or outcome if you prefer to look at the bigger picture simultaneously)

    When we produce stuff, for instance in different industries, we need to put in raw material, instructions for how to treat these, and specifications for how we want the end result to look like.

    Value creation is more geared towards input of for instance customer needs, which isn’t necessarily tangible as some sort of hardware items – it could be totally immaterial. But there is an uncountable amount of needs through history that is fulfilled with some sort of tangible item.

    2. Resource assessment

    Both value creation and “pure production” can’t be performed without resources. The resources can be human’s time and skills, an AI prompt, machines and tools along a production line, software tools and platforms, code languages and so forth.
    Regardless of what you are about to accomplish, you need to assess what resources you need, how many you need (if the resource type is limited in it’s output per resource) and what pace you can expect from the setup you are planning.

    The exact same type of preparation is fundamental for creating value (though you rather shy for these dry and boring realities in the value creation context because value creation is something totally different and much more coomplicateed…)

    3. Manage and control (or orchestration and follow-up if you prefer)

    For production in the industry there is a lot of different and established, often branch-specific frameworks that is implemented quite well and also well taken care of, since product certifications, branch standards, CE markings and regulations require this.

    In the value creation realm things can be much less specified, depending on what type of business you’re in. It can of course be weighed down by really tough regulations and branch-specific requirements, whereas the value creation becomes constrained due to the circumstances and hopefully evaluated with that in mind.

    Finally

    To conclude this we can quite clearly see that value creation and production is just about same thing, different name.

    BUT – the value creation as a term always contains production, since folks working with production too often just see their own discipline as the almighty thing to do, where the need for customer focus, understanding and orientation etc, is overlooked.
    In these cases, there are a number of process owners and managers and so forth who constantly run around the production team and maintain customer focus for the ones refusing to adapt customer focus themselves. To defend the staff, many hardware work steps can be quite abstract to directly connect to a customer value, though they are unavoidably interconnected with an end result, which also is – an outcome.

    In for instance software businesses or IT-organizations on the other hand, we tend to push customer awareness and the need for creating customer values, not only outputs, onto the teams and resources directly. This is of course necessary and in fact fundamental in times of fierce competition and ever-evolving rapid development.
    The problem is that there are so many tasks necessary to perform, which are more of output nature and doesn’t fit in the outcome bubble since they are just secondary and more of enabling characteristics than direct wo-ho effects for the end user.
    Yet a lot, if not the most, in the immaterial producing business is about the same repetitive tasks that need to be performed, over and over again, without deviations – just like in any sort of industry… at least when we are looking at operations, which most often is overlooked since development is so much more fun to discuss.

    Meta-reflections:

    If we regard production as a subordinated process residing within a value creation – value, framework, wrapping, don’t really know what to call this entity – then marketing and sales also are subordinated processes residing alongside the production process. These are kind of production processes as well, where marketing’s output should be an irresistible urge to buy, and sales refines interested, so called prospects or leads, into buying customers.

    And existing or won customers are in turn refined to come into retention state – room for another production process… is this maybe called CRM…?