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

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.

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.

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.

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.

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.

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.

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.

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)

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.

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.

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?

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.

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/

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.

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.

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!

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.

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.

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.