Let's gather, share our experience and learn together! We will be glad if you join us on May 23, 2015. Let's use this day for peer-to-peer learning, collaboration and creativity. We invite you to join and share your insights and feelings, discuss the questions you care about.

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.

Top 50 Agile Conferences of 2014

Yes, we're in the top 50 and we want to keep and improve our place there. That means that we try our best to deliver the spirit of learning and knowledge sharing to our audience.

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.

Accenture is a global management consulting, technology services and outsourcing company, with more than 281,000 people serving clients in more than 120 countries. Combining unparalleled experience, comprehensive capabilities across all industries and business functions, and extensive research on the world’s most successful companies, Accenture collaborates with clients to help them become high-performance businesses and governments.

Become part of something bigger than you alone. With over 375,000 members worldwide, Scrum Alliance brings you together with like-minded people who are passionate about Scrum and who are changing the world of work every day. We are a nonprofit membership organization that encourages and supports the widespread adoption and effective practice of Scrum. We provide advocacy, community, and education to support this movement, equip our members, and help them succeed with Scrum in software development and beyond. Learn more at www.ScrumAlliance.org and come sprint with us!

Why We Fail to Change? (10:15 - 11:00; Big Hall)

Improvement initiatives are like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it. For decades most of improvement programs fail. Interestingly enough, with the rise of Agile and Lean the success rates of change initiatives don’t get better. Why so? Every now and then we focus on processes and methods. We exploit success stories from other organizations just to find ourselves failing again. Should it be a surprise given how little attention we pay to our specific context? Should it be a surprise given bias toward methods and tools at cost of mindset? Let me discuss some of methods we use to drive improvements. My goal is to show you that most of the time you shouldn’t even bother to use them. The missing bit is almost never a tool or a method. This is going to be sort of myth busting. We need that to change our focus to the important bits: right mindset and understanding the context.

Agile Metrics – what is really needed and makes sense in order to steer a large agile project (11:15 - 12:00; Big Hall)

This talk introduces a minimal set of agile metrics for agile project management beyond the known ones as e.g. Velocity and Sprint Burndowns. We will talk about how these metrics are defined and how they are visualized while looking at some example scenarios. The presented agile metrics are also the standard set, which Accenture as a world-wide IT service provider uses in his large-scale agile projects.

Agile Innovation - Why people matters (12:15 - 13:00; Big Hall)

Many companies and governments today are trying to encourage innovation and new ideas within their organizations but the results are often poor or at least not good enough. Why is that and why do we need to have the human perspective to be successful? How should we act and think before we start a project around innovation or a big change?

Why to become a Project Manager? Why I did? (14:00 - 14:30; Room 2)

My passion changed from Programming to Project Management. I am board member at International Project Management Association Latvia since 2001, am assessor and give classes also on Program and Portfolio Management. I hear many stories of people who somehow found their 'ways to a project management profession'. Let me share the best ones! Set of persona-based stories that could help programmers and people in other roles to better understand if Project Managers job is good for them or not by looking how other people got there. For each case pros and cons are analysed. I was influenced by reading some of Adizes' books.

What is a Scrum Master? (14:00 - 14:30; Room 1)

This presentation will look into a Scrum Master role as proposed by the Scrum framework. At first - role's essentials in Scrum and shortly its similarities with identical roles in other methods, then overview of this role's different interpretations across the industry and my own experience in that. Why this topic? Scrum Master is a central role in an environment that wants to become Agile. While in the first place Scrum Master is serving a team, he or she is also serving an organization. Scrum Master is a soft role more than a hard one (like developer) and therefore includes coaching too. In my experience and research, above aspects are often under-estimated, which have significant impact on the overall work productivity of an organization that adopts or has adopted Agile. I would like to try clearing things out around this role together with you in ADR 2015!

Agile and a Cookbook (14:30 - 15:00; Room 2)

Let's look briefly at ideas behind agile. As well, at a bit of history when these ideas appeared and how they evolved. It allows us to see what do we do ourselves in a different perspective. Agile approach has a lot in common with far more mature scientific development. Let's look at what scientists do? Observe a process, get an idea and check it. What is next? Observe, renew the idea and check it again. What is next? Observe, renew the idea and check it again. What is next? Observe and try do figure out something essential of the process. Usually it is called a hypothesis and an experiment and the development tends to be their sequence.

Technical... user stories?! (14:30 - 15:00; Room 1)

User stories are supposed to reflect the 'human' side of the IT. The should be easy to understand and not too technical. Ok, but what should happen when you're asked to prepare user stories for strictly technical projects/products? Agenda: 1. Understanding target audiences. 2. Understanding scope. 3. Use or not to use user stories -> scope management. 4. Fitting the requirements to 'user stories' oriented tools.

Software architecture also needs Agile (15:30 - 16:00; Room 1)

Software architecture is a vital part of the project development life cycle. Done explicitly by a software architect or implicitly in the head of a developer, it has an important role in the whole process. Changes in the requirements, vague definitions, and poor documentation, however, are some of the usual problems software architects encounter. On the other hand Agile methodology gives us ideas how to deal with these problems. Iterations, meetings, and early evaluations are some of the proposed techniques. Can one apply Agile in the context of software architecture? How can a software architect react on specification changes? How can we keep up-to-date documentation of our system? In this talk I will try to give answers to these questions based on my experience and I will do a short demo to illustrate a real scenario.

Agile in context of Latvian Public Procurement Law (15:15 - 16:00; Room 2)

Public Procurement Law sets several constraints for tendering process and delivery of information technology projects. Additional controls may be required depending on project funding i.e. European Regional Development Fund or other. The discussion is aimed for managers, consultants and lawyers being in charge for software development process from both sides - state agencies and software development companies. We assume that participants are familiar with general Agile principles, 'Agile Contracts Primer' http://www.agilecontracts.org/ and requirements of Public Procurement Law however it is not strict requirement and everybody is welcome.

Being Agile to Become Customer Centric (16:30 - 17:15; Big Hall)

The first principle of Agile manifesto says 'Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.' But, Is our highest priority to delight our customer, or to delight our sponsor. Do we understand who the real customer is and behave accordingly? I’ve often seen Agile teams producing software aimed to delight: another departments within their organization, an external organization hiring their development services, their management or even their Product Owners. But, are those the ones to be delighted by the product in development? I believe that software is awesome when it helps creating awesome experiences to the people the organization is serving. To create those delighting experiences is very important to understand who your real customer is and empathize with him. This session is aimed to create that awareness and to introduce some practical tools that can help creating a 'Customer Centric' Agile implementation and culture in organizations. I will start the session by explaining what is customer centricity and how it can become the competitive advantage of your business and a powerful reason for adopting Agile. I'll continue with simple tips, and practical examples, which attendees can incorporate into your Agile implementation to empower customer delighting. Such as including “moments of truth” in “Personas” and going from 'User Stories' to 'Customer Stories' The listener will get from this session easy-to-apply tools to equip their Agile implementation an extra focus on their real customer to maximize customer satisfaction and create an important foundation for the buy-in of Agile by the business.

No Estimates: Let's Explore the Possibilities (17:30 - 18:30; Big Hall)

'The only sure thing about forecasts is that they are WRONG' - James P. Womack and Daniel T. Jones. Estimates have been the bane of software development and programmers for decades. Managers/Customers want to know: When will it be done? How much will it cost? Programmers are told 'We won't hold you to the estimate', and yet they often are. It's my contention that estimates are not useful for this purpose, and even worse they misinform the decisions they are meant to support. Do we really need estimates? Is simply 'getting better' at estimates worthwhile? Can we live without them? Will things be better without them? I don't have answers for you, but I've worked with 'no estimates' for over 4 years and I'm still alive. I want to explore the idea of estimates, why they are pervasive in the programming world, how they might be harmful, and see if we can start a dialog about finding a better way to make decisions.