Information is fuel for change

Changes are taking place at a quicker pace than ever in the history of humankind, and expanding to more and more areas of life. The winners in this race of changes are those who were among the first to see the opportunities in the changes and make use of them. At the same time, those who stick to the traditional ways of doing things are under ever more pressure.
The power and fuel for change is information. The amount of information is increasing exponentially, as is our ability to process information. This has led to a digital revolution where the ever increasing information is refined and processed, or developed further. At the same time, information serves as capital for our information society. It equals power in many ways, and the opportunities to utilise it also spur innovations.

Everything is based on infra

The demand for efficiency and speed is high on individuals, organisations, processes and operating methods, but also on the information society infrastructure which lies behind it all. Every year, the world consumes more and more calculating power and disc capacity for storing an ever increasing amount of information. It also requires a global main memory, which can constantly and intelligently process the data we produce in the extensive cloud formed by information networks.

Innovations require that the information representing our shared capital is available to everyone anywhere, using any device, and ever quicker and easier. New innovations and visions rely heavily on the infrastructure behind the development: wireless and wired information networks, submarine cables, giant automated machine halls and their quickly scalable capacity services, as well as information pools where enormous amounts of chaotic data can be dumped for later processing and utilisation.

Architecture built based on the customers’ needs

In a world of global cloud services, competence means being among the first to implement new innovative services and using them to build an architecture which is entirely scalable according to the users’ needs and able to fix itself automatically in case of disturbances. It must also be monitored to ensure that disturbances will not even take place as they have been prepared for in advance.
we are hiring
I feel that the maintenance of information systems will require less and less human work in the future. Human work and competence have been utilised already when designing the systems. An information system in production use should tick on like a Swiss clock, while we humans can sleep peacefully for the night. The future will know no interruptions in use. Digital services are available to everyone everywhere, at any time, using any terminal device. Expert work will be focused on the construction and development of all this, understanding the needs of customers and end users, and communicating with them.
Building all this requires competence, expertise, and a deep understanding of the possibilities brought on by the newest technologies. Here at Gofore, we have been a forerunner in this for years now. We share an interest with our customers: producing information systems which function reliably and maintaining them with as little work required as possible. Using today’s technologies, this is possible. The only things required from the customers to ensure the continued development are the ability to grab on to the change, and the courage to be excited by new ideas.

Blog series “Digital Companion”

In blog series “Digital Companion” Gofore’s expert services managers explain how digitalization turns from festive speeches into actions. Change is accelerating exponentially right now. In this change, organizations require assistance with project management, leadership, service design, graphic design, programming and data analysis. This – and as a cherry on the top cloud infrastructure management – can all be provided by Gofore.

Previously on the blog series:
Timur Kärki Roll up your sleeves and head towards the unknown
Mikael Nylund: Renewability required in a time of changes
Ville Tuominen: Design enables the creation of value – for all interest groups

Kristiina Härkönen

Kristiina works at Gofore as Chief Sustainability Officer - her dream job. She has always been passionate about building a better future for both people and for the planet. She believes that technology and digitalization can be important factors helping to solve some of our time’s biggest challenges. In some respects, they are also their causes. Technology in itself is neutral, it is us, the people who must decide how to use it. We must decide the goals where we apply our limited brain capital. It is also imperative that companies understand their responsibility for creating a more sustainable future. Kristiina has worked at Gofore since 2003 and during that time has seen the company grow from five people to over six hundred. She has worked as a software developer, project manager, architecture and project management consultant, in sales and as a business director. Out of work, Kristina enjoys relaxing with nature, exploring the forests with her dog.

Linkedin profileTwitter profile

Do you know a perfect match? Sharing is caring

Project management is dead

In the software business, the (project) management role is useless. You need a high-level visionary who states the (business) vision. Let’s call her a product owner, and you need a change catalyst who makes the stuff happen. Let’s call her a scrum master. Two levels. No middle-anything. You don’t need middle-level, mid-term planning.
Culture of experimentation, MVP and overall agile principles lead to early value creation and early failure. You don’t have expensive software project failures because they fail early. You have finally learned to manage successful software projects. The only secret is to skip the middle-term planning. Just create a long-term vision and start experimenting.

Men are naïve

Men are driven by the need for certainty. This results in an inflated need for middle-term planning. “What are the 1H2018 features being delivered, their exact schedule and budget?”. Nobody can answer truthfully. You could state honestly “we will aim to fulfil the basic features of vision X during the next 3-6 months with the current team”. Or you can act like a professional project manager and come up with a detailed feature plan and exact estimates. We all know, such a plan is as trustworthy as the six-month detailed weather forecast.
There is no room for old school project management. Project management in a sense of deciding up front what, when, how and how much it will cost. The main reason for project management existing in the current software business is for sales reasons. Fixed price projects are nice to sell and easy to buy. That’s called a pig in a poke.

Reductionism is reductionist

Reductionism means that you can solve a problem by breaking it down into smaller parts, solving the small problems and then putting it all back together again. This works in a simple environment. In a complex environment, the pieces of the system are not the sum of the parts. When you have a complex problem, you need trials. Try and fail until you find a satisfying solution. Small investments can be made into safe-to-fail experiments in a balanced portfolio before we commit more resources. Cynefin explains in detail the different environment types.
we are hiring

Correlation does not imply causation

The assumption that past practice leads to a future deterministic solution is valid only within an ordered system with common context and stable, known constraints. You must understand the difference between correlation and causality. With enough data, you can find a correlation between anything. “More people drown when they eat more ice cream”. You can use data-driven decision making only in a simple environment where you know the constraints. Problems arise when work is based on wrong assumptions. Don’t ask: Has this worked before? Ask: Is this the right direction to take? This question forces you to stop and reflect on the situation.

Manage high and low

You need some management. There is no such thing as a self-organizing organization. However, you need to choose wisely what and when to manage. You must constantly evaluate the outcome of the latest short-term sprint and keep an eye on the long-term vision. Don’t spend your time planning mid-term roadmaps of how to achieve a near-term vision. At the best such roadmaps are useless and at the worst they are deceptive. No mid-term planning what so ever will help you in the future.
manage high and low

Stop and think

Today, more than ever, proper management is needed. You need to think and reflect on the situation daily. If you allow yourself to get caught up in the bureaucracy to the point where you don’t have time to stop, think and reflect, then you are damaging not just yourself but the whole organization. Being busy is not the same thing as paying attention. Requiring status PowerPoints doesn’t steer the work or create transparency. You cannot create objectivity in a complex environment, your own subjective judgement is required. Requiring simple reports is laziness. Understand the needs of management and acquire the needed information. Preferably through intelligent conversations.
As a manager, you can either spend quality 1-on-1 time with the people in the downstream, or you can wait for things go south. Stop and reflect regularly. Not just when it is a New Year.


Simplicity at the Heart of Agile:

Dave Snowden’s 12 Shibboleths of Christmas:
The Extinction of Agile Coaching:

How Google Sold Its Engineers on Management:

Fixed-Price Failure:


Agile Transformation in Action – Part 1
Agile Transformation in Action – Part 2
What’s the point scaling Agile

We are always on the lookout for skilled developers to join our award-winning team. We have exciting projects running throughout 2018 in Helsinki and Tampere – get in touch to find out more

Jari Hietaniemi

Linkedin profile

Do you know a perfect match? Sharing is caring

Before going into the cloud from your traditional datacenter or if you are just starting a new, there are few things which you should take into account. These are not showstoppers, but things that you should take into account and save yourself (possibly) from lots of headaches and refactoring in the future.

1. What kind of Cloud do you need?

Do you need to model a whole cloud infrastructure or would you be content with just some system to manage your containers off-premises? Is your system already highly entangled with Azure AD? Do you actually want to manage anything, or just a server to SSH into? These are few considerations on what kind of cloud platform you need. Cloud solutions range from simple SaaS-applications to very complex environments in AWS/Google Cloud/Azure. Between these extremes, there are possibilities like Heroku. Use the right tool for the job.

2. Location, location, location

Whilst not as critical as in the real estate business, the location also plays a major part in the cloud. If you do business mostly in a certain geographical area, it is useful to deploy your cloud near that area in order to minimize latency. Also if your organization already has a Direct Connect (or equivalent) set up in some region, it might be worth considering utilizing the (already paid for) premium link.

3. Networking

Do you have an existing infrastructure somewhere that you are planning to join with your cloud infrastructure at some point? If so, make sure that you have done your IP address range planning in such a manner that there aren’t any address range collisions. Even if you are dealing with a ‘cloud-only infrastructure’, it is worth spending a few moments planning private and public subnets and their ip-ranges. Modifying subnets at a later time is tedious at least, and sometimes completely impossible. You don’t want to scrap your whole infrastructure and build it anew.
.. which brings us to

4. Infrastructure as a code

When you have a shiny new cloud environment on your hands it is quite ok to play around and do some testing. You might even do a simple PoC that you are going to rip apart afterwards (which has happened to no PoC ever). But when doing stuff that is possibly going to production, try to start treating your Infrastructure as a Code. This allows you to more easily view the whole setup of the environment, create copies and reuse components in your future endeavours. Even if the Infrastructure as a Code might seem a lot of work, it will save countless hours in the future.

5. Can you do it yourself

You can do things in cloud quite easily, but doing them right is a completely different thing. I tried to bring some light to this issue in my earlier blog post (Finnish only, sorry). Basically, the whole idea boils down to the point that when you go cloud you are actually managing a whole data center by yourself. The difference is that it’s hosted in the cloud and won’t require physical activities but instead coding and automation. Remember all those things that are left to the datacenter people? Well, they are still there (apart from dragging servers and disks from one rack to another) but this time you should know all the bits and pieces. This is not an impossible task, but nothing to sneeze at either. Know your limits and most importantly choose which parts of the infrastructure you want to be responsible for. For the rest of the stuff, you should find a suitable partner who can handle them for you.

Tero Vepsäläinen

Do you know a perfect match? Sharing is caring

feature teams
Running a software development project is complex and scaling it is even more difficult. Typically, scaling means multiple teams, roles and processes. In the worst scenario, ‘metawork’ such as meetings, coordination, handovers and over planning kills the development efficiency totally.
A common root cause is the wrong organisational structure. Often, organisations are based on specialised teams which are focused to deliver only one thing.  A specialised team is also called a component team and is accountable, for example, for requirement analysis; front-end development; user experience; architecture design or deployment. This structure might feel rational, but the reality is different.

Problem makers

In the component-based organisation, the development process is slow, complicated and contains a lot of handovers. Typically, a new feature is created and planned by the requirement team. When the feature is written, the first development team (i.e. backend team) will implement the feature and assign it to the next development team (i.e. frontend team). When implementation is ready, the testing team will test the feature. Finally, after the feature is tested, the system team will deploy the feature to the production.
Features are rarely the same size and they often overlap. For this reason, some teams create queues and other teams become bottlenecks. This is the textbook example of the sub-optimisation that creates a lot of waste (i.e. partially ready features) and causes priority and resource fights. Multitasking is also very frequent in the component-based organisation.
A feature typically consists of multiple components which generate dependencies between component teams and make integration painful. The feature’s programming code is separated into different components and continuous integration turns into “delayed integration”. A typical pattern is to introduce a coordinator role, such as an integration manager, whose responsibility is to integrate parts together.
The feature ownership is also vague in the component-based organisation. Should the frontend team, database team or user experience team take on the responsibility of the feature? The solution is a new coordination role such as feature manager or product manager. The larger the project, the more coordinator roles are needed.
In the component-based organisation, every team knows only one part of the system. This reduces learning and makes the product vision unclear to team members. Component team’s “customers” are other component teams, not real end-users. 
The end result is a waterfall development model where completing one feature can take from months to years. Agile practises on the team level won’t help because impediments are at the organisational level. Luckily, there is a solution available and it’s called the ‘feature-based organisation’.

Cross-functional and cross-component

In the feature-based organisation, teams are cross-functional and cross-component. Cross-functional means that the team completes end-to-end features independently. Typically, the team consists of developers, testers, system specialists and designers. Having said that, the individual team member does not need to know the whole system or have all the skills.
Teams are also not organised around specific components but can work on all modules. Components still exist, but they are not used as an organisational structure.

we are hiring

Dozens of benefits

The feature-based organisational benefits are clear. According to ‘Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum’, advantages include:

  • increased value throughput–focus on delivering what the customer or market values most
  • increased learning–individual and team learning increases because of broader responsibility and because of co-location with colleagues who are specialists in a variety of areas
  • reduces the waste of underutilized people
  • simplified planning–by giving a whole feature to the team, organising and planning becomes easier
  • reduced waste of handoff–since the entire co-located feature team does all the work (analysis, design, code, test), handoff is reduced
  • less waiting; faster cycle time–waiting is reduced because handoff is eliminated and because completing a customer feature does not have to wait for multiple parties each doing part of the work serially
  • self-managing; improved cost and efficiency— The team has responsibility for end-to-end completion and for coordinating their work with others. Feature teams are less expensive–there isn’t the need for extra overhead such as extra managers and coordinators
  • better code/design quality–multiple feature teams working on shared components create pressure to keep the code clean, formatted to standards, constantly refactored, and surrounded by unit tests.
  • better motivation–research shows that if a team feels they have complete end-to-end responsibility, and the goal is customer-directed, then there is higher motivation and job satisfaction
  • simple interface and module coordination— the feature team works across all components; no need for inter-team coordination.
  • change is easier–changes in requirements or design are absorbed by one team; multi-team re-coordination and re-planning are not necessary.

Minor caution

There are a few boundaries in the feature-based organisation which must be tackled. The organisation could have special contracts with vendors, for example, infrastructure and development contracts are separated. Nevertheless, a feature-based organisation is possible, teams would just be a mixture of different vendors.
Team sizes might also be bigger in the feature-based organisation. Scrum guide recommends a team size of less than nine. Although, working with larger teams has much fewer side effects than working with component teams.
Keeping the quality consistent and how to share best practices are challenges in large projects. These risks can be reduced by creating communities or guilds with responsibilities for example, for architecture, user experience or testing. Communities or guilds are run by the team members and their communication and coordination is informal.
Sometimes the feature team lacks skills. A shared team member is a quick fix, but not the optimal solution. In the long term, the organisation must support the team e.g. with training, finding the best team-sets or hiring new people.

Culture follows the structure

The component-based organisation is based on the assumption that one person can only do one specific job. In contrast, an Agile mindset is based on learning, cooperation and the team’s self-managing abilities. Agile and the component-based organisation is a contradiction that cannot be resolved. The organisation must choose which road to take.
Graphic Design  Ville Takala 


Feature teams:
A Decade of Descaling with LeSS:
The Scrum Guide:

Further reading from the Gofore blog

Agile Transformation in Action – Part 1
Agile Transformation in Action – Part 2
What’s the point scaling Agile
We are always on the lookout for skilled developers to join our award-winning team. We have exciting projects running throughout 2018 in Helsinki and Tampere – get in touch to find out more

Juhana Huotarinen

Juhana Huotarinen is a lead consultant of software development at Gofore. Juhana’s background is in software engineering and lately, he has taken part in some of the biggest digitalisation endeavours in Finland. His blogs focus on current topics, involving agile transformation, software megatrends, and work culture. Juhana follows the ‘every business is a software business’ motto.

Do you know a perfect match? Sharing is caring

The City of Espoo has chosen Gofore Plc as one of its partners in the development of digital services for the next four years. Gofore was named the overall primary supplier in the procurement process. The total value of the development collaboration arrangement was evaluated at EUR 6 million in the call for tenders. Gofore reported (25.10.2017, in Finnish) on the co-operation: After this the contracts have been signed.

City services to be re-structured

The projects to be carried out in collaboration with the City of Espoo will encompass much more than updates to the City’s IT systems. The aim is to comprehensively examine the organisation of municipal services in new ways.
“We are planning a micro services architecture which will work in the background for new digital services,” says Riikka Vilminko-Heikkinen, the Business Manager responsible for Municipalities and Regional Government at Gofore.
“The City of Espoo is a bold reformer of digital services in the public sector. This collaboration will allow us to conduct some very interesting projects in the coming years.”

Collaboration starting on many fronts

The procurement concerned several different service areas. The subject of the call for tenders was expert services for the development of digital and online services as well as supplemental support and administration services. The resulting collaboration will encompass work conducted by Gofore’s scrum master developers as well as UX and UI developers, among others.
In addition to this, the collaboration will also give the City of Espoo access to the expertise of Gofore’s software development, integration, backlog manager and release manager experts.

The competitive tendering encompassed the following service areas:

A: Scrum master developers
B: UX/UI developers
C: Developers (back-end, microservices)
D: Integration experts
E: QA experts and data security experts
F: DevOps experts
G: Release manager experts
H: Backlog manager experts
I: Multi-skilled teams.
Gofore was chosen as the primary supplier in areas A, B, C, D, G, H and I of the arrangement. In addition to this, Gofore was chosen as one of the suppliers in area F. Framework agreements will be prepared individually for each area. The City of Espoo does not commit to predefined purchasing volumes during the contract period.
This is not the first time that Gofore has worked together with the City of Espoo, as the company has previously supplied the City with the service, which gives parents greater access to the everyday life of early childhood education.
Read more:

Further enquiries

Gofore Plc
Riikka Vilminko-Heikkinen
Municipalities and Regional Government
tel. +358 44 528 5181

Gofore Plc
Timur Kärki, CEO
tel. +358 40 828 5886

Gofore Oyj

Do you know a perfect match? Sharing is caring

Agile workshops help team building and create a deeper understanding of the Agile mindset. A well-organized workshop also gives the opportunity to step out from the normal work routine. There are numerous exercises for general Agile and teamwork topics, but fewer dealing with the project context. This blog post will introduce three simple exercises which can be used in any Agile workshop.

Definition of Done matrix

DoD (Definition of Done) is a crucial part of software quality. It defines conditions that a product must satisfy before it’s ready to launch. DoD also describes the team’s responsibilities towards the organisation. The common mistake is although the DoD has been created, it becomes outdated. The ‘Definition of Done matrix’ exercise is a straightforward method to update the project’s DoD.
The first step is to list the current DoD rules. The team writes down the rules to post-it notes, one rule to one post-it note. In the second step, the team attaches post-it notes to the Definition of Done matrix. The Definition of Done matrix’s four categories are ‘in use and important’; ‘not in use and important’; ‘in use and unnecessary’ and ‘not in use and unnecessary’. See the Definition of Done matrix below.
Definition of done Matrix    
The Team negotiates together how every post-it note should be stuck to the matrix. After post-it notes are attached, the team creates possible new DoD rules and applies them to the matrix as well. Finally, the team collects all the post-it notes from ‘in use and important’ and ‘not in use and important’ categories and updates the DoD. This exercise outcome is the team’s shared understanding of the quality and an updated version of DoD. The whole practice is linear and does not need much moderation.

A staged interview with the Business Model Canvas

An unclear project vision is often the root cause of vague User Stories or a poorly prioritised product backlog. Typically, the team hears the vision only at the kick-off meeting, where the product owner introduces it. The following exercise turns roles upside-down, so the team take on the responsibility for the product vision.
Firstly, the Product Owner goes to sit in the middle of the room and the team starts asking questions about the product. The goal is to fill out all the elements of the ‘Business Model Canvas’. The Business Model Canvas is a simple tool for visualising the current business plan. The team can also use the ‘Lean Canvas’ template, which focuses more on a product’s early stages.
When the team has successfully filled the whole canvas, they pitch the vision to the product owner. This practice helps the team to understand the project’s goal and objectives. A short introduction of the canvas might be needed in advance.
we are hiring

The Disney Method with the real use case

The Disney method is a popular technique to generate ideas and solve complicated problems. The method helps to look at ideas or problems from different perspectives and includes all these ideas in a final conclusion. The method works well also in software development.
The team select a problem before the exercise. The problem could relate to integrations, deployment, architecture or some other part of software development. In the first stage, the team shares their ideas on how to solve the problem. This stage, there is no room for restrictions or criticism. The second stage, the team thinks in a more logical planning style how to implement the ideas. The last stage, the team provides a constructive critique of the ideas in order to find the weak points and solve them. Finally, the team votes best solutions for the next round. After two or three rounds, there is only one solution left.
As a result, the team reaches a solid creative idea with an action plan to apply it. The team might struggle during the exercise and in that case, guidance is needed.

Not just a free lunch

Agile workshops are not just an opportunity to skip weekly meetings and get free snacks. Workshops bring up themes which are not visible on a daily basis. Occasionally these issues surprise or even push people out of their comfort zone. However, with careful planning, an Agile workshop boosts the team morale and productivity to the next level.
Agile Games & Exercises
Definition of Done
Business Model Canvas
Lean Canvas
The Disney Method
Further reading from the Gofore Blog
Agile Transformation in Action – Part 1
Agile Transformation in Action – Part 2
What’s the point scaling Agile

Juhana Huotarinen

Juhana Huotarinen is a lead consultant of software development at Gofore. Juhana’s background is in software engineering and lately, he has taken part in some of the biggest digitalisation endeavours in Finland. His blogs focus on current topics, involving agile transformation, software megatrends, and work culture. Juhana follows the ‘every business is a software business’ motto.

Do you know a perfect match? Sharing is caring

Find the stories in your data

Data. Information. What is it good for? Why should you care? How can your company benefit?
I believe in a future where information, knowledge, and understanding will be more accessible to the masses. In a future when we are able to dive into complex subjects and have a discussion without having a university level degree in the matter. Data visualisation can help companies and government in decision making, and allow it to be easier, more accurate, transparent, and democratic. Learning for kids as well as adults is a life-long journey, and it should be something visual, experimental, about building, experiencing, and doing, rather than passive, textual, or lonely. See, for example, how the concept of evolution can be taught through visuals and by building something on your own: Critters.
Make it visible
Do you have information that nobody in your company has seen? Do you want to communicate that information to a wider audience? Are you looking for more fact-based decision-making? Information visualisation can be a powerful tool in making something visible that nobody has seen before. When working with data you can look for stories in the data and may discover something that you never thought of before, new opportunities and possibilities to improve customers’ experience, to save, or scale up operations. Information visualisation can make us understand scale, relations, and effects much better. A grim but a good example of how little we understand about scale if shown only in numbers: The Fallen of WWII.
Make it playful – Facilitate learning, make people remember
Allowing users to explore and change information rather than look at static visualisations can be very effective. When people can explore and play with data they are creating subjective interpretations of the data and making the end results look different. Virtual reality can be a good tool in helping people to understand broader concepts, structures, and it facilitates learning on your own. People should forget that they are learning something new.
Convincing your customer and your employees
Data analytics and information visualisation can provide a wonderful set of tools for various industries, companies, and government. When data is visual it connects with our visceral senses and can provide an emotional response which in effect facilitates learning and remembering. Data visualisation is the truth delivered beautifully.
Have you been able to shift thinking and start a change by “just” visualising data? We’d love to hear more.
Do you have a complex data set that you would need to communicate to your employees or customers with ease and effect? Service design coupled with data analytics, and world-class visualisation skills can start you on a new journey.

Minna Vänskä

Minna has several years of experience working with international teams, across organizational boundaries, running UX studies, concepting, development and quality improvement projects. She is an experienced user researcher and communication specialist. At Gofore she is responsible for user research, user experience design, and service design projects. Minna loves to apply service design methods in user research and to involve organisations and people to discover the insights.

Do you know a perfect match? Sharing is caring