# Upday Published articles for Upday. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## About Building Trust DevFeed: [About Building Trust]() Original publisher: [Read original article]() Author: Srikanth Achanta (srikanth@upday.com) Published: 2017-09-18T22:00:55Z Content type: opinion Language: en Sources: [Upday]() Topics: [trust](), [Software]() Tags: [change](), [company](), [cost](), [creativity](), [innovation](), [management](), [people](), [team](), [trust]() ### AI overview The article explains how distrust can increase operating costs and reduce creativity in software organisations. It describes three stages: blame shifting, risk-averse and complacent behaviour, and distrust becoming embedded in the company culture. It recommends acknowledging the problem, improving communication and aligning words with actions. ### Source excerpt Trust is the most precious resource in any organisation. For modern software organisations, which depend heavily on its employees for its success, trust becomes of paramount importance. When trust is a topic, it's clear that there is a deficit of it. It is a dangerous state to be in and it mainly affects the company in two ways. Increased cost of operations (by many fold) and shrinking space for creativity/innovation. One hurts the business in the short-to-medium term and the other hurts in the long term. When the atmosphere in an organisation is one of distrust, people lose patience and empathy for others, and everything they dislike will be seen as a problem/failure. If a feature is delayed it's due to an incompetent engineer; if sales targets are not met it's due to a poor tech setup; if the office looks empty it's because engineers don't take their work seriously; if the vision or strategy is not clear it's due to poor management; if the product roadmap lacks 'interesting' features it's due to incompetent POs and so on. This is Stage One. Although exaggerated, if you look closely there is some truth (among all the excuses) in these statements, but people refuse to accept and change. They are instead busy shifting the blame onto others. In Stage Two, engineers start adding more buffer to their estimates so they are never late, sales targets will be set so low that it's hard to miss them, the office will look full but nothing gets done, fancy features are added to please people rather than users, workshops will be held to come up with catchy vision statements, etc, etc. People stop taking risks and they become complacent. They add additional layers of insurance to their work to feel secure. All these activities take the time, money and energy of the team, which should otherwise be focused in achieving business goals. In Stage Three, the most dangerous phase of all, distrust becomes part of the culture. Every new initiative, new decision, new idea, new process will ## Upday's Journey from Monolithic Backend Components to Microservices DevFeed: [Upday's Journey from Monolithic Backend Components to Microservices]() Original publisher: [Read original article]() Author: María Fernández Pajares (maria@upday.com) Published: 2017-08-22T22:55:55Z Content type: article Language: en Sources: [Upday]() Topics: [Back end](), [Architecture & Design](), [Microservice](), [Java](), [Spring Boot](), [Ruby]() Tags: [architecture](), [backend](), [conway-s-law](), [java](), [microservices](), [ruby](), [spring-boot]() ### AI overview The article describes upday's backend architecture journey, beginning with Java and Spring Boot monolithic components and later moving toward microservices as the company and backend teams grew. It also discusses how architecture and team structure can shape each other. ### Source excerpt I have always wanted to write about our journey through the world of backend architectures. As a developer, you may have been facing problems related to this topic in your team or with your projects. You might even be aware of the magical and trendy solutions out there, but sometimes these don't perfectly fit your current needs. This topic has not been - and it is not yet - an easy one for us either, but after facing many problems we now find ourselves in the world of backend architecture. Therefore I would like to share a few of our experiences and learnings in this area at upday. Conway's Law's reversion In conferences I have attended I have heard references to what could be interpreted from Mel Conway's Law: A backend architecture is a reflection of the team setup. and I totally agree with that but I also think that with time it may become the other way around: the architecture can end up shaping the team instead of the team shaping the architecture. Let me dig more into the challenges we face this time around and how we managed to resolve them: Our firsts architectural steps At upday we started with a small team of developers tasked with creating a robust solution to fulfill our client's requirements of reliability and providing good quality content to our readers. As in most startups, everything started fast and in a rush. The solution we finally came up with consisted of two monolithic components written in Java and Spring Boot. Together they form the core of our system. But they were not the only ones. We also had other smaller components written in Ruby or Java, which took care of minor requirements. When this setup worked properly and was production ready, we went live with it. When our architecture started to have flows When our company started growing, it was impossible to stick to only one big team of backend developers. We started splitting our backend team into feature teams. This was not an optimal setup at that time, given these two big components ha ## A Journey Towards a Custom Data Warehouse Solution Part 2: We Need Storage DevFeed: [A Journey Towards a Custom Data Warehouse Solution Part 2: We Need Storage]() Original publisher: [Read original article]() Author: Robert Bordo (robert@upday.com) Published: 2017-08-22T04:39:55Z Content type: article Language: en Sources: [Upday]() Topics: [data](), [data lake](), [Amazon S3](), [Amazon Redshift](), [Amazon Web Services](), [Scalability]() Tags: [aws](), [business-intelligence](), [data](), [data-lake](), [s3](), [scalability](), [storage](), [warehouse]() ### AI overview This article examines storage choices for a custom data warehouse. It describes application log data, the limitations of time-series databases for additional master and historical data, business intelligence access needs, and the use of Amazon S3 as a data lake while considering other storage options including AWS Redshift. ### Source excerpt In the beginning we created a cluster. And the cluster was without form, and void; and nulls were upon the face of the storage. As we learned in part 1 of our series, a data warehouse consists of several components. The key component is the storage. All the others group around it. But how can one draw a decision on which storage solution to adopt? What is out there anyway? Preface In a perfect world there would be only one kind of storage that fits all the needs of current DWH development and analysis. But since we are not living in that kind of place, we have several options. And the number of options increase the deeper one dives into the topic. There seem to be solutions for every use case you can think of. That might be a good starting point. What is our most common use case? What are we going to store? And how would we like to access our data in the end? Our major source is a massive amount of log data coming from our app. Everything the user does (e.g swiping through articles, selecting categories, leaving the app) is tracked, enriched with metadata (e.g. the user's location, app version, article identifier) and stored by a third-party service in big, semi-structured log files. Having only this source, a time series database like Graphite or InfluxDB could do the job. But also having slow changing master data, like user profiles, article metadata and maybe even to keep a history of data, this solution would not satisfy our current and future needs. Another thing that comes to my mind is how the data will be accessed by our final consumer (namely: Business Intelligence). Usually they use tools like Jasper Reports or Tableau for generating reports. For analyses we have to pre-aggregate the data to make queries more performant and translate raw information into a digestible format. What else is on the market? Storage good at bad at Example S3/Flat Files scalability, easy to use, data lake querying S3 Time Series DB handling time series data non time series data G ## 360|Andev - Denver 2017 DevFeed: [360|Andev - Denver 2017]() Original publisher: [Read original article]() Author: Peter Krauß (peter.krauss@upday.com) Published: 2017-08-17T05:00:00Z Content type: article Language: en Sources: [Upday]() Topics: [Android](), [debug](), [modules](), [Object-relational mapping](), [Persistence](), [Stack Overflow](), [Google]() Tags: [2017](), [android](), [animation](), [debug](), [debugger](), [developer](), [google](), [lifecycle](), [modules](), [orm](), [persistence](), [stack-overflow](), [tests]() ### AI overview This article recounts talks attended at the 360|Andev conference in Denver in 2017. It covers Android Instant Apps at Stack Overflow, Android developer options for bug reporting and debugging, and the Room persistence API in Android Architecture Components. The supplied text ends while discussing Room. ### Source excerpt As part of my Silicon Valley Fellowship from Axel-Springer I had the chance to visit the 360|Andev and I would like to present you some of the talks I attended. Day 1 "Making your App Instant" - by Kasra Rahjerdi video Kasra Rahjerdi is the lead Android Developer at Stack Overflow and told us the story about how they implemented Android Instant Apps for StackExchange in collaboration with Google. He highly recommended the codelab that Google provides. It is a tricky business to split an, app that was implemented as a monolith, into modules that can be reused. He emphasized that you should never try to refactor your code while splitting it. The complexity is simply too high and you will find yourself in a dead end! Split it, make it compile and if you feel so, make it more beautiful - but never the other way around. I enjoyed the talk from Kasra very much, because he is a real energetic speaker who understands to entertain his audience. "Android Developer Options Deep Dive" - by Andrea Falcone Andrea gave a great talk about the developer options of Android. I am working with this platform for round about 5 years now, but I did not know about all the powerful tools. Interactive Bug Report - interactive bug reports with embedded screenshots - makes the reproduction of bugs much easier. wait for debugger - Have you ever had a bug in your onCreate() method? Then this is your tool! If you turn this option on, the debugger will be attached before the app starts and you are able to debug the beginning of the lifecycle. animation scale - I guess most of us have used this tool already to turn of animations, because they are problematic for espresso tests. But the tool is much more powerful. It allows you to change the duration of animations. If you set it to Animation scale 10x the animation will be speed up by the factor 10. This tweet from Kelly Schuster shows the complete content of the talk with the help of an awesome sketchnote. Such an amazing talk by @asfalcone on the ## Dealing With Murphy's Law at upday. DevFeed: [Dealing With Murphy's Law at upday.]() Original publisher: [Read original article]() Author: Nicola Miotto (nicola@upday.com) Published: 2017-07-24T04:39:55Z Content type: article Language: en Sources: [Upday]() Topics: [resiliency](), [Android](), [App](), [Back end](), [Front end](), [samsung](), [User experience (UX)](), [Users]() Tags: [android](), [app](), [architecture](), [backend](), [behaviour](), [collaboration](), [devices](), [errors](), [frontend](), [outage](), [resiliency](), [samsung](), [service](), [settings]() ### AI overview The article discusses the architecture of upday's Android news app, focusing on resiliency and robustness around the personalized My News feature. It also explains the app's news streams and the service-level agreement severity levels used to respond to incidents. ### Source excerpt In this blog post we will provide a few insights on the architecture of the upday news app (both backend and frontend), focusing on the work that has been put on the resiliency and robustness of the components around the My News feature. upday & Samsung Before digging into the technicalities, it's worth to spend a few words on what upday is and which responsabilities we have towards our stake holders. The App upday is a fruit of a collaboration between Axel Springer and Samsung. The end result is a news application for Android, pre-installed as the default news-app on most of the Samsung devices (S7, S8, A series etc). The one purpose of the application is to deliver relevant news content to the users. The goal is achieved by means of the two news streams that the app provides: Top News: this section is an editorial curated news stream, whose titles and headlines are manually crafted by a team of editors (in each of the available countries). It's supposed to provide the user with all the relevant news of the moment, independently from taste and preferences. My News: this is the "machine curated" news stream, generated by a swarm of super intelligent cyber beings enslaved to our will. Or at least that's how business sometimes likes to sell it. The important thing is that this stream is personalized based on the user explicit feedback and settings and behaviour. SLA With Samsung Collaborations with big players come always at a cost. For the engineering team at upday this cost is the Service Level Agreement that we need to commit to. So, when a problem with the service occurs, it's categorized in a specific severity level that also defines then the actions to take. These are, in Layman's terms, the 4 severity levels of our SLA: Severity 4: An Error affecting non- upday 's Services with little or no Users impact. More concisely: no one cares. It's hit once a single third-party picture wouldn't load, for instance. Severity 3: Errors that causes degradation of the UX. Lik ## upday Blogathon 2017 DevFeed: [upday Blogathon 2017]() Original publisher: [Read original article]() Author: Robert Bordo (robert@upday.com) Published: 2017-07-20T05:00:00Z Content type: opinion Language: en Sources: [Upday]() Topics: [Hackathon]() Tags: [2017](), [blog](), [hackathon]() ### AI overview upday describes creating a Blogathon by using a Hackathon to generate posts for its tech blog. The event produced eight finished or nearly finished articles, including tutorials and personal insights from the company's daily work. ### Source excerpt What and why? Here at upday we have a lot of talented engineers doing very interesting "stuff" and using up-to-date (some would even say top-notch) technologies. Doing good is fine, but talking about it is even better. The problem is that not every engineer likes writing about his profession. Often I hear: "this wouldn't be interesting to anyone else", "there are already articles about it", "I don't have time for this" or "I simply cannot write". All this might be true. But for me, it's not enough of an excuse. Last year we started our upday tech blog to attract more talented people and of course, to get attention in the tech community. This worked out quite well. We received promising applications, a few of us got invited as speakers to international conferences and we also organised well-received meetups. Unfortunately, the driving force behind most of these activities left the company, hired by a much bigger player (another proof our efforts bear fruit). And Since then our blog has been more or less inactive. This needed to change. But how can one convince people to invest time and energy into something they don't really like or want to do? How? At upday, from time to time we organise Hackathons. During a Hackathon, people work intensely in unusual team formations (often business people also participate), test new technologies and dive into certain topics in order to produce something valuable, interesting or surprising within only a few hours of work. A few of these results have actually found their way into our product. Others were just cool. And some, of course, just sucked. Our plan now was to "abuse" one of those Hackathons to generate blog posts. The idea of a Blogathon was born. Okay, I know what you might be thinking right now. Anyway, presenting this idea provoked mixed reactions. Everything from "cool" to "it sucks big time". But no risk no fun, it's only painful at the start and attending was optional anyway. Timetable we announced the Blogathon two we ## Holacracy - Whatˋs The Fuss About? Part 1 DevFeed: [Holacracy - Whatˋs The Fuss About? Part 1]() Original publisher: [Read original article]() Author: Peter Krauß (peter.krauss@upday.com) Published: 2017-06-26T19:39:55Z Content type: opinion Language: en Sources: [Upday]() Topics: [Agile](), [Development](), [Self-organizing Team]() Tags: [agile](), [culture](), [development-process](), [efficiency](), [rules]() ### AI overview This article examines Holacracy as an alternative to traditional hierarchical management. It describes principles such as distributed decision-making, defined responsibilities, and a constitution of organizational rules, while noting that Holacracy is not a universal solution. ### Source excerpt What is the right approach to being as happy, productive and as innovative as possible? Well, I guess this question pops up in many companies and there are many books out there trying to give an answer to this question. However, I deeply believe there is not one answer "to bind them all". However some principles are helpful to create a healthy environment - this means for us updudes: you need independence to make your own decisions you need to know what you are responsible for you need to know what you can expect from others and what they are responsible/accountable for If all these conditions are met, the probability you finish your task with the highest quality and efficiency is high - and you may even have some fun in the meantime. One guide that everyone is talking about in the moment is Holacracy. So we decided to have a closer look. And what did we realize? It is not the "Silver Bullet" to solve all our problems! (What a surprise!) But Holacracy offers many tools we started using to come closer to our Garden of Eden. In the next sections I will describe some key aspects of Holacracy. Our experiences will be part of a follow-up post. The CTO is Dead - Long Live The Constitution The classical hierarchical system - one person is in charge and takes all the decisions - worked pretty well for a few hundred years. It assumes this person is able to take the best possible decisions because he or she foresees every requirement and fully understands the big picture. This might be true for assembly lines producing simple things. But it already becomes unlikely if you think about fully automated, robot-controlled assembly lines in car production. It is completely impossible in an agile and fast changing software development process. What could be the alternative? Anarchy, grass-roots democracy based decisions or maybe hiring an almighty genius who knows everything? But this would be the omniscient leader again... And how would you know he/she knows everything? The answer Ho ## A Public Speaking Experiment: Blank Slides DevFeed: [A Public Speaking Experiment: Blank Slides]() Original publisher: [Read original article]() Author: Florina Muntenescu (florina@upday.com) Published: 2017-03-08T04:00:00Z Content type: opinion Language: en Sources: [Upday]() Topics: [screen](), [context]() Tags: [communication](), [experiment](), [presentation](), [public](), [speaker](), [speaking]() ### AI overview The author describes experimenting with blank slides during a public-speaking presentation. Blank slides were used while telling personal stories, while text slides displayed quotes and key takeaways. The author reports that audience attention shifted toward the speaker and that body language, tone, and speech pace became more important, while noting drawbacks such as reduced visual guidance and greater reliance on speaker preparation. ### Source excerpt My talk at the International Women's Day event, organised by Women Techmakers gave me the chance to share my story about public speaking and also to try something new: using blank slides. Screenshot from my Google Slides The time allocated for my talk was 25min + 5min for Q&A. Since this was a non-tech talk that didn't require much visual support, I decided to combine text slides with blank slides. You can find the final deck here. My strategy was this: Use blank slides for the moments when I'm telling my story. Like this, the focus of the audience is on what I'm saying. Use text slides only for quotes and main take-aways. These would only appear in the key moments of my presentation and the audience should focus on them. The effect of the take-aways is now amplified, since these are the only parts that the audience both hears and sees. Usually in my tech talks, I tend to have one slide per idea. So I kept the same approach now, even if my slides were blank. This also gives me a sign of when I should have a small break in my speaking flow. There are a few possible downsides: The IT audience is used to talks where they always have a visual guidance, so having a black screen all of the sudden can be a surprise. I saw this effect when rehearsing my talk with a friend. But, after the initial surprise, I could see that my strategy is working: he was only looking at the slides when there was something there and the rest of the time, his attention was on what I was saying. If the audience gets distracted by their phone when they're trying to pay attention to the talk again, it will be harder to grasp the context because of the lack of visual aid. To diminish this effect, the time between text slides was only a few minutes. Talk time! How did things go? From a speaker's perspective: Given that the slides are blank, I had no more support for what's coming next in my talk. I had to rely either on the speaker's notes or on knowing the talk really well. The tendency of looking ## How Product Managers Use Soft Skills and User Feedback DevFeed: [How Product Managers Use Soft Skills and User Feedback]() Original publisher: [Read original article]() Author: Madeleine Want (madeleine@upday.com) Published: 2017-03-08T04:00:00Z Content type: opinion Language: en Sources: [Upday]() Topics: [Product Management](), [User experience (UX)](), [Development]() Tags: [leadership](), [product-management](), [product-owner](), [soft-skills](), [users](), [ux]() ### AI overview The article reflects on how product management has evolved from a broad mix of responsibilities toward stronger emphasis on communication, consensus-building, persuasion, and listening to users. It describes user feedback loops as part of product management and related to UX. ### Source excerpt "Until now, sociologists have depended on limited data sets and surveys that tell us how people say they think and behave, rather than what they actually do." - (Pentland, 2015) I grew up thinking I was clever. My grades seemed to say so, and my parents certainly did. But I wasn't sure exactly what that meant, and at some point I settled on the conclusion that being clever means you probably don't need to check your math. If only I'd verbalised that idea and been gently corrected early on, I would have saved myself years wasted assuming and spent them learning instead. For several years now I've enjoyed a trajectory of increasing leadership with very little authority. As a Product Manager I lead a product - but I don't have any formal technical qualifications. I also lead a team and a vision - but nobody reports to me. This is typical of the Product Manager role, and makes it challenging and rewarding at the same time. Strong Product Managers don't have to bring specific technical skills to the team, but they do need soft skills, - "the ability to steer and navigate, intangible qualities and behaviors" (Cheng, 2016). Everything that allows you to understand, communicate, build consensus, debate and direct is a soft skill, and Product Managers do these things every day. It makes sense: why else would your team jump on-board for your vision? You have to be able to communicate it compellingly. Why should the business allocate resources to your plan? You need to be able to argue it persuasively. How can you be confident it will succeed? You need to listen to the people who will make it succeed - the users. Product Management Then Traditional definitions of the Product Manager/Product Owner (PM/PO) role have focused on the blend of skills it requires. Being a great PO includes being a customer delighter, storyteller, delegator, developer, knowledge broker, conflict resolver and escalator (Lindstrom). Others have visualised similar definitions in diagrams like this one 1: ## Building Stronger Agile Teams Through Team Setup, Alignment, and Outcome Measurement DevFeed: [Building Stronger Agile Teams Through Team Setup, Alignment, and Outcome Measurement]() Original publisher: [Read original article]() Author: Johannes Theilmann (johannes.theilmann@upday.com) Published: 2017-03-03T04:00:00Z Content type: article Language: en Sources: [Upday]() Topics: [Agile](), [Self-organizing Team](), [meetings](), [Canvas](), [jira](), [Slack]() Tags: [agile](), [business](), [cycle-time](), [deploy](), [devops](), [meetings](), [metrics](), [product-owner]() ### AI overview An upday Product Owner describes a checklist for setting up stronger Agile teams, including defining goals, agreeing on team structure, aligning on tools and roles, prioritizing projects with CD3 and WSJF, and measuring outcomes through cycle time, deployment frequency, feature lead time, team happiness, and meeting volume. ### Source excerpt At upday we challenge ourselves to achieve technical excellence and a strong understanding of business needs. Due to external and internal circumstances we have quite a volatile team setup. At least each quarter we change either the team members, the PO or the whole structure of our teams - from horizontal to cross-functional to fluent and back again. However our goal is to have stable teams with a clear business orientation while also enabling team members to grow technically and to support each other (eg. reviews, testing, tech discussions). It is the challenge for each team member to adapt quickly to new teams, different skill sets and goals. I would like to share how we approach building stronger teams and to have a checklist for myself when a new team is set up: As a Product Owner I want to set up teams quickly and efficiently in order to get them up 'n' running fast and deliver the highest business value. Acceptance Criteria: Project goals are set for the next quarter Team set up is agreed with agile coach / scrum master / team-cut captain Team alignment canvas session defines: communication tools (Slack, Skype, email etc.) planning and progress meetings (Jira, Trello) roles, component owner, facilitator, lead team agreement Depict the process the team is improving on a story map map projects Calculate the CD3 (cost of delay divided by duration) and WSJF (weighted short jobs first) with the team. PO-team choose projects based on CD3 and/or WSJF Feedback from stakeholders is collected on a confluence page Epics for projects define clearly user/business value and metrics, objectives and key results (OKRs) to measure the success of an epic. External team members are invited to groomings to make upcoming changes transparent early on and to final reviews to identify potential follow up stories We already made several experiments with the team setup without really being able to measure the outcomes. We also realised that not all our needs are covered by the existing ## Using Lean Change Management Experiments to Guide Organizational Change DevFeed: [Using Lean Change Management Experiments to Guide Organizational Change]() Original publisher: [Read original article]() Author: Mari Kumlien (mari@upday.com) Published: 2017-01-12T04:00:00Z Content type: opinion Language: en Sources: [Upday]() Topics: [experiments](), [Agile]() Tags: [agile](), [change-management](), [experiments](), [insights](), [management]() ### AI overview The article describes how upday applies Lean Change Management to organizational improvement. It advocates collecting insights from people in the organization, designing small experiments with affected participants, and evaluating hypotheses against predefined metrics before taking the next step. ### Source excerpt A new year comes with the feeling that now is the time to change things. How many of us started the year with a promise to change and a few days later, it was already broken? Once a year, big-bang changes don't work - it never did and never will. Instead, change things when and where you feel the need to. At upday, we strive to continuously improve; how we work and what we deliver. This requires constant change. How do we foster an organization where the changes are based on what is truly going on in the organization and its surroundings? Where change is not driven by a few, but by anyone who sees the need for change? Where change is not planned upfront and executed top-down but as small steps involving people who are affected? Where we all take part in shaping the future of the organization we want to work in and where we can deliver excellence? Where Did We Start? I (Agile Coach at upday) joined a Lean Change Agent workshop together with Richard, one of our Data Scientists, and our CTO Andi. It was a two day workshop held by Mike Weber and based on the book by Jason Little: Lean Change Management. It was an active workshop including lots of participation and interactions, with great tools and ideas about how to work with change in an organization. We were introduced to a way of approaching change by collecting insights and from these, create small experiments that you evaluate and learn from before you take the next step. The idea is that instead of planning the change upfront, to create small experiments based on your current understanding and insights gathered, and review these after a fixed time period. The word experiment is important here since it emphasizes that until we have tried something out; verified our assumptions (hypotheses) based on predefined metrics, we don't know whether it's the right thing to do and if our change will be successful. Another key ingredient is to involve people affected by the change in designing the change. This is called the L