On 28th of October I jumped on the morning train from Vaasa to Tampere in order to attend my first ever Tampere Goes Agile event. This is a summary of the event and summarizes what I learned from it. The event was in Tampere Hall. They took good care of the guests starting with a little breakfast upon arrival. There was always coffee available during the breaks and lunch was served in the middle of the event. They even arranged an after party but I only had 30 minutes of time there to socialize before I had to jump on the train back to Vaasa. Overall, it was a positive experience and I hope to be able to attend next year as well.

I will use these TLDR notations for a quick summary of each presentation that I attended, which hopefully helps in making the decision whether to read about it or not.

But I want the team to be X times faster(!)

TLDR; the role of the team lead is to protect the team and help bring out the best out of them. There is no silver bullet (read agile methodology) for great performance. The team makes the results. Experiment and learn to see what suits best.

Mika Turunen is the Chief Technology Officer at Checkout Finland, which is part of OP Group. He shared his story so far as a CTO and team lead. One of his main tasks, according to him, was to bridge the gap between the CxO level and developers. He even went to say that usually the teams are doing quite well and that management needs to be driven. He continues quite quickly however to switch the focus on the team, something that he talks about for the majority of the keynote. He emphasized the need for taking small steps and making the work visible. This also helps build trust in management. He wanted to build trust with the team, which meant getting to know each team member. Who they are, and what they do both on and off work. He continued to show the importance of getting the people to work as a team, experiment and learn from their mistakes. Try out different tools and methodologies to see what works and what does not. Never did he allow the management to directly “give feedback” to the team but instead he worked as a shield to protect the team. See each person for their individual strengths and needs and aim to arrange their work accordingly. Some like to implement new things (even to the point that they seldom finish it), while others then like the problem solving part that is required when fixing bugs. As a team lead, you should emphasize the importance of retrospectives, continuous improvement and even futurespectives that works as a type of risk management. His top takeaways at the end of the keynote was:

  • There is no silver bullet
  • Be good with your team (be present)
  • Focus on communication

E3: Enabling, Empowering and Emotional

TLDR; Ericsson’s E3 training is a 24-hour workshop what they use to help employees take a leap in performance instead of incremental improvements. The three E’s come from the words Enabling, Empowering and Emotional.

Kati Ilvonen & Hanna-Mari Loisa gave us a sneak peak of their E3 workshop that is in use in Ericsson. The idea for the workshop was born when management in Finland genuinely wanted to know how to get individuals to take leaps forward in performance instead of incremental improvements. They use the term emotional shift. The 3-day workshop was born. It consists of the following main themes:

  • You as a person
  • Encounters/working with others
  • Future/what next

The actual contents of said workshop are quite vague as this workshop was a kind of a tasting of the actual workshop. We tried out some of the activities from the actual event. In hindsight, I would say that all activities related to the first theme and as such focused on quite a lot on self-awareness. The most impressive thing was probably how open Finns were among strangers about their feelings and expectations. We covered such topics as what is our passion, how to break beliefs and restrictions to reach bigger potential, and that one can always choose the attitude how you address situations. It is quite difficult to summarize anything “useful” to share from this session. It was interesting but to be honest I had a bit different/higher expectations from the session prior to the event.

Negative emotions, primary driver of team development

TLDR; it is in our nature to be lazy. As a result, we are reluctant to change until we reach a certain point when we discover that something has to change for the better. Turn the negative feelings to a positive goal and start the journey towards change through small incremental steps.

After the lunch break, it was time to listen to Eetu Kaivola from Siili talk about making a change. He told a parallel story from his personal life about being overweight and compared this to his experiences from driving change and coaching teams in work. Eetu stated that by human nature we are lazy and rather remain unchanged than change the way we do things. We resist change until the situation gets unbearable and we make the conclusion that something has to change! Usually the first step here is that we set too ambitious goals and get even more depressed due to the imminent failure. Instead, one should start by taking small steps towards revelation. This applies to teams as well. Personal well-being is equally important because you seldom care about the team if you are not feeling well on a personal level. So to sum it up:

  • Find something that bothers you
  • Challenge the status quo
  • Turn negative emotions to a positive goal
  • Share the vision in order to gain the motivation for change

Agile fixed price projects

TLDR; Project model that is used depends on three perspectives. Managing risk, perceived value and psychological security. One alternative is to sell fixed price and fixed content over one-month long iterations called here the fixed price agile model.

This was one of my highest anticipated talks of the day due to my role in daily work at Wapice where I constantly try to find the balance between project agility and customer expectations. Teemu Toivonen from Triari shared his view on this topic.

Teemu started off with a controversial statement that fixed price projects is the death march for developers. Developers are often the ones who take the consequences when e.g. requirements change, estimates are wrong, we discover better ways of implementing a solution or maybe worst, we lack a shared understanding of the scope and what we should achieve. To tackle this there are three perspectives to take into account:

  • Managing risk
  • Perceived value
  • Psychological security

You need to find a balance in these factors together with the customer affects the outcome of the project. The customer usually want share the risk; they want to feel that they get value for their investment; you need to make the customer feel safe in the decisions that they make.

If you split your work into smaller pieces, you can better manage risk. Agility in requirements, problem solving and design is another way to manage risk. Perceived value again has a lot to do with emotional aspects, such as risk adversity, compliance with existing structure and outsourcing inconvenience. Psychological safety plays an important role. In essence, this is about true partnership where we focus on the process rather than the outcome, manage to learn, work transparently and feel that we are on the same boat.

So agile has solutions to many of these things. Is agile the silver bullet that will save us all? Not necessarily, although it has many benefits mentioned above. The reason for this is that customer has all the risk. There might be a mismatch with governance practices (read budgeting, decision-making and approval). Lastly, the customer might think that it is too big of a leap to take. This is something that I wholeheartedly agree on as we are working with big customers from the industry. One aspect for us subcontractors is that agile model also might lead to lower profits, as we work per hour and lack a buffer/margin in the work that would occasionally increase the profit.

Finally, Teemu presented his solution to this problem. Fixed price agile, which means selling fixed price short iterations to the customer. Below are the main points:

  • 1 month fixed price project (time, cost, scope).
  • Using business requirements (relax requirements).
  • Scope base on team estimation relative – minus % from estimate.
  • Pricing contains 20 % overhead for risk.
  • Project contains all changes in a business area (many teams).
  • LeSS or SAFe coordination and planning between teams.
  • Safe and trust is created with good history and openness about the model.
  • It does not matter if an individual project goes over – it will even out over the year.

The benefits here are that customer has a perceived security with fixed price offers and subcontractors have possibility for increased profit, due to the margins for overhead. Personally, my only concern with this model is that the one-month iterations are too short. Customer wants longer commitments, at least from my experience. Teem ended the presentation well by summarizing that this is not necessarily the best solution either. What it important is that context matters. Talk with your customer to find a model that fits you and where there is a balance between the three perceived perspectives mentioned in the beginning of this text. Best presentation of the day, although it did not give me any ready solutions/answers that I looking for.

Deploying agile in multi-site multi-culture environments

TLDR; Rauno Kosamo a former Nokia employee shared his story from adopting agile in a large organization. He presented many challenges, such as external, internal, and cultural challenges. All this resulted in failures and quality problems. Bit by bit they were able to improve, but it was a rough road and Rauno joined other challenges before reaching the end of the transformation.

Rauno tried to keep it secret which company he was reflecting on, but already in the beginning, it was quite apparent that he was talking about his former employer Nokia. The presentation was more of a story pinpointing everything that was wrong in the organization, and I must tell it did not sound good. I see little benefit in listing all the problems he mentioned so instead I will highlight the most interesting parts.

The key takeaway for me, even if we are not a multi-site global organization, was the Lewis Model (dimensions of behavior). It lists several countries in a triangle based on the way they like to work. So not only are there time zones that makes global cross-site challenging, more importantly there are differences in work culture. The more apart from each other you are in the triangle, the more differing cultures are you working with. His case example was working from Finland, Poland, U.S.A., and India. Look at the above link and figure out whether it is a good match.

Another interesting takeaway is how they addressed all these issues. They were:

  • Product level Kanban board, to give an overview picture of the development.
  • They started measuring end-to-end flow.

Rauno ended the presentation with the “culture eats strategy for breakfast”, which was in his opinion the end state when he left the company. This was almost a weird presentation, in the sense that it was brutally honest and showed how also one of “Finland’s greatest” have their struggles.

The day ended with a discussion panel that did not bring anything new to the table. In my opinion, panelists more or less concluded what he or she told in their own presentations earlier during the day.

This was my first visit to Tampere Goes Agile and I hope that I can participate again next year and hopefully be more open to discussion with other participants during all breaks in order to hear more about working practices in other companies.