Revenge of the Chatbots


Chatbots have gained an unusually large focus in recent years. A chatbot is a piece of software that performs automated tasks, such as setting an alarm, scheduling a meeting or ordering a pizza. Here is one story of chatbots’ practical use.

Background

Gofore is a Finnish software and consultancy company. Because of the company’s rapid growth, its manual and repetitive tasks required more and more attention. Hiring more managers was never an option.
The original idea was to design a fancy dashboard and graph tool. We started the internal project, and within three months the tool was ready. As usual, our first hunch was wrong. The management used a few graphs, but the tool never gained the popularity we had hoped for.
If the mountain won’t come to Muhammad, then Muhammad must go to the mountain. Therefore, we looked to one common tool that people use on daily basis – Slack *. Soon, we created the first chatbot on Slack.

Simple Deployment

Adding a chatbot to Slack was easy. The dashboard and graph tool already integrates to our ERP and a few other background systems via API or Webhooks. From there, the data goes to the time series database.
The chatbot army uses the same architecture as described above. Some bots are schedule-based and some are event-driven. Check out the Slack-bot-users tutorial for the further information.

Seven-Nation Bots

Collecting and reporting business information is a time-consuming and error-sensitive job. Our bots parse the information automatically on the easy form. For instance, the bots list the utilization rates, sales opportunities, and crucial marketing data. See the most readable blogpost-chatbot in action below:

As humans, we tend to forget things. The chatbots provide advice if the user has forgotten to record working hours, worked too much, or has not sent a bill to the customer. See our chatbot quoting Napoleon below:

The ‘hot member’ of our bots’ army is the train-ticket-chatbot. Originally created in our Hackathon event by Harri Hämäläinen, this chatbot helps people to buy season train tickets more quickly and efficiently. See how the chatbot survives the customer service duty:

Dad, Could I Have my Own Chatbot?

Can you use chatbots in your business? Definitely! Firstly, analyse what annoying tasks your workers or customers do regularly. Secondly, decide how to use chatbots. Chatbots’ natural habitats are in messaging applications such as Slack, Yammer, or other messaging tools. Lastly, find few skilled developers and explain the use case. Remember to give the developers enough access rights, since chatbots most likely integrate into your existing systems.
The ultimate goal is to let chatbots take care of all manual and repetitive work in our company. We are not there yet, but the target is achievable. Chatbots allow people focus on what they do best – solving complex problems.
Thanks to these awesome people who brought our bots to life:

  • Joonas Itkonen
  • Mikael Harju
  • Harri Hämäläinen
  • Juuso Meriläinen
  • Antti Tohmo
  • Joona Romppanen
  • Jesper Skand
  • Timo Nikkilä
  • Marko Wallin
  • Peter Kronström
Graphic design

Ville Takala

Details:

Slack is one of the biggest cloud-based collaboration tool. Slack supports channels, direct messages, file sharing, and calls. Slack endless integration possibilities makes it the perfect tool for chatbots.

Read more

https://www.recode.net/2016/4/11/11586022/what-are-bots
https://www.cnet.com/how-to/what-is-a-bot/
http://www.techworld.com/picture-gallery/personal-tech/9-best-uses-of-chatbots-in-business-in-uk-3641500/

Avatar

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

Following the acquisition of Leadin that came into effect in May, new appointments have been made to the management of Gofore. The rapidly-growing companies are integrating and from now on will write their success story together.
Topi Koskinen has been appointed as Gofore’s Chief Operating Officer (COO), and Ville Tuominen as the Director of International Business. Both appointments are effective 9.6.2017. At the same time, Koskinen and Tuominen are joining Gofore’s management team.
Topi Koskinen is responsible at Gofore for production management and for continuous development of agile governance of the company. He will also continue as the Managing Director of Leadin. Ville Tuominen is responsible for Gofore’s international business operations. In addition, he will lead sales of Gofore’s Design services. Alongside his new duties, Tuominen will continue at Leadin in the role of Commercial Manager.
“Traditionally, people have grown into managerial roles at Gofore – previously, no-one has been recruited from outside for the position of a director or manager. Through our first company acquisition, we got not only skilled personnel, but also management,” says the CEO of Gofore, Timur Kärki.
The area of responsibility of Gofore management team member Mikael Nylund has been expanded. Mikael will be leading the mergers & acquisitions process at Gofore, in addition to his current role as a Head of the Management Consulting business. The objective for the M&A process is to support the growth strategy based on organic growth of the company with acquisition transactions in Finland and in selected other market areas. The aim is to find targets with which Gofore can strengthen its ability to comprehensively help its clients in digital transformation.
The acquisition of Leadin was confirmed on 31.5.2017, when Gofore acquired all the shares of Leadin. The growing companies will seek to recruit a total of 170 workers during this year, increasing the number of personnel at the offices of Finland, Great Britain and Germany. Gofore was selected as the best workplace in Finland and the 2nd best workplace in Europe in the Great Place to Work 2017 study. Leadin will continue to operate under its own name for now, and business will go on without interruption.
Further information:
Gofore, CEO Timur Kärki, +358 40 828 5886, timur.karki@gofore.com
Learn more about the acquisition of Leadin

Gofore Oyj

Gofore Oyj

Do you know a perfect match? Sharing is caring

SAFe vs LeSS Shootout

First of all. Ahoy, all you “Why agile” and “I don’t need scaling, I already have Scrum” people. Please start here.
I’ve followed the growing interest towards methods of scaling agile for the last decade. Personally I faced the idea of scaling Agile, whilst working as a subcontractor for Nokia. Back then two very different kind of frameworks were born. Ari and Ran explains the history of these scaling frameworks, so I won’t go there. I’ll just want to find out, which approach is better. The fastest and most entertaining way is to take our two of the most experienced scaling agile gun men Stefan and Juhana and start shooting. Whilst the gun men are warming up, let’s make a quick generic comparison of the frameworks.

Juhana, Jari and Stefan warming up

We’ve blogged earlier about SAFe (in Finnish) and LeSS in rather positive tone – now it’s time to get some friction between them. Like in all the unforgettable shootouts, the tension must be built gradually from introduction and rising action towards climax.

Guide to drama

Name

I must say, if I created a scaling framework, I wouldn’t name it either “Safe” or “Less”. The “Less HUGE” makes things even more paradoxal.

There is a clear winner on the field of naming the Scaling Agile framework. The Recipes for Agile Governance in the Enterprise aka “RAGE” wins the fight between names.

Portal

Never, ever design usability restricting cr*p on any media in the name of copyrights. It is a lose-lose deal.
Both systems provide similar web interface: A big picture on the front page, where you can click into details.
  • The hippie drawing style of LeSS will make all the wave riding, new age developers feel warm and fuzzy.
  • The engineering style, mind-blowing-in-details drawings of SAFe will make all the managers feel super important. However, the copy-paste restriction of SAFe portal sucks, while it also disables for example text search of browser.

LeSS wins the fight between the portals.

Comparison of web portals. LeSS on left and SAFe on right

Book

We live in a colorful world. Use them.
Both systems are provided as books
  • Both books are the same diameter and around 330 pages.
  • Both books come from Addison-Wesley.
  • SAFe book has more pictures and colors, otherwise they are rather similar.

SAFe wins the fight between books with flying colors.

Comparison of books. SAFe on left and LeSS on right

Introduction of The Gun Men

Question #1: Tell us a little bit about yourself and when you became a fan of SaFE / LeSS?

Stefan:
I’m a business manager and consultant at Gofore. Currently I’m focusing on our customers in health technology, healthcare, social care and wellbeing businesses. Throughout my professional career I’ve been interested in all development methods – from SW development to business & customer development. I was first exposed to SAFe whilst working at Nokia a decade ago, but the real revelation of SAFe to me happened at GE Healthcare in 2014. We had 16 teams, nearly 200 professionals scattered across globe with a goal to create multiple new products together. We applied SAFe to align the goals, sync on delivery and to optimize flows.
Juhana:
I’m a lead consultant of software development at Gofore. I have a background in software engineering and have been in the IT field for more than decade. I’ve taken part for some of the biggest public sector digitalization endeavours in Finland. For some reason, I’ve always been the guy who’s removing obstacles and trying to improve everything. So, the Scrum Master’s duty was a natural choice for me. Lately, I’ve focussed on transforming entire organisations to Agile mode. In the latest project, I was consulting a large software program that required Agile transformation. I needed a powerful and straightforward solution for the transformation. The LeSS approach caught my attention very quickly; the LeSS principles and rules were understandable and simple. The challenges confronted in the target organization were tackled intelligently with the LeSS method. This  would not have been possible if using a one-size-fits-all format such as the SaFE.
Conclusion:
SAFe interest people in management type of roles and LeSS fascinates adventurous problem solvers.

Rising Action

Question #2: Imagine a 40 person project working in waterfall model. How would you deploy SAFe/LeSS?

Educate everyone into Agile mindset

Stefan:
SAFe provides the best practices from industry also for the deployment of SAFe. The things to conside in deployment are:

  • Train everyone: a) train the leaders, b) train the internal change agents, and c) train project personnel.
  • Split project to 2-pizzas-serves-them teams. Select team level development methodology, e.g. Scrum. Make sure that teams have the right set of competences to work as feature teams.
  • Define the way of working for the organization. For a 40 person program the two lowest level of SAFe framework serve the purpose: 1) Team level and 2) Program level.
  • Then it’s about start your Agile Release Train to develop in common cadence according to commonly agreed increment plan. The increment planning and demo sessions are where the magic happens – the whole program planning, resolving and agreeing together in the same room and at the same time.

Juhana:
The LeSS creator Craig Larman’s advice for large, multi-site, and/or offshore programs is just ‘don’t do that’. Instead pick the ten best developers. If you must scale, here are the adaption principles:

  • You should educate everybody. The easiest way is to sign people to the Scrum and LeSS trainings. The formal coaching is followed up by a team, organisational and technical coaching.
  • Define the product as broadly as possible. A broader definition tends to be more customer centric and creates simpler organisations.
  • Define the ‘DoD (Definition of Done)’. A better and stronger DoD eliminates groups, roles, and positions.
  • Have appropriately-structured teams. One team member belongs to only one team, and the teams are stable, long-lived, cross-functional, and co-located. Only the Product Owner provides work for the teams. Keep managers away from the teams.

Conclusion:
Both approaches aim to educate and engage everyone.

Climax

Question #3: Our current organisation has 3 team leaders, 1 architect, 1 project manager, 1 product manager and 1 UX/AD specialist. What would these persons do in SAFe/LeSS?

Stefan:
When using Scrum on team level then there are roles of the Scrum Master, Product Owner and SW developers. On program level you’ll find Product Management and Business Owners. Note, that the role of leaders in SAFe is different from traditional management – the roles are Lean-Agile leadership type of roles.

  • The old team leaders from the legacy organization could become developers, Scrum Masters or Product Owners depending on their capabilities and desires.
  • Architect and UX/AD specialist could continue working across the teams in program level roles.
  • Project manager could be promoted to the role of Release Train Engineer.
  • Product Manager could continue with same title, but in a modified role at product management.

Juhana: 
Specialised roles are forbidden in LeSS.

  • The team leaders can become Scrum Masters. They should follow the servant-leadership-mindset such as putting people first, coaching, removing obstacles, and creating the community. One Scrum Master can serve one to three teams.
  • The Architect and UX Designer will each join a team. In addition, the architect can lead or be part of the architect community, and the UX Designer can lead or be part of the user experience community. The communities ensure the cross-cutting quality and are run by the team members.
  • the product Manager can take the Product Owner’s role and responsibilities.
  • The project Manager could focus on increasing the capability of the organisation’s value delivery with using techniques such as ‘Go and See’ and ‘See the Whole’. The Product Manager role is also temporarily needed if there is a weak Definition of Done.

Conclusion:
Tune-down way of SAFe makes it easy to sell towards legacy management.  SAFe has built-in program management process and roles. Build-up way of LeSS asks “How to simplify the organization, and be agile?”.

Question #4: Okay, now the program is working according to SAFe/LeSS framework. How does the model scale when you add two more teams?

Stefan:
SAFe’s program level guidelines make this rather easy. Assuming the teams are feature teams then it’s rather easy to add new teams – just invite them to the common Release Train Planning event and share the prioritized increment backlog across the teams. SAFe can scale up to multiple release trains and multiple value streams, but at that extreme we would be then talking about thousands of developers, and that’s a bit scary anyway.
Juhana: 
LeSS scales easily – you just add two more teams to the structure. Avoid creating component-based teams such as front-end, integration, or operation teams. If the number of teams exceeds eight, use the LeSS Huge framework. It’s based on the same principles and rules, but adds a few extra practices.
Conclusion:
After reaching Lean Agile organization scaling is easy.

Resolution

Both models require the Enterprise to change. Agile is about mind-set, not about roles or processes.

It seems that the path for agile scaling is rather similar, no matter what framework you are using. After the first hour of shooting, there is yet no clear winner.
Thanks for reading! Please, throw in any additional questions!
We will tackle those in the Shootout Sequel, where we will finally find out, which one of these two frameworks is the best.

Jari Hietaniemi

Jari Hietaniemi

Jari Hietaniemi is an enthusiastic digitalization consultant. He specialises in complex and vast software projects. His philosophy is based on thinking that a consultant must know technology, architecture, project management, quality assurance, human resources, coaching and sales. His versatile experience and constant quest for improvement help to finish projects successfully and to bring new drive into client organizations.

Linkedin profile

Do you know a perfect match? Sharing is caring

The Dark Side of Microservices

Background

A microservices architecture is a gold mine for software business. Modularity, component independency and reuse, scalability, and the freedom to choose a technology are good arguments for any architect planning meeting. Unfortunately, it is only the half-truth.

There is no free lunch

Microservices encapsulate business logic into small and loosely-coupled services. This has been argued as a justification for microservices. Though individual service complexity is reduced, orchestrating a large and distributed system makes things more complicated. A microservices architecture simply shifts complexity from the code design and implementation to system operations.
Designing and building a microservices architecture is a massive investment. A build pipeline, centralized logging system, and orchestration engine are needed from the first version. In addition to this, a microservices architecture makes daily software development such as developing, testing, and deploying more complicated.

Reuse is overrated

The reuse of components is one of the core principles of a microservices architecture. Reuse has been a strong sales argument for numerous frameworks, platforms, and architecture models. Unfortunately, the system that is based on reused components doesn’t come without a cost.
Fred Brooks made the observation that it took about nine times the effort to design and maintain a reused component compared to a single use component. This ratio may be higher than today’s standards, but is nevertheless a substantial difference.
Additionally, organisations often overestimate reuse needs. Nowadays, the products change rapidly and their lifetimes are short. One-size-fits-all solutions are wasteful in many cases.

Is your organisation ready?

Big companies, such as Netflix and Amazon, love to talk about microservices. These companies are able to make an enormous investment, both economically and culturally. If your organisation wants to adopt microservices, it must be ready for these changes.
Microservices principles put pressure on organisations to be more adaptive and flexible. Teams should have the authority to design, plan, and deploy their work. This DevOps culture lifts up the organisation’s maturity demands.
Conway’s Law states that the structure of your software is likely to reflect the structure of your software development organisation. The organisation must create integrated cross-functional teams where business, marketing, and developing teams work closely together to get all the potential from microservices. These organisation changes might be slow and painful.
Microservices provide technological freedom. This could lead to a situation where one system contains countless software languages, paradigms, and frameworks. The outcome is dramatically higher maintenance costs and teams’ standard of excellence.

Time to Rollback?

Should we turn back time and start building a ‘monolithic architecture’ again though ‘serverless architecture’ is just around the corner? Maybe not, although it is always a good idea to see both sides of the moon (even when discussing your favourite technology).
 
Graphic design
Ville Takala
 
Read more:
https://martinfowler.com/articles/microservice-trade-offs.html
https://www.oreilly.com/ideas/microservices-shift-complexity-to-where-it-belongs
https://blog.codecentric.de/en/2015/10/the-broken-promise-of-re-use/
https://techbeacon.com/want-develop-great-microservices-reorganize-your-team
 

Avatar

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

If you are unfamiliar with Agile or still don’t see benefits of Scaling Agile, this is the blog to drop by. This blog is a hidden sub-section of the SAFe vs LeSS shootout.

Why Agile

Moving an enterprise (from waterfall) to agile is a huge task. The organization and culture must change. However, it is obvious that the waterfall-type process doesn’t work and therefore we must face the change. In agile way, we run fast delivery of the highest priority requirements, followed by fast feedback and learning. Some cynics ask why waterfall wouldn’t work. Well, here’s why:
  1. Don’t assume you can develop a new and innovative system based on fixed requirements and schedule. It is impossible to predict a schedule for large software system deliver. If you do waterfall development with tight schedule, the team haven’t started to code yet, when you hit the deadline. In agile development, the system is up and running from the start. You learn fast and fail fast. Reference: http://www.infoq.com/resource/articles/scaling-software-agility/en/resources/ch02.pdf
  2. Don’t assume you or your customer can understand requirements up front. You can’t define requirements before-hand. Intangible system like software will present its full existence only through functionality. And when you see and feel the functionality, it usually needs tuning. Light bulb of Edison, hoover of Dyson, iPhone of Jobs, Amazon book store, they all are results of endless rounds around Deming cycle. https://hbr.org/2008/05/innovation-and-iteration-frien
  3. Don’t assume you can manage the change. Business requirements change during defining the requirements. Throughout the requirement definition process one starts to understand better the system and its optimal functionality. Requirements do change during the system implementation. Change will be constant and can be managed only with small increments. https://hbr.org/2007/11/a-leaders-framework-for-decision-making
  4. Don’t assume the system integration is ever easy. Putting together independent code modules will bring the overall system architecture to alive. Only then can you validate the functional and non-functional features of the system. Software integration is harder and slower the more you postpone it. We have DevOps trending for a reason. All the non-integrated code is waste; we need to get rid of. It is inefficient, expensive and risky to store large amounts of non-integrated code. https://gofore.com/en/the-sweet-spot-of-devops/

According the 11th State of Agile report, companies benefit from agile by being able to manage changing requirements, achieving higher team productivity, gaining improved project visibility, better time-to-market and higher team morale.

Why Scaling (Agile)

Scaling answers on a question how to build large and complex software system faster, smarter and more transparent ways than waterfall could ever provide. In short scaling is iterative development in a large organization. Agile Scaling is about learning to use interative practices on Enterprise level.
  1. Don’t believe your need to do large projects or multisite and offshore development.
  2. Focus on creating great products with a small number people, team of extroardinary multi-skilled and co-located developers.
  3. Break the rules 1 and 2. Sometimes you need to create so big/complex/business critical deliverable that a single team cannot achieve the goal in the given time frame. Stuff that is listed for example in SAFe and LeSS case studies.

In Agile Scaling, the individual teams still work in Scrum, Kanban or whatever mode. The “scaling” part answers on the question how coordination between dozens of such teams is being handled. You need autonomy and alignment. Autonomy means that teams are Agile. Alignment means that all the teams work towards a common goal. Nobody suboptimises in the name of a team. Henrik Kniberg puts it beautifully “Like a Jazz band, each musician is autonomous and plays own instrument, but still listen to each other and focus on whole song together”.

Accoring the 11th State of Agile report the greatest challenges with Agile remain on old organizations adopting agile culture. According the report the most common (63%) challenge is “company philosophy or culture at odds with core agile values”.

Two very different approaches for scaling Agile: SAFe and LeSS

There exist numerous scaling frameworks like DAD, RAGE, Enterprise Scrum and more, which are being comprehensively compared in ASK Matrix. However, in Finland we have the most experience on SAFe and LesSS. They represent different ends of the Agile scaling. LeSS represents build-up and SAFe tune-down approach.

Tune down means that only parts of the framework are deployed, build up means that the framework is being created case by case

SAFe

Accoring the 11th State of Agile report the most common scaling framework is SAFe. SAFe provides power of agile while leveraging systems thinking and Lean product development. SAFe brings a new better program process, explained in familiar terms. SAFe is easily understood by the traditional management. SAFe works on the same domain as other project and program management systems, adding Lean/Agile methods. SAFe revolves heavily around program execution.
SAFe whitepaper states that benefits from documented case studies include:
  • 20-50% increase in productivity
  • 30-75% faster time to market
  • 50%+ defect reduction
  • Happier, more motivated employees
11th State of Agile Report shows where Agile Scaling is heading

LeSS

LeSS reinvents management by scaling Agile and Scrum. LeSS shows how to cope with complexity by creating simplicity. LeSS is deliberately incomplete and leaves rooms for situational learning. LeSS doesn’t offer apparently safe and disciplined approaches to offer a comforting illusion of predictable control. LeSS concentrates on the minimal essense required when scaling, like continuous attention to technical excellence and continuous experimentation. LeSS is scaling Scrum without adding layers or processes. On the contrary, it simplifies the organization radically – more with less. The teams take care of the technical coordination. The product owner works with the market and with the teams. The managers become coaches or product owners. LeSS is a framework that must be adapted to meet the particular needs. LeSS does not provide fixed answers, but provides a starting point for understanding the deeper principles.
LeSS case studies provide examples of LeSS adoption and list also some benefits like:
  • Nokia Networks: The previous product where we used a sequential life cycle model took twice as long to develop, and the sequential life cycle and single-function teams and component teams would not have allowed us to make the major change in direction that we did. LeSS gave us that organizational agility.
  • John Deere: Teams were able to give a useable realistic forecast. Within half a year, the teams were able to plan and forecast delivery dates reliably upfront. Massive quality problems were fixed and teams became focussed.

The Beginning

Now, when you’ve been converted into an Agile believer, you are ready to learn whether SAFe or LeSS is the best way for Scaling Agile. Please proceed to SAFe vs LeSS Shootout.

Jari Hietaniemi

Jari Hietaniemi

Jari Hietaniemi is an enthusiastic digitalization consultant. He specialises in complex and vast software projects. His philosophy is based on thinking that a consultant must know technology, architecture, project management, quality assurance, human resources, coaching and sales. His versatile experience and constant quest for improvement help to finish projects successfully and to bring new drive into client organizations.

Linkedin profile

Do you know a perfect match? Sharing is caring

SAFe vs LeSS Shootout

First of all. Ahoy, all you “Why agile” and “I don’t need scaling, I already have Scrum” people. Please start here.
I’ve followed the growing interest towards methods of scaling agile for the last decade. Personally I faced the idea of scaling Agile, whilst working as a subcontractor for Nokia. Back then two very different kind of frameworks were born. Ari and Ran explains the history of these scaling frameworks, so I won’t go there. I’ll just want to find out, which approach is better. The fastest and most entertaining way is to take our two of the most experienced scaling agile gun men Stefan and Juhana and start shooting. Whilst the gun men are warming up, let’s make a quick generic comparison of the frameworks.

Juhana, Jari and Stefan warming up

We’ve blogged earlier about SAFe (in Finnish) and LeSS in rather positive tone – now it’s time to get some friction between them. Like in all the unforgettable shootouts, the tension must be built gradually from introduction and rising action towards climax.
Guide to drama

Name

I must say, if I created a scaling framework, I wouldn’t name it either “Safe” or “Less”. The “Less HUGE” makes things even more paradoxal.

There is a clear winner on the field of naming the Scaling Agile framework. The Recipes for Agile Governance in the Enterprise aka “RAGE” wins the fight between names.

Portal

Never, ever design usability restricting cr*p on any media in the name of copyrights. It is a lose-lose deal.
Both systems provide similar web interface: A big picture on the front page, where you can click into details.
  • The hippie drawing style of LeSS will make all the wave riding, new age developers feel warm and fuzzy.
  • The engineering style, mind-blowing-in-details drawings of SAFe will make all the managers feel super important. However, the copy-paste restriction of SAFe portal sucks, while it also disables for example text search of browser.

LeSS wins the fight between the portals.

Comparison of web portals. LeSS on left and SAFe on right

Book

We live in a colorful world. Use them.
Both systems are provided as books
  • Both books are the same diameter and around 330 pages.
  • Both books come from Addison-Wesley.
  • SAFe book has more pictures and colors, otherwise they are rather similar.

SAFe wins the fight between books with flying colors.

Comparison of books. SAFe on left and LeSS on right

Introduction of The Gun Men

Question #1: Tell us a little bit about yourself and when you became a fan of SaFE / LeSS?

Stefan:
I’m a business manager and consultant at Gofore. Currently I’m focusing on our customers in health technology, healthcare, social care and wellbeing businesses. Throughout my professional career I’ve been interested in all development methods – from SW development to business & customer development. I was first exposed to SAFe whilst working at Nokia a decade ago, but the real revelation of SAFe to me happened at GE Healthcare in 2014. We had 16 teams, nearly 200 professionals scattered across globe with a goal to create multiple new products together. We applied SAFe to align the goals, sync on delivery and to optimize flows.
Juhana:
I’m a lead consultant of software development at Gofore. I have a background in software engineering and have been in the IT field for more than decade. I’ve taken part for some of the biggest public sector digitalization endeavours in Finland. For some reason, I’ve always been the guy who’s removing obstacles and trying to improve everything. So, the Scrum Master’s duty was a natural choice for me. Lately, I’ve focussed on transforming entire organisations to Agile mode. In the latest project, I was consulting a large software program that required Agile transformation. I needed a powerful and straightforward solution for the transformation. The LeSS approach caught my attention very quickly; the LeSS principles and rules were understandable and simple. The challenges confronted in the target organization were tackled intelligently with the LeSS method. This  would not have been possible if using a one-size-fits-all format such as the SaFE.
Conclusion:
SAFe interest people in management type of roles and LeSS fascinates adventurous problem solvers.

Rising Action

Question #2: Imagine a 40 person project working in waterfall model. How would you deploy SAFe/LeSS?

Educate everyone into Agile mindset

Stefan:
SAFe provides the best practices from industry also for the deployment of SAFe. The things to conside in deployment are:

  • Train everyone: a) train the leaders, b) train the internal change agents, and c) train project personnel.
  • Split project to 2-pizzas-serves-them teams. Select team level development methodology, e.g. Scrum. Make sure that teams have the right set of competences to work as feature teams.
  • Define the way of working for the organization. For a 40 person program the two lowest level of SAFe framework serve the purpose: 1) Team level and 2) Program level.
  • Then it’s about start your Agile Release Train to develop in common cadence according to commonly agreed increment plan. The increment planning and demo sessions are where the magic happens – the whole program planning, resolving and agreeing together in the same room and at the same time.

Juhana:
The LeSS creator Craig Larman’s advice for large, multi-site, and/or offshore programs is just ‘don’t do that’. Instead pick the ten best developers. If you must scale, here are the adaption principles:

  • You should educate everybody. The easiest way is to sign people to the Scrum and LeSS trainings. The formal coaching is followed up by a team, organisational and technical coaching.
  • Define the product as broadly as possible. A broader definition tends to be more customer centric and creates simpler organisations.
  • Define the ‘DoD (Definition of Done)’. A better and stronger DoD eliminates groups, roles, and positions.
  • Have appropriately-structured teams. One team member belongs to only one team, and the teams are stable, long-lived, cross-functional, and co-located. Only the Product Owner provides work for the teams. Keep managers away from the teams.

Conclusion:
Both approaches aim to educate and engage everyone.

Climax

Question #3: Our current organisation has 3 team leaders, 1 architect, 1 project manager, 1 product manager and 1 UX/AD specialist. What would these persons do in SAFe/LeSS?

Stefan:
When using Scrum on team level then there are roles of the Scrum Master, Product Owner and SW developers. On program level you’ll find Product Management and Business Owners. Note, that the role of leaders in SAFe is different from traditional management – the roles are Lean-Agile leadership type of roles.

  • The old team leaders from the legacy organization could become developers, Scrum Masters or Product Owners depending on their capabilities and desires.
  • Architect and UX/AD specialist could continue working across the teams in program level roles.
  • Project manager could be promoted to the role of Release Train Engineer.
  • Product Manager could continue with same title, but in a modified role at product management.

Juhana: 
Specialised roles are forbidden in LeSS.

  • The team leaders can become Scrum Masters. They should follow the servant-leadership-mindset such as putting people first, coaching, removing obstacles, and creating the community. One Scrum Master can serve one to three teams.
  • The Architect and UX Designer will each join a team. In addition, the architect can lead or be part of the architect community, and the UX Designer can lead or be part of the user experience community. The communities ensure the cross-cutting quality and are run by the team members.
  • the product Manager can take the Product Owner’s role and responsibilities.
  • The project Manager could focus on increasing the capability of the organisation’s value delivery with using techniques such as ‘Go and See’ and ‘See the Whole’. The Product Manager role is also temporarily needed if there is a weak Definition of Done.

Conclusion:
Tune-down way of SAFe makes it easy to sell towards legacy management.  SAFe has built-in program management process and roles. Build-up way of LeSS asks “How to simplify the organization, and be agile?”.

Question #4: Okay, now the program is working according to SAFe/LeSS framework. How does the model scale when you add two more teams?

Stefan:
SAFe’s program level guidelines make this rather easy. Assuming the teams are feature teams then it’s rather easy to add new teams – just invite them to the common Release Train Planning event and share the prioritized increment backlog across the teams. SAFe can scale up to multiple release trains and multiple value streams, but at that extreme we would be then talking about thousands of developers, and that’s a bit scary anyway.
Juhana: 
LeSS scales easily – you just add two more teams to the structure. Avoid creating component-based teams such as front-end, integration, or operation teams. If the number of teams exceeds eight, use the LeSS Huge framework. It’s based on the same principles and rules, but adds a few extra practices.
Conclusion:
After reaching Lean Agile organization scaling is easy.

Resolution

Both models require the Enterprise to change. Agile is about mind-set, not about roles or processes.

It seems that the path for agile scaling is rather similar, no matter what framework you are using. After the first hour of shooting, there is yet no clear winner.
Thanks for reading! Please, throw in any additional questions!
We will tackle those in the Shootout Sequel, where we will finally find out, which one of these two frameworks is the best.

Jari Hietaniemi

Jari Hietaniemi

Jari Hietaniemi is an enthusiastic digitalization consultant. He specialises in complex and vast software projects. His philosophy is based on thinking that a consultant must know technology, architecture, project management, quality assurance, human resources, coaching and sales. His versatile experience and constant quest for improvement help to finish projects successfully and to bring new drive into client organizations.

Linkedin profile

Do you know a perfect match? Sharing is caring

Gofore projects exposed

So, what kind of projects do you do at Gofore? What technologies are you using? How are your projects organised? These are the questions I often hear when interviewing, or when in discussions with customers or colleagues from other companies. Sometimes even when travelling on early morning buses but never on the dance floor.
These are actually quite difficult questions to answer, as there are so many projects and they are all so different. Our company is also growing very fast and there tends to be new and exciting things happening every day. To shed light on these questions, at Gofore we conducted our second ‘project radar’ this spring. Gofore Project Radar is loosely based on technology radars published by various companies, but instead of discussing what kind of technologies are currently of interest, our approach is concentrated more on what kind of software projects we actually do and how we do them. It is worth pointing out, that even though this radar concerns only our software projects, at Gofore we work in a broad field all the way from designing services to leading digital transformation.
Our first radar was conducted in the autumn of 2016, this spring we tweaked it a bit and had another round. The main purpose of the radar is to show our own employees what kind of software projects we do, but it also serves as an interesting overview of our company to anyone who is interested. If you are seeking a developer job, technologies listed on the radar are the ones you should feel most comfortable with. If you are one of our customers or just interested in general, the radar gives you a nice perspective on what is going on in the field. In this blog, I am going to discuss some of the most interesting findings of our latest project radar survey.

There’s a new kid on the front-end block, again!

The last few years haven’t been exactly a walk in the park for people dealing with front-end technologies. Huge demand for creating ever more usable, architecturally solid and eloquent solutions has led to a situation where new frameworks (that promise to change everything) tend to emerge during your coffee break. However, according to our radar, it seems that two technologies with different approaches, React and Angular, are the survivors of this battle. If you are interested, you can read more about comparing these two approaches from our earlier blogs.
Currently, both React and Angular seem to be popular choices in our projects. In our radar survey, Facebook-backed React, with or without state handling frameworks, such as Redux, is considered the most popular front-end technology. It is being used in over 40% of our projects and 46% would choose it if the project was written again. Percentages preferring React are quite substantial, even though there is a small decline from 2016. Back then an even larger portion preferred React as the number one choice.
Angular is a solid player in the field, although it’s clearly less used compared to React. Google’s decision to write a new version of the framework without backwards compatibility to older AngularJS versions may be one of the reasons why Angular is now used less in our projects. There is a lot of older AngularJS code in the world and that is also the case in some of our projects. Despite these drawbacks, new Angular is still a somewhat popular choice: almost 20% of our respondents would prefer it.
Nevertheless, in the front-end developers’ world there is always something new and shiny coming around the corner. This time it is Vue.js, which seems, again, to be a little better and nicer than its competitors. Vue.js did not show on our radar at all in 2016, but now almost 15% of all the respondents would choose it for front-end work. Déjà vu!

Java, old chum

To me Java is like country music. It seems to never go out of style (if it ever was in style), and you are never quite sure if you like it or hate it. A few years ago, my opinion was that Java as a language will eventually disappear and more sophisticated, yet JVM-based, languages – such as Scala or Clojure – will surely replace it. According to our radar that is, well, not happening, at least not any time soon. Java still has the clear majority and no other language comes even close. Interestingly, Java is also considered a favourite technology for back-end development, should the project be written from scratch. Maybe it is because of the big improvements made with the advent of Java 8. Although Java is still very verbose and lacks some of the coolest features of its rivals, the language is steadily improving.
That said, the biggest reason for choosing Java is most likely in the customer requirements. In my experience, many organisations tend to safeguard their software development by favouring more mature and established languages. Companies are afraid that choosing less popular (yet promising) technology can turn out to be a very bad decision later, if there is, for instance a lack of proficient developers in the market or the community loses interest.
On the other hand, choosing the right tool for the problem can really turn the tables in development efficiency and thus time-to-market.  A few years back, a somewhat bizarre idea of using an open-source Javascript engine (originally developed for the Google Chrome browser) for server-side development was considered categorically horrible by some folks. Today, using Javascript and Node.js for back-end development is not only a valid but, the second biggest choice in our projects (16%) which basically means you do not always have to listen to Dolly Parton.
As the size of our company is increasing, we have also expanded our technology selection further to fulfil the needs of our customers. Since our last project radar, one particularly growing technology in our projects has been .NET Framework. Now, C# is used roughly in every sixth project for back-end development, which is quite an improvement on 3% in 2016. This does not mean that there have been technology switches from other alternatives in our customer projects, but rather many new projects are starting with Microsoft stack.
Lastly, Python has been, and still is a very viable option. It is often being used, for example, in our data-science related projects along with R. Several projects also use Python as a complementary choice for specific purposes.

Mom, those big boys are putting containers everywhere!

One pleasant result of our survey was that cloud services are being used in one way or another on 60% of our projects. This is great news for everyone (except traditional service providers) as cloud platforms often bring better ‘bang for the buck’ and enable a more dynamic environment for software development. This does not necessarily mean that the actual production environments are in the cloud. Instead, many still use more traditional service providers in parallel with cloud services, such as Amazon Web Services or Azure. Often, especially in public sector projects, legislation enforces that actual customer data remains within country borders. Even in these cases there are hybrid solutions that benefit from both cloud and traditional service provider offerings. This can be a great alternative for tackling, for example, cost effective load balancing and still maintaining customer data on private servers.
Things that go great together with cloud infrastructure are software container platforms. They are also becoming a more common alternative in our projects and the single biggest tool in this field is Docker. Using container technologies allows teams to handle development in better isolation of infrastructural issues and foster development and operation synergies. Over half of our respondents were at least assessing Docker and almost 40% were using it in production. However, it is not for everyone – one third was not considering it now and some 16% decided to put it on hold for now.

Where do we go from here?

Having a company-wide understanding of what is really going on in our software projects, what technologies we know well, and what the biggest trends are is essential. Gofore Project Radar is one way of gathering and sharing this information and our intention is to develop this even further. In the future, we aim to have even more accurate and up-to-date results and we would like to share these in public as well. We will get back to this subject in the autumn, but in the meantime let me ask: how is your project radar looking?

Avatar

Kustaa Huhtala

Kustaa is a software professional with strong expertise in versatile modern technologies, agile methodologies and project management. He has also worked as a lead developer, agile coach and scrum master in several projects.

Linkedin profile

Do you know a perfect match? Sharing is caring

The best place to work in Finland is now also one of the best places to work in Europe. Gofore, an expert in digital services, rose to 2. place in the ranking of the best workplaces in the Great Place to Work Europe. The announcement was made during a gala dinner held in Paris on June 8th. Gofore is seen as an innovator of work culture, which relies on solid expertise and a relaxed and open atmosphere. This innovative culture is also helping as Gofore opens new offices across Europe
“The heart, hands and feet of operations of Gofore are our enthusiastic employees, who are at the peak of their profession. The award is recognition of the fact that the people who are extremely important to us also sincerely enjoy their work, and we’re not only the best place to work in Finland, but also one of the absolute top places in Europe,” Erkki Salminen, Director responsible for the company’s culture and competences, says with delight.
The fantastic work culture of Gofore is an example of a way of managing companies that are capable of modernising and which are required in a changing world:
“In this day and age, the companies that survive are those that are capable of change and that boldly look to the future. We believe that this is achieved through inspired people, shared learning and openness. The same cultural change can also be seen at the moment in our customer base – in addition to development of services, the digitalising world also needs reforming work and operating procedures” continues Timur Kärki, the CEO of Gofore.
Through the acquisition of Leadin, completed in May, Gofore is a genuinely international company and expanding operations in Europe is a natural part of the growth path of the company. The strong work culture serves as an excellent basis for internationalisation and the top ranking indicates that Gofore is also an attractive employer on a European level.

Rapid growth and even more satisfied employees

Growth into new markets does not only mean expansion of business operations, but also new work opportunities for employees of the company. Gofore’s style of management emphasises a wide-ranging search for things that are new, both at a company and at an individual level. Work roles which are invigorating and support one’s own development are at the heart of the open culture and offering international opportunities is one way to create an even better work community.
“Recruiting the best professionals in their fields is important to us. We have always believed strongly that people who get fired-up by their work also inspire our customers. In this way, top expertise and creation of
customer value are combined and the end result is a satisfied customer. Everyone takes pleasure in the successes,” adds Salminen.
The company’s rate of development is intense, but right from the beginning the number one value of Gofore has been that the company is as good a place as possible for everyone to work at. The annual rise in the Great Place to Work rankings, combined with continuous growth, is evidence of this. Last year, the company was sixth on the European list. Earlier this year, Gofore was chosen the best place to work in Finland rising from 3rd in 2015 and 2016.
100 companies from a group of 2 340 companies were selected onto the Great Place to Work Europe list. The list is based on national surveys carried out by Great Place to Work in 19 different European countries.
Further information:
Erkki Salminen, Director, Culture & Competences
+358 40 738 5650, erkki.salminen@gofore.com
Erkki is in Paris representing Gofore. The best way to reach him is by phone or with a text message, where you can also leave a request to be called back.
Timur Kärki, CEO
+358 40 828 5886, timur.karki@gofore.com
Riikka Nurminen, Marketing & Communications Director
+358 50 486 8600, riikka.nurminen@gofore.com

Gofore Oyj

Gofore Oyj

Do you know a perfect match? Sharing is caring

Web analytics is one of the essential tools for a website and in addition to measuring web traffic and getting information about the number of visitors it can be also used as a tool to assess and improve the effectiveness of a website. The most common way to collect data is to use on-site web analytics that measure measuring visitors’ behaviour on your site with page tagging technology. This is how Google Analytics, which is widely used web analytics service, works. But what would you use if you wanted to keep control over your own data?
Look no further! Piwik is an open source web analytics application which aims to be the ultimate alternative to Google Analytics. Here’s a short overview to Piwik Analytics and how to get started with it.

“Web analytics is the measurement, collection, analysis and reporting of web data for purposes of understanding and optimizing web usage.” – Wikipedia

Piwik Open Analytics Platform

Piwik is a web analytics application which tracks online visits to one or more websites and displays reports of these visits for analysis. In short, it aims to be the ultimate open source alternative to Google Analytics. The code is GPL v3 licensed and available in GitHub. On technical side, Piwik is written in PHP, it uses MySQL or MariaDB database and you can host it by yourself. And if you don’t want to setup or host Piwik, you can also get commercial services.
Piwik provides the usual features you would expect from a web analytics application. You get reports regarding the geographic location of visits, the source of visits, the technical capabilities of visitors, what the visitors did and the time of visits. Piwik also provides features for analysis of the data it accumulates, such as saving notes to data, goals for actions, transitions for seeing how visitors navigate, overlaying analytics data on top of a website and displaying how metrics change over time. The easiest way to see what it has to offer is to check the Piwik online demo.

Feature highlights

You might ask how Piwik differs from other web analytics applications such as Google Analytics? One principle advantage of using Piwik is that you are in control. You can host Piwik on your own server and the data is tracked inside your MySQL or preferably MariaDB database. You have full control over your data. On contrary, software as a service analytics applications, have full access to the collected user data. Data privacy is essential for public sector and enterprises who can’t or don’t want to share it, for example with Google. You are able to ensure that your visitors behaviour on your website is not shared with advertising companies.
Another interesting feature is that Piwik provides advanced privacy options: ability to anonymize IP addresses, purge the tracking (but not report)  data regularly, opt-out support and Do Not Track support. Your website visitors can decide if they want to be tracked.
You can also do scheduled reports which are sent by e-mail, import data from web server logs, use the API for accessing reports and administrative functions. Piwik also has mobile app to access the analytics data. Piwik is also customizable with plugins and you can integrate it with WordPress and other applications.

Piwik’s User Interface

Piwik has clean and simple user interface as seen in the following screenshots (taken from the online demo).

Piwik Dashboard

 
Piwik Visitors Overview

Setting up Piwik

Setting up Piwik is easy and there’s good documention available for running web analytics. All you need is a web server such as Nginx, PHP 7 and MariaDB. MariaDB has in some cases significantly improved query performance and reliability of Piwik over using MySQL. You can setup Piwik manually but the most easiest way to start with it is to use the provided Docker image and docker-compose. The docker-compose file setups four containers (MySQL, Piwik, Nginx and Cron) and with compose you can start them up. The Piwik image is available from Docker Hub.

The alternative is to do your own Docker image for Piwik and related services. In my opinion, it makes sense to have just two containers: one for Piwik related web stuff and other for MariaDB. The Piwik container runs Piwik, Nginx and Cron script with e.g. supervisor. The official image uses Debian (from PHP) but Piwik runs nicely also on Alpine Linux. One thing to tinker with when using Docker is to get MariaDB access to Piwik’s assets for LOAD DATA INFILE which will greatly speed Piwik’s archiving process.

Third choice is to spend some money, skip the technical setup and use cloud-hosted Piwik Pro.

If you’re setting up Piwik manually, you can watch a video of installation and after that a video of configuring settings. After you’re done with the 5 minute installation you get the JavaScript tag which is then included in the bottom of each page of your website. If you’re using React there’s a Piwik analytics component for React Router. Piwik will then record the activity across your website into your database.

And that’s about all there is to starting with Piwik. Simple setup with Docker or doing it manually, adding the JavaScript tag, configuring some options if needed and then just wait for the data from visitors.

Piwik: your data, your analytics

Piwik is a good and feature rich alternative for a web analytics application. Setting it up isn’t as straightforward as using some hosted service, such as Google Analytics, but that’s the way self-hosted services always are. If you need web analytics, want to keep control of your own data and don’t mind hosting it yourself and thus paying for the server, then Piwik is a good choice.

This article was originally published on Rule of Tech, author’s personal blog about technology and software development.

Avatar

Marko Wallin

Marko works as a full stack software engineer and creates better world through digitalization. He writes technology and software development related blog and developes open source applications e.g. for mobile phones. He also likes mountain biking.

Do you know a perfect match? Sharing is caring