We all know that the way in which software products are delivered has changed a lot in the last few years. There is an increasing need to deliver things faster and to ensure that what we deliver is high-quality. If some years ago, development teams had enough time to design an architecture, to plan what they developed very well, in the last few years, the same teams do not enjoy the same amount of time. For this reason, the work methodologies laid great focus on the time required to deliver a product. We live in a globalized world, a state of affairs which can be seen in the way teams are built. Some time ago, development teams shared the same location. This is no longer valid. The majority of the development teams are distributed on different time zones and across various cultural contexts. In spite of all this, the high-standards of software product quality is as high as it will ever be.
Feb 1st marked my one year anniversary at my current company. I’ve been here several times throughout my professional life, but never before did I feel like sharing some insights about it. During my almost 10 years in business, I’ve been working for both big and small companies, local and multinational, with corporate and entrepreneurial cultures, in managerial and operational positions, yet this time something is different. Thinking about this from an inquisitive analyst perspective, it seems that at some point along the way I’ve learned some lessons, discovered new passions and confirmed some hunches about the world around me, just enough to keep the journey ahead interesting and just enough to think sharing them would bring value.
The idea that luck plays an important role in the field of innovation is well known. Just google "lucky inventions" and you will receive tons of lists with all kinds of novelties that were invented by chance – at least the authors of the lists say so. However, I have another opinion. Briefly, I believe serendipity does not exist. Okay, I know this statement is a bit radical. Everything depends on how somebody defines “serendipity”. I don’t want to start a semantics debate, I just want to show that “luck” has a much lesser role than what is commonly believed.
Imagine that you are searching for a new potential product or for a new functionality for your existing product that will be successful on the market. You are convinced that the market you’re targeting is in development, you talk to people in the industry, you research online, and you finally find the information needed to support your belief that the market is on an ascending trend and that your product will be a successful one. You decide to invest time and energy in the product and, soon enough, you are launching it backed up by a major marketing campaign. But your product fails. Nothing went as you have expected it to go: the market didn’t develop fast enough, you have fewer and fewer customers than you have initially estimated, you can’t cover the product costs, and you are working now in losses.
In the previous issue, we introduced the performance management framework OKR (Objectives and Key Results) and how it can help us build and grow performant product teams. In short, OKR is a set of measurable objectives and key results that we set quarterly. Each objective has a responsible, and at the end of each quarter we draw the line and evaluate the results: how many goals we were able to accomplish? Next, we will consider a timeline for implementation of OKR in a company, with a snapshot of annual and monthly activities.
A set of well-defined objectives is an essential prerequisite for the success of any company. Company objectives are extremely important for Product Teams because they guide strategic decisions in a manner which seeks to align itself with the solution meant to solve the issues product users are confronted with. Even if there are many models and methodologies for performance management, the OKRs (Objectives and Key Results) model is one of the best means of keeping the people involved in development focused on the target. The model provides a clear and simple view of objectives and key results, as well as a transparent and measurable way of tracking the progress made to reach those objectives.
Despite everybody’s good intentions, seemingly ignoring the effort invested and the relevance of the ideas thrown into the game, extremly lots of projects end-up creating products that nobody wants, nobody asked for and/or cannot possibly be sold. So, which might be the causes for such situations, considering that we live in an increasingly measured society, over-exposed to management processes and formal models, which practically guarantees minimum exposure to risk, from the success rate point of view?
When I began my career as a software engineer, I could not have imagined the important roles adaptability and soft skills would play in achieving successful outcomes for projects. In those early days, I believed that everything was black or white, that analytical and problem solving skills were my greatest assets, and that communication should always be direct and concise. Reality showed me a different picture. I joined Flow Traders in 2011 and I immediately found myself working with a wide variety of people, not just the machine in front of me. I had never considered that I might need to sell a solution to someone, or that I would need to explain the architecture of a big project to a non-technical person. These were new skills that I needed to learn. In this article I will share my experience of working at a company where diversity feels at home - the perfect place to develop communication skills and learn the value of our differences.
A while ago, I wrote an article addressing some important aspects in the world of client communication, or at least that was what I thought I was doing. I talked about how important it is to find a common ground when talking to somebody, especially if the people involved have different backgrounds. I also talked about the importance of emphasizing the value of what we are communicating, to point out what our ideas are bringing to the game. Since then, I have continued to improve my communication skills and I have discovered how important it is to pass these messages in a very efficient manner, especially when there are time constraints in the game. This is almost always the case when discussing with a client. There have been a couple of game changers for me lately, which I think have really helped me improve my efficiency when communicating. In this article I want to pass along these additional teachings.
Software development exists, in the end, to solve Business problems and bring as much Business value as possible. If our role is the one of “Business Analyst” in a software company, we feel not meeting our goals if we are not able to identify the real Business needs and if we are not able to prove the Business value delivered by the applications or features to be developed. Is it enough to have a number set as “Business value” for each user story? Should we also be aware of the real Business value behind that number? Would this help us and our teams provide the best possible solution and do things right from the very beginning?