Go Agile!

Agile Day Riga
  • March 17, 2011
  • Radisson Blu Hotel Latvija, Riga
  • 200+ Participants
  • 18 Speakers

Agile Day Riga 2012

Goal of this conference is to provide a clear explanation to participants why agile and lean software development approaches become so important nowadays, show how these approaches help to solve problems and facilitate discussions and experience exchange between agile practitioners and newcomers.

The conference will cover questions how to make a transition from traditional approach to agile and contain real life examples and case studies, presentations and workshops for beginners and advanced agile practitioners.

Dozen of highly skilled and passioned professionals from across Europe will tell their stories, will share their experience and will give their advices. Both technical and non technical workshops will be organized as well during the conference.

What is Agile Day Riga?

Goal of this conference is to provide a clear explanation why Agile and Lean software development approaches became so important nowadays, show how these approaches help to solve problems and facilitate discussions and experience exchange between Agile practitioners and newcomers.

Agile Day Riga
Agile Latvia

What is Agile Latvia?

Agile Latvia is a community with a goal to spread information about Agile practices amongst Latvian software development professionals and industry newcomers.

Our Gratitude to

Agile Alliance

Agile Alliance supports people who explore and apply Agile values, principles, and practices to make building software solutions more effective, humane, and sustainable. We share our passion to deliver software better every day. We are a nonprofit organization with global membership, supporting and serving the Agile software community since 2001.


C.T.Co is a leader in agile application development. C.T.Co limited is a Europe-oriented IT solutions and services provider, based in Riga, Latvia (EU) with a track record of delivering enterprise solutions to top global clients for over 15 years.


A Coding Dojo With a Twist

A CyberDojo is coding dojo with a difference. Each group: writes their code and tests inside a web browser; presses their run-tests button to submit their code and tests to the CyberDojo server, the server saves the submission, runs the tests, and returns the test-outcome to the browser as a traffic light; green if all the tests passed; amber if the tests could not be run (eg syntax error); red if one or more tests failed; a dashboard shows each groups traffic light history. Click on any traffic light to open a diff-view of that submission; periodically a bell rings, indicating the driver from each group must move to another group and become a navigator. I built CyberDojo to promote deliberate software practice of: test driven development, and team dynamics and collaboration. I strongly believe that if you practice coding using your normal development environment then you are likely to be drawn into an unhelpful “completion” mindset. Practising in a CyberDojo helps to combat this tendency since a CyberDojo is so obviously not your normal development environment! Practising in a CyberDojo helps you to concentrate on the practice.

Jon Jagger

Hi. I’m 2C years old (hexadecimal) and I’ve loved software since I was about 10 (decimal). I’m a self employed software coach-consultant-trainer-programmer-etc specializing in practice, people, process, agility, test driven development, and systems thinking. I built CyberDojo to promote deliberate software practice. I’ve worked with Accenture, Cisco, Friends Provident, HP, Microsoft, Opera, Ordnance Survey, RBS, Reuters, Renault F1, Schlumberger, and many many more. I work on a no win, no fee basis. If you don’t like my work I won’t invoice you. I’m the ex ECMA TG2 C# convenor. I’m the current ACCU conference chairman. I’ve had some C# books published. I’m married to the beautiful Natalie, and proud father of Ellie, Penny and Patrick. I love freshwater river fishing. I live in rural Somerset in England.

Agile Communication

Everybody agrees these days that communication is one of the key success factors in any project, regardless of their size and complexity. During the agile adoption process, many teams and managers are blind to communication issues and believe everything is working just fine. However, experience suggests that communication is failing at many levels -managers don't really understand their developers, testers and other geeks, who on the other hand often fail to effectively sell their point back to management. Similar situations exist between sales and technical experts or even between developers and testers. The fact is that speaking the same language doesn't guarantee the understanding of each other's points. This highly-interactive talk shows typical communication patterns, behaviors and provides eye-opening insights into the ways communication can improved Some practical games include the whole audience, which typically makes the session very lively and engaging.

Zuzana Šochová

Over 11 years of commercial experiences in IT, beginning as a software designer/engineer and moving up into project management, program management, and into executive management at a company provides SW services for international customers (USA, Germany, Austria, Great Britain, …) that operating in mission critical and life critical sectors – i.e. air traffic control management systems, extensive healthcare applications, and public safety systems. Started with agile and Scrum back in 2005, where I was involved in implementing the agile methods at large US company operating in the medical area. From that time, I was responsible for implementation of agile and Scrum to teams in the Czech Republic operating in different areas of IT industry. Currently she works as a trainer, consultant and coach for software organizations, support them in tailoring their agile adoption processes to company culture. She is founder of the Czech agile community Agile Association, organizing conferences and events and sharing the agile experience all around. She is regular speaker at international conferences. She is Managing Director of LOTOFIDEA.

Agile Contracts — Thesis, Antithesis, Synthesis

Thesis: In order to have control over software project, a customer needs to have a contract that holds a supplier’s feet to the fire and fixes the price and scope of what is delivered. Antithesis: Effective projects require collaboration between a customer and a supplier. A contract that fixes the price and scope of the project undermines the trust needed for this collaboration. Synthesis: Target price contract aligns the incentives of the supplier and the customer towards making the scope match the budget. This gives the customer control over the price and value of the created software while maintaining a collaborative environment.

Johannes Brodwall

Johannes Brodwall is a solution architect by day and a test-infected Java programmer by night. He discovered extreme programming more than ten years ago and has been trying to practice test-driven development, continuous integration and pair programming ever since. He still fails more than he would like. He works for Steria Norway as chief scientist and spends his copious spare time organizing the monthly Oslo XP meetup user group and the annual Smidig 20xx conference.

Anonymous Analyst

The role of software analyst is full of misunderstandings. In cross-functional teams we focus on having a shared vision and shared architecture. We avoid specializations, we force every member of a team to act and pull required information from all available sources without additional chains in the communication. The role of traditional software analyst does not fit nicely into Scrum either. They have been usually separated from teams and we cannot call them neither Scrum Masters nor Product Owners. However, software analysts play essential role in cross-functional teams. Our understanding of what they should do and the role they play in a team should be different. Analysts help us understand and we should focus on sharing this understanding inside the team. Here I will present the roots of misunderstandings and some practical tips how they can be avoided.

Stanislav Vasilyev

Agile Coach. Co-founder and one of the event organizers at Agile Estonia. Believes in common sense and things that work instead of methodologies and frameworks.

Becoming Agile in Public Sector Project

Becoming agile is not an easy task, especially if you are working in public sector project. Though it is possible and we have managed to do it. Here is our advice on how to do it: Seek for opportunities. Public sector project carry pretty heavy burden of administrative work, which does not go well together with strive of agile practices to eliminate waste. Though sometimes things which seem to us as obstacles at the first glance, are in fact opportunities. We will teach you how to use some of them; Start small. Starting all is often scary, and build resistance to agile practices on both customer and supplier side. By implementing practice by practice you will have enough time to gain trust and build confidence of the team; Work harder! When you start using agile practices in software development, all team members both on customer and supplier side have to commit to following them. Lack of commitment justified by lack of understanding or complexity of chosen approach might actually hide bigger problem - insufficient ability to deliver. Sometimes it is enough just to start working.

Linda Vītuma

My passions: information system 'go-live', problem solving and change management. Have worked 12 years in IT industry. Pretend to be 'early adapter'.

Elina Jakubaneca

Elīna Jakubaneca has been working for Tieto Latvia (former TietoEnator Alise) for five years as Scrum Master, Project Supervisor and Department Manager for Oracle E-Business Suite based projects. Now she is Senior Consultant in her newly founded company eBIT, SIA. Her main professional interests are related to Agile project supervision and project portfolio management.

Extreme Startup

Extreme startup is a team-based coding competition. Over the course of a few hours, you will write an application that answers the questions from the workshop server. You can work solo or in pairs, test-driven or cowboy coding, in any programming language you want. Answer the most questions and win the competition! This workshop was first run at #xp2011 by Richard Chatley and Matt Wynne. Johannes have run the workshop several times in conferences and companies. For more information on the workshop itself, see Johannes' blog post on extreme startup. Bring a wi-fi-capable computer with the development environment(s) of your choice. (If you can't bring a computer, you can pair with someone else. We depend on most people bringing a computer, though)

Johannes Brodwall

Johannes Brodwall is a solution architect by day and a test-infected Java programmer by night. He discovered extreme programming more than ten years ago and has been trying to practice test-driven development, continuous integration and pair programming ever since. He still fails more than he would like. He works for Steria Norway as chief scientist and spends his copious spare time organizing the monthly Oslo XP meetup user group and the annual Smidig 20xx conference.

How to Be a Lean Product Developer?

We are not just writing software – we are in business of creating a great inspiring product that serves a purpose. During the session you shall learn how to communicate and validate your ideas faster, how to build your product faster, how to measure it all (faster) and how to learn faster while doing all these activities.

Marko Taipale

Marko Taipale is an entrepreneur in Helsinki specializing in management of agile and lean product development processes. He is a co-founder and Chief Technology Officer of Huitale with over 14 years of experience in software development. He has helped a number of companies to transform to agile and shares some his experiences on his blog.

How to Change the World

How do I make my managers more Agile? How can I convince developers to educate themselves? How can I make customers more cooperative? How do I start a European network of Agile and Lean practitioners? When transforming organizations and other social systems people usually encounter obstacles. And these obstacles very often involve changing other people’s behaviors. Of course, we cannot really _make_ people behave in a different way. We also cannot really make people laugh, and we cannot really make people happy. But… we can certainly try! This session is about Change Management 3.0. It is a new change management “super model” which views organizations as complex adaptive systems and social networks. The Change Management 3.0 supermodel wraps various existing models (PDCA, ADKAR, Adoption Curve and The 5 I's). It lists a few dozen hard questions that can help people in their attempts to change the behaviors of other people in an organization and beyond. No matter whether you are a manager, Scrum Master, Product Owner, software developer or writer, anyone will find it useful to know how to change the world around them.

Jurgen Appelo

Jurgen Appelo is a writer, speaker, trainer, entrepreneur, illustrator, developer, manager, blogger, reader, dreamer, leader, freethinker, and… Dutch guy. Since 2008 Jurgen writes a popular blog at www.noop.nl, which deals with development management, software engineering, business improvement, personal development, and complexity theory. He is the author of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders, which describes the role of the manager in agile organizations. He is also a speaker, being regularly invited to talk at business seminars and conferences around the world. After studying Software Engineering at the Delft University of Technology, and earning his Master’s degree in 1994, Jurgen Appelo has busied himself starting up and leading a variety of Dutch businesses, always in the position of team leader, manager, or executive. Jurgen has experience in leading a horde of 100 software developers, development managers, project managers, business consultants, quality managers, service managers, and kangaroos, some of which he hired accidentally.

How to Coach Traditional Managers into Lean and Agile?

Managers are often quoted as an impediment for Agile adoption. We have seen also otherwise: managers might be the crucial make it or break it force within organization that is ongoing change. In this presentation several aspects of change management, leadership and coaching are touched. Real-life examples from Ericsson Finland: team formation and operation (managers and coaches role), Change Roadmap, coaching Leadership Teams, different levels of coaching (individuals, teams, PO, portfolio, line management on different levels). What is required from a management coach? How to get involvement? Why Scrum was seen as a threat for managers? How to involve people to change managers?

Henri Kivioja

Ericsson Finland started Agile transformation in 2008 with the first Scrum Team. Since then they have scaled up to 30+ teams and set up a complete e2e setup supporting Agile. This transformation has been (and still is) profound change in organizational thinking and culture. Henri Kivioja is delighted to share the experiences and learnings from this journey.

Introducing BDD

There is a great promise in BDD (Behaviour Test Driven Development). A promise of better understanding between Product Owner and the development team. Having experienced all that, Aki tells a story how he managed to introduce BDD process to his current work environment and what made it successful. The story has a happy ending.

Aki Salmi

Aki does not believe in magic. He makes it happen. Aki is a hiking guide of Suomen Latu and is using the leadership principles learned in such an agile environment in his daily work as Scrum Master. He is also the man behind Turku Agile Day, bringing the joy of agile software development to the crowds. Professionally his passion is agile testing and test automation where he has excelled during his whole career. Meet a man who is living his dream.

Mikado Method

A code base must be changed, or it will die. But sometimes these changes feels like a fight with the Legacy Software Hydra, for every scary head cut off, two more grows out. Every change takes us further from the goal! Instead, come learn the Mikado Method, a systematic approach to beat the Hydra and change the code in a safe way. It enables continuous delivery, and it enhances team communication, collaboration and learning, helping individuals stay on track. We will practice to visualize, prepare and perform business-value-focused changes, without having a broken code-base in the process. Process/Mechanics: Participants sharing code change horror stories to get in the mood; The horror story behind the Mikado Method, and the resolution; The core concepts to make it work, and the benefits of it; The Mikado Method kata in Java code (https://github.com/mikadomethod/kata-java), performed by presenter; Q&A/Debriefing. Participants perform same demo as a kata. Bring Your Own Laptop!! (Java and C# examples provided); Q&A/Debriefing. The material is also presented in a book which can be downloaded from http://mikadomethod.wordpress.com/book/

Ola Ellnestam

Ola Ellnestam came in contact with Agile in the year 2000 after reading Extreme Programming Explained. At the time he didn’t know what kind of impact that particular book would have on him and the software industry. Fueled by many new thoughts he began his Agile journey which later led him to start a company specializing in XP and Scrum. In 2005 Ola started Agical with three colleagues, one of Sweden’s most prominent Agile coaching companies of today. As an expert in software developing skills such as TDD and Continuous Integration as well as more soft skills he coaches both developers and leaders while they are learning Agile practices and methods. Today he is working with clients that are working with or would like to be working with Agile methods. This often puts him in situations where he has to defend, promote and question the values and practices behind Agile which he has become very familiar with. Ola is also one of the driving forces behind ‘Agile Sweden’, Sweden’s biggest Agile network.

Daniel Brolund

Automating developer, fearless restructurer of code, intelligent tester, and mentor in all those areas. Daniel is a software developer with a sixth sense for what works and what is effective. He is a co-creator of the Mikado Method, an effective way to restructure code bases of all sizes. He has been a speaker at JavaZone 2011, Turku Agile Day 2011, JFokus 20111, DevLin2011, Øredev2010, Agile2011/2010, XP2010/2009, SPA2010, XPDay2009, SDC2009, all Agila Sverige conferences and Smidig2008. The Mikado Method blog Ola and Daniel have created a method for making large scale refactoring in large software systems. On this blog You can read the latest regarding the method. Daniels blog A well balanced mix of deep thoughts and recommendations about agile practices.

Product Management in Agile Organization with Product Developed by Many Teams

Early in 2010 we implemented Scrum in Adform as its development process. More than 40 people were split to 6 cross functional teams. So what’s the big deal you will ask? The big deal for us was: we all work developing ONE product (SaS Ads Serving platform)! We are not working on separate projects! How to organize Product Management work to fit this? How 6 Product Owners should work together, with company management, and other departments? How to split big features and divide work to teams (usually one feature had to be implemented by few teams to bring value to the customer)? What to do with 'research' projects? How to handle the growth of the company (now we have more than 50 people and 8 teams)? In this presentation I will share our journey, as well as mistakes we made and lessons learned. If you are implementing Agile in organization or project with many teams working on one product - this presentation is for you.

Vaidas Adomauskas

Is working as a Product Manager and Scrum Coach in Adform. He is Product Owner (Product Manager) of one of the key company products as well as coaching Scrum teams with every day improvements. Before Adform, Vaidas had implemented Scrum in Lavasoft in Sweden. Vaidas is the author of the blog http://scrum.agile.lt, initiator of Agile and Scrum Users Group in Lithuania, Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), participant/speaker of international and national IT/Agile conferences, lecturer at Vilnius University (“Agile Project Management with Scrum” course), and member of Lithuanian Project Management Association.

Simple Effective Teamwork

Agile practices may be the way to build great software but what really matters is how well your team works together. In this beginner-friendly talk, Antti reveals the simple principles behind succesful software teams.

Antti Tarvainen

Antti is a software developer and a coach living in Tampere, Finland. He works for Leonidas and swears to good communication, understanding the customer, and seeing the big picture. He believes that the keys to better software are good communication and keeping it simple. You can find his thoughts in his blog.

Story Points Considered Harmful – A New Look at Estimation Techniques

Story Points are the typical estimation unit for Agile Teams. But do they really work? Or are there better ways to estimate? In this talk, we‘ll look at the problem of estimating, as well as empirical data challenging the validity of story points. Can we find an accurate way of assessing the cost and duration of a project without estimating all our Stories? Come to learn how to do that!

Vasco Duarte

I want to transform product development organizations into product business organizations. I do that by focusing the work of the product development teams on the end-to-end life-cycle of their products.

The Red Bead Experiment

Targets, rewards, motivational speeches, ranking, individual bonuses, and even punishments, are to this day common management practices to get results from the workers. Are they effective in getting us to do better work? The world famous consultant Dr W Edwards Deming, who was “the man who taught the Japanese, America and many other countries about quality”, created The Red Bead Experiment in 1982 to communicate his take on the subject. In this session we will run a version of the experiment that has been slightly adapted for software development by David P. Joyce. The experiment introduces many of Deming’s ideas about management, the principles of variation and statistical process control charts. And it is a humorous and fun experience for both participants and audience! After the experiment there will be a presentation followed by a group discussions on the learning points and how they can be related to software development and the management of software development teams.

Joakim Sundén

Joakim is an Agile & Lean Coach with Avega Group, Sweden. He helps clients improve through coaching and mentoring of individuals, teams and organizations. This is often accomplished using Agile and Lean software development methodologies such as Scrum, XP and Kanban. When working as a developer coach Joakim favors Test Driven Development, refactoring and evolutionary object-oriented design, mainly on the .NET platform. He is an organizer of, and active participant in, conferences, networks and user groups in the Agile, Lean and .NET communities.

The Role of Management in Agile Through Real-life Stories

This session is an entertaining in-depth investigation into the role of management in Agile. At the start of this session we will define management in an Agile context. Then we will proceed through five real-life stories describing problematic situations ranging from teams to organizations. Each story begins with an organization diagram followed by perceived symptoms, root-causes and effects. For developers this session is an opportunity to understand the causes of some of the problems you face in your teams. and for managers this session is an opportunity to learn from mistakes done by others.

Ari Tanninen

Ari is a software guy who has practiced agile for about a half of his over ten-year career. He has done most jobs that exist in a typical software project, and has been around the industry long enough to know where to use agile and where not to. He is currently Head of Product Development at Intellipocket but still writes code for a living.

Using BDD to Make Clients Happy

Today, when good developers are as hard to find as honest politicians, we — the development teams — run the show. But increasingly, we're losing touch with the very thing that allows us to be successful. We're forgetting about how to make our (development) clients happy. More fundamentally, this means that we're losing touch with the end goal: to build products that have a high value, regardless of how they're developed. In this session i'll show you modern agile methodology called BDD and couple of accompanied tools, that will finally help you on the way to make well thought products.

Konstantin Kudryashov

Senior from-birth web developer. PHP, Symfony, Doctrine, node.js developer. BDD evangelist, QA perfectionist, Mac user, UNIX expert. And loving husband…