Emil Vikström

Emil Vikström

Meet Emil

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus.

Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Donec pede justo, fringilla vel, aliquet nec, vulputate eget, arcu. In enim justo, rhoncus ut, imperdiet a, venenatis vitae, justo.

Nullam dictum felis eu pede mollis pretium. Integer tincidunt. Cras dapibus. Vivamus elementum semper nisi. Aenean vulputate eleifend tellus. Aenean leo ligula, porttitor eu, consequat vitae, eleifend ac, enim. Aliquam lorem ante, dapibus in, viverra quis, feugiat a, tellus.


What I Do

Phasellus viverra nulla ut metus varius laoreet. Quisque rutrum. Aenean imperdiet. Etiam ultricies nisi vel augue. Curabitur ullamcorper ultricies nisi. Nam eget dui. Etiam rhoncus.

Maecenas tempus, tellus eget condimentum rhoncus, sem quam semper libero, sit amet adipiscing sem neque sed ipsum. Nam quam nunc, blandit vel, luctus pulvinar, hendrerit id, lorem. Maecenas nec odio et ante tincidunt tempus. Donec vitae sapien ut libero venenatis faucibus. Nullam quis ante. Etiam sit amet orci eget eros faucibus tincidunt. Duis leo. Sed fringilla mauris sit amet nibh. Donec sodales sagittis magna. Sed consequat, leo eget bibendum sodales, augue velit cursus nunc,

  • Team & Individual Coaching
  • International Projects
  • Large Scale Delivery
  • DevOps
  • Agile Coach
  • Trainer
  • Project Manager
  • Agile
  • Scrum
  • Lean
  • Kanban
  • SAFe
Selected Engagements


Viasat TV to Go


Programme Manager: Emerging Products

Delivery leader across a portfolio of products, including the successful launch of TV To Go across three countries, reporting to Head-Of and C-level executives.

Candy Crush Soda

King Logo

Interim Scrum Master: Candy Crush Soda

Coaching two of the game’s four teams as it moved from a highly confidential project, through its beta launch.



Delivery Leader: IBM Custom Development & Support Services

Leading the delivery and commercial management of multiple contracts for a 50 person multilevel team in the UK and India.

RBS: The Royal Bank of Scotland

RBS Retail Bank

Programme Scrum Master: Electronic Customer Review (eCR)

Contract Agile Coaching role for a large, distributed programme team delivering a portal application, in the first significant Agile delivery in RBS Retail Bank.

Coaching Customers

IBM Logo

Lean Coach: UK & Nordics Global Services Accounts

Coach to large outsourced delivery organisations delivering Application Development and Support Services into major customers.

Recent Writing

“Big 5” dangers for your software company

The definition of “big 5” is traditionally the 5 most dangerous african animals to hunt on foot. For software development I have defined it as the 5 greatest dangers of running your software company. Technical Debt A lot of legacy code and not aggressively reducing technical debt is a sure way to keep your IT organization on a low level of productivity and high level of frustration. With technical debt I mean for example spaghetti code and poor architecture, lack of or bad APIs, lack of tests, no modularization and no continuous refactoring. If you are building a new system letting the above happen is a good way of making sure you will have potentially fatal problems later. An example is not refactoring the quick prototype you hacked together for your first demo or letting your test and deploy infrastructure become a mess. Weak technical leadership Relying on cowboy developers, whole development teams or disconnected managers to lead in important technology and architectural decisions will likely result in fragmented architecture and endless discussions. Worst case examples can be taken from public examples in Sweden where bad technical decisions wasted tens of million euros of tax payers money. Even if  bad decisions does not topple your business you will likely end up with sub-standard development tools and practices and lack of Continuous Delivery, DevOps and Lean Startup thinking. This will in turn reduce your company agility and the best tech people find a cooler place to work. Waterfall project model Although Agile development has become a de facto standard for software development many companies still employ traditional project management and... read more

Guest blog: Stepping Stones into the Future through Leadership Agility at Ericsson

This is a guest post by my dear friend Anna Sandström; Agile Coach and Organizational developer at the telecom giant Ericsson. Anna is an excellent coach who help people with deep changes that translates into everyday high-performance, both at Ericsson and in her own company. The original post can be found here. /Emil By Anna Sandström Within Ericsson we have gained lots of experience from Agile Way of working! But what about our leadership? Have we become increasingly adoptable at responding to the degree of change and complexity that pervades today’s workplace? Trigger for my curiosity and inspiration My curiosity started in my work in leadership teams, and reading about adult learning and growing into new stages of awareness and leading. I had the opportunity to meet with a very inspirational leader in a different branch than where I’m working, and through understanding more about the work she has been doing from a co-creator way of leading, I got inspired to dare to start using some of my skills in the leadership teams I am active coaching in. I created WS material for the Leadership Agility model I created together with a colleague (Per) from a different part of Ericsson, four blocks of material around the Leadership Agility model, using some techniques from Training from the Back of the Room thinking. Each block in itself is self contained, and the theory is broken up with short presentations in the big group, self-reflections and “pair share” with a colleague and sharing with the rest of the group. What we tried to achieve was… Communicating an understanding of the Leadership agility concept. Understanding of the... read more

Continuous Delivery anti-pattern: We are unaware of the waste in our process

A big part of the waste we have in our development processes is there simply because we are not aware of it and the thinking that creates it. We lack transparency and a thinking of the whole flow from requirements to production. Some common causes of this are: We do not measure lead-times, queue-sizes and bottlenecks We don’t have tools and methods which supports that we as people gather and create awareness of the whole We organize, use steering models and architecture and employ a management philosophy which optimizes on so called resource efficiency. Unfortunately focusing on resource efficiency often leads to that we do not focus on delivering value to the customers. We tend to forget that we also need to optimize on lead-time and so called flow efficiency. We also tend to not see the waste we create by optimizing on resource usage. Depending on how you steer the organization and what basic assumptions you use the balance between resource efficiency and flow efficiency can end up in any of the four quadrants described in the following picture. Note: this picture is based on the model from the popular book This is Lean. Unfortunately we have seen that many organizations that have been using a traditional development methodology (resource efficiency) have over time slipped further and further down into Dead End. For the organization this usually means near deadlock in information flows, zero productivity and people burnout. On the other hand, successful organizations we are working with have managed to create a synergy between delivering quickly to the customer and using the resources... read more

Continuous Delivery Anti-Pattern: Long lead-times from requirements to production

Ok you may ask “how is this an anti-pattern? it sounds more like a symptom”. I would argue that it is both a symptom and a cause and that it really doesn’t matter. It is a symptom because we get long lead-times from of the practices and processes we use. It is a cause because today we have the knowledge, technology and experience to greatly reduce the lead-times. In other words the length of lead-time is a matter of choice. Traditional development processes, steering-models and organization is by definition working against short lead-times. Much of the delay is created in the handovers between requirements, development, test and production. Some consequences we almost always see in traditional organizations which are related to long lead-times are: Difficulty in planning Highly risky deliveries Poor quality Very large cost to make sure quality is good Cleanup months after delivery Unhappy customers High employee costs Employee burnout Naturally we may have more or less “debt” in the organization which are preventing us from instantly reducing the lead-times. There are on the other hand many examples of organizations which have reduced lead-time greatly (and also reduced the mentioned consequences) by just working in another way. So what is a good first step? Having the management team look into DevOps and Continuous Delivery is great. You don’t need to understand every technical detail about it but getting a basic understanding and then focus the whole organization on reducing lead-times can be very effective. As I mentioned short lead-times is a choice, for some perhaps a long term goal. We have learnt that in traditional organizations this choice must be made... read more

Continuous Delivery anti-pattern: Deliver after development is done

In traditional development we often make an assumption that it is impossible or to costly too test the software early and often. Many companies has proven that the opposite is true; “if it hurts, do it more often” is the key to success. Unfortunately traditional project-steering models do a lot to keep outdated assumptions in place. The consequences of delivering and deploying late are for example: We save costly tests and setups of test and delivery environments until the end of development The time from check-in of the code until feedback reaches the developers is very long which means that they have a hard time remembering what they did You see exponentially increasing costs and lead-times and deployments are late because of “Big-bang” behavior The time at integration, final test and deployment is very stressful which causes coworkers to quit or burn out It’s quite easy to put in KPIs to measure the hard and soft costs this creates, for example: What is the cost of the different test setups and when do we use them? How long is the feedback loop to developers? How long is the “integration” time? What is the cost of the overtime it creates? How much manual re-work is done during test and deployment? What is the ROI of that? What is the cost of overtime related to deployments that didn’t go smoothly? How big is the queue of work waiting to be deployed? What is the value of our coworkers? How do they feel? What is the cost if they quit/burn out? What would we gain if we attracted... read more