no more cubes

Tag: thought

  • On Low-Code platforms

    Drag-and-drop platforms enable developers to assemble applications without manual programming. Toyota, ConocoPhillips, and GlobalTranz are among those enterprises leveraging low-code to create business value.

    From the article

    No Code

    Low-Code/No-Code seems to be the buzz word of the current industry. There are virtually no product releases anymore recently, that don’t include features from this category. Every vendor is aiming to push something with this label.

    Only, the idea is about as old as the software industry itself.

    The sole purpose of software is to make technology available to people with less technical background. Software, in particular enterprise software, is meant to scale. To enable large scale processes to work. These processes most often require diverse backgrounds and experiences to work together.

    Standardised software products, rolled out across entire companies, if not value chains, promises to allow exactly that. With no coding required. At least not, after the integration project finished.

    Low Code

    What is different though, is the rapid speed of change. And low-code is the key to enable virtually everyone. The entire concept is about democratising technology a lot further. The big bet is to shorten integration projects and enable business users to innovate. With no IT-Department in the middle. Asking for huge budgets and long delivery periods.

    Low Code, after all, is a very old idea, but with a new, much larger, audience for enterprise software. And that’s why it’s such a game changer for the industry.

    CIO.com has an article: How low-code platforms are transforming software development | CIO

  • Product First Step Feedback

    Product First Step Feedback: Having worked in customer facing roles most of my career, I have experienced first hand how important it is for clients to get quick impressions of a product. Opportunities to leave that impression are often limited.

    The other night, a colleague argued most products don’t even need a UI. And a UI won’t even be necessary for products that aim at developers as their audience. It may be unnecessary for specific, complex products. And in general, I won’t disagree. Such products exist and still require a good first impression. Browsing open source directories at Github, popular projects come with good documentation. A readme.md that comes with building and running instruction.

    GitHub - Product Feedback
    GitHub

    In the IaaS/PaaS/SaaS world, popular tools come with first step tutorials. Quick tours to get potential users started in minutes. Google apparently made this a release requirement, since virtually all products ship with a “Get Started in 5 Minutes” section to start with.

    When I came into the product management role, I was a strong proponent of UI driven products. In hindsight, this believe was driven by the pure marketing thought of it. A UI shows better at trade fair booths than a terminal.

    With more technical products, the readme is the last resort. And with that, an opportunity to gather feedback is gone. The UI can implement tracking and analysis to build a feedback channel for Product Managers to understand how the new feature actually is perceived.

    In the software, provided it is delivered in source, the first step that could possible send telemetry, is the build process. And to drive adoption, you have to offer the customer a good first impression in documentation, before he can build your component. Should the documentation not deliver on this first step, you lost a customer even before he saw the product. If you are in the situation to receive feedback on this first impression, take that very serious.

  • Unlock your product organization’s potential by defining “done”

    Simplifying and aligning conversations with a definition of done

    All too often, the task list for your teams shared project management tool shows items like “Create Workflow” or “Define Process”. Items that do resonate well in the flow of work and in the nexus of individuals. But they do fall short of allowing the rest of the organization to grasp the meaning and even fail to do so for the reporter when some time has passed.

    Some consice expressions on expectations on what this story or ticket is about can do wonder to getting things done. Rather than “defining a a workflow”, for example the product management team would

    • Check for Duplicate Entries
    • Describe the Requirement
    • Outline all depending products
    • Draw a critical path
    • Align all stakeholders on the critical path
    • Communicate to the team

    The core idea is to eliminate any discussion about when an issue, item or story is delivered and is unique across function. Of course, the above serves as an example and will vary by team and work, and needs revision in any particular scenario. Having specific action advise will help reducing debates and focus on an actual deliverable, that is done by all opinion.

    Source: Unlock your product organization’s potential by defining “done”

  • Engineering Marketing

    One important aspect of the implementation of product management roles and organisation, is the engineering partnership. The other day I found Julia Austins article on the topic that also touched the realistic options. To re-cap, these are either market oriented or engineering oriented. Either of these have their Pros and Cons.

    My few thoughts on these two approaches:

    Product Management driven Product development – While this indeed seems to be the more traditional approach, in which a “Product Manager” collects customer requirements. Nevertheless, it’s not necessarily a setup that is favourable for Waterfall development, nor is waterfall something favourable as as such for software development. It allows an organisation to maintain the customer focus through a dedicated person, that is incentivised differently than engineering.

    Engineering driven Product development – This is an approach you can read a lot about from big tech companies recently. It requires a team that is well into the field the product shall serve, which often enough is not the case. In particular large and diversified companies will struggle to give find the right people at the right time, whereas smaller, growing companies can hire for the sharply defined purpose.

    An compromise approach is sure the PM<>Engineering partnership to overcome the shortcoming, and the responsibility to maintain a customer focus is on the PMs shoulders

  • Agile Werte

    Mein Team führt schon seit geraumer Zeit eine Diskussion darüber, wie man den Prozess verbessern kann. Und das ist auch gut, denn ständige Verbesserung ist ein zentraler Bestandteil jeden agilen Handelns.

    Allerdings liegt die Antwort auf die Frage nie in Werkzeugen und deren Möglichkeiten. Um das Problem zu lösen muss dessen Ursache verstanden werden. Jira bietet sicher viele Möglichkeiten, noch ein Feld einzuführen. Wenn die Diskussion sich darum dreht, welches Feld am besten ergänzt wird und wie ein Zustandsübergang abzubilden ist, ist das agile vollkommen aus den Augen verloren.

    Eine unmittelbare Konsequenz von Werkzeugen ist, dass sie es Teammitgliedern erlaubt, Verantwortung abzugeben. Der Zustand wird möglicherweise richtig abgebildet, das Feld richtig gefüllt. Nun ist es an jemand anderem das technische Problem zu identifizieren, die Person weiss möglicherweise nicht einmal über den Zustand Bescheid.

    Agil soll heissen, das Vertrauen aller Mitglieder im Team soweit herzustellen, dass notwendige Arbeit in Standup Meetings oder spätestens im Review transparent gemacht wird. Dabei kann kein Tool helfen.

  • Corporate Open Source

    One concept that is under active discussion for the past decade or so but constantly being misunderstood. Open Source is often taken as a label for software downloaded from the internet, packages free of charge, components under a particular license filed under “Creative”. Often enough it’s misused for lower quality software, which reality has proven wrong by 2017, not to mention the issue with intellectual property.

    However, there are many much more aspects to the concept, that add substantial value to any software centrist product organisation. And in times of digitalisation and digital transformation, software will move into the value chain of many organisation that don’t anticipate it yet. Whenever a customer offering is complex and / or service based, transparency and documentation are often key to a satisfactory result and efficient processes.

    Open source may not be the one single bullet for any organization, but the concept will help becoming more transparent and efficient.

    Single Source of Truth

    While SharePoint is a powerful tool with many opportunities to improve processes, many organisations use it to maintain a file server. Which has information about any other effort, therefore creating a large spread between the tangible product and the then theoretical documentation. Not to mention the version horror everybody experienced at least once, trying to ask a few people for the latest version.

    Reversing this process through Wiki or even Version Control Repositories allows to keep only one version, that is automatically the latest. Software will take care of all versioning, that would go in filenames_v01_final.docx otherwise.

    Transparency

    Adding together the product with documentation allows quick reference, pointing back and forth between customer facing and engineering. While this may sound terrible technical, the nasty guts of any product can still be ignored by those who don’t need to see it. However, for those requiring insight, they don’t have to go through a process to see it. Or even have to talk to a colleague first and ask. Oh, and the colleague will be on vacation anyway.

    Opening the product internals will remove any barrier to productive work and allow employees for quick insight. Obviously, some may argue an open repository may lead to uncontrollable product results, but that’s actually a different point. Write access or merge credentials are not required for anybody without responsibility.

    Applicable Metrics

    To shape it all up, the management world has plenty of nice metrics that can be applied to measure the whole thing. Not all of them express quality by themselves, but applied consciously these can carry a product far.

    Documentation Coverage is something that will serve as a great basis for the point I’m trying to make here. With closed projects, or engineering only code, it’s often difficult to understand whether a product, feature or bug is actually just badly documented or the colleague just doesn’t want to help.

    With a metric to measure percentage of a product being documented, at a minimum the amount of available documentation can be measured. And with the product internals being transparent, any reader can – at least theoretically – see whether the documentation correctly corresponds.

    Conclusion

    While being a strong supporter of open source software in general, I’m not trying to make a point for open sourcing anything outside an organisation. However, transparency will help any organisation improve the offering and processes. And the concept of open source will help achieve this transparency. It has a hurdle to overcome, in particular management will have to overcome their fear of software and technology to adopt this concept, but the step is worth taking on the way to digital transformation.

  • Mix and Mingle

    The past weekend I traveled internationally to work with colleagues on another continent. I’m a lucky volunteering member of IEEE, and so I reached out to the community before I jumped on my flight.

    Turns out I have friends in this city, and so I spent a whole afternoon learning about the city and the eventualities it brings along.

    Both my old friend and me agreed throughout our conversation that networking is an important activity, and having built an extensive network is an enormous asset.

    While IEEE is only one opportunity to meet people, it is a solid recommendation for engineers to actually pick up this activity in first place, even though it may not seem obvious at the beginning of the individual career. Working with and knowing many people is all too often underestimated and need strong soft skills. But even those can be trained, just like engineering can be tought.

  • Is cloud computing truly, truly disruptive?

    “Disruption” is one of those words that has been overused, being applied to every little product or service that comes to market, or every new company that emerges. Cloud computing and digital technologies, for example, are branded by many as “disruptive.” New services and business models sweeping through markets, such as Uber and Airbnb, are […]

    Turns out, no, the cloud itself ain’t disruptive. But the availability of on-demand computing resources enables businesses to come up with ideas more easily and the service based approach disrupts businesses.
    via: Is cloud computing truly, truly disruptive?

  • eMail. Still.

    Year 2015. Still eMail is the predominant means of communication. Everybody hates it, most companies make an effort to ban it. Atos wanted to go email free, Telekom shuts off their servers, Daimler even deletes email for people on vacation. Even I receive emails, saying “I need this, but I cannot answer”, quoting the “email free day policy”. Despite all effort, nobody succeeds.

    Why? Unclear. While I think email should be banned myself, I have difficulties offering a better option. But I develop a feeling for why this is happening. This morning somebody mentioned he’ll be posting into a slack.com channel. That company claims to simplify communication, make teamwork less painful and busy, all searchable. As if nobody else tried that. And even if slack.com does a good job in what they aim for, they are just another solution.

    In my personal, active use are trello.com, Pocket, Salesforce chatter. While my company introduces a community, colleagues swear on private Facebook groups or WhatsApp for simplified communication. Not to mention the tools customers and businesspartners are using. Popular among these are Jive, Atlassian Jira, SAP Jam, but not limited, I’ve seen self hosted communities, bug trackers and ticketing tools.

    It’s difficult to keep track of all these tools. But they all send notifications through email.

    Which tool do you use to communicate?

  • Disruptive.

    Disruptive Innovation, as a concept, is overused in business literature to an unbearable level, and almost permanently misused by startups and self proclaimed thought leaders, describing their own new app or promoting their own blog.

    And no, Uber is not disruptive, either. No app monetizing on people sharing things is. Internet to allow this, is.