Was it Worth It? Measuring the Success of an Agility Project in Business Terms

Transforming a company that is working in “”traditional”” methodologies to “”Agile”” is expensive: management attention, overcoming change resistance, cost of consultants and time spent on re-education and training. Is it worth it? Measuring success in business terms is hard but may be crucial in management buy-in into executing an Agility project.

How will it improve the bottom lines? Can we expect more lines of code to be written by less developers? Can the success of an Agility project be somehow quantified?

This session looks at statistics gathered in my company – R&D, QA, Support, HR and Sales have all contributed their KPI graphs – to try and answer this question. I’ll be presenting some enlightening graphs of before and after a major Agility project that covered many aspects of the company operations. Trying to explain the change both in qualitative AND in quantitative measures. Hopefully, making a clear business case for going Agile.

1. Executive motivations in an Agility project
2. Short overview of the Agile path taken in Videobet/Playtech
3. Looking at statistics gathered in R&D, QA, Support, HR and Sales
4. Making the business case for Agility

Learning Outcome
a. Serve as an example for an executive level Agility project retrospective.
b. Can be used as a tool in management buy-in for a company-wide Agility project.

BIO: Ethan Ram is the chief architect of Videobet, the Tallinn division of Playtech, developing one of the most advanced gaming platforms in the gaming market. Among his recent project he has led the Agile transformation of Videobet development and operations groups to work in Scrum. The project started late last year and is now past its climax. Before Videobet Ethan was working as the R&D manager of a web-based gaming startup where he transformed the development group to work in Kanban with Continuous Deployment environment.

Too many ways to improve Scrum? Take them all!

Many teams, from small to large, not familiar with incremental and iterative delivery methods, struggle with getting started, keeping the momentum and focusing at the right things. Right tools and technologies can help!

A brief summary of organisational development tools for improving the implementation of Scrum, complemented with a few real-life use cases, where these tools have been used in different organisations – number of teams involved, characteristics, effects, outcomes etc

BIO: 18 years in the field of international software industry, from small to humongous-sized companies. I have collected a few excellent achievements over the years, combined them with many more how-not-to experiences. During the last five years I have been focused on building tools of organisational development to smoothen the merger of technology and business.

Building microservices with Esticade framework

Easiest way to get started with microservices.
How to start using benefits of microservices without worrying about REST APIs, port mapping, configuring endpoints and firewalls or service discovery. We explore the benefits and pitfalls of Esticade framework and show how to achieve scalability, reliability and optimal performance with Esticade (and microservices in general), with minimal time and effort.

BIO: Developer for more than ten years, have been working with many technologies and languages.

#NoComments /* about the worthlessness of comments in clean code */

What #NoEstimates is for agilists, #NoComments should be for all developers who <3 clean code!

Comments are – at best – a necessary evil” (Uncle Bob, “Clean Code”) – Over the years I gathered quite a collection of examples for bad code comments. The most precious gems among them I would like to share with you. You will listen in on developer monologues and dialogues, try to analyze cryptic bylines, experience different levels of UnCamelCasing(tm) skill and fight your way through a redundant, useless and misleading inline thicket. You will also hear about well-meant tools and plugins that should not even exist if the mantra #NoComments would be valued as it should be.

BIO: Björn Kimminich is working in the area of software development for Kuehne + Nagel for over 8 years where he is now responsible for Global IT Architecture. He is doing Clean Code trainings with Kuehne + Nagel’s globally distributed development staff since 2011. As a side job he lectures software development at the UAS Nordakademie where he teaches Java to engineering students as their first programming language.

My personal experience with innovation in product team

This is the story where I was against hacking in team but after 1 year became the innovation champ do push it across the company.
I got my new product and team who was willing to do hacking. As a product manager with full of backlog, delayed delivery and high pressure from managers I was against of any new distractions. But that how it started. After long journey and many complicated experiments we ended up with fantastic outcome. Lot of internal improvements, many new customer features in live and patent taken for one invention.

BIO: more than 20 years on IT field and last 6 years in Skype

Defining and executing a portfolio strategy

How to come up with a successful portfolio strategy and how to execute it?
How does a Chief Product Owner turn the company strategy into a portfolio strategy and build a suite of products and services to satisfy new and existing customers? What are some common pitfalls in aligning the organisational structure, governance, budgeting and legal issues and what to do about it?

In a perfect world everyone in our organisation knows what and why it should be achieved, has clarity around which decisions need to be made by whom and has the necessary competence, information, resources and authority to do it. Usually this is not the case. I will share practical examples, tools and models that I have used to help organisations make progress in executing their portfolio strategy.

The agile journey of Telia Estonia: experiments and discoveries

How to deal with 150 projects on a waiting list, if they are on the same level of importance and urgency? How to help business overcome the fear of building only small part of their grand vision? How to grow intrapreneurship in the hierarchic and matrix organization and support the people in their new roles?
In this talk you’ll hear what experiments we had, what we learned from these, where we failed and where we succeeded.

BIO: “I have 16 years of experience in software development, I’ve been a developer and a project manager. For 11 years, I’ve also been a lecturer in Tallinn University of Technology.
For the last 2,5 years I’ve been responsible for IT development process improvements in Telia Eesti. In my view, improvements in IT development cannot be enforced, they can only be sold out to the leaders, managers and teams. I think this can be done by a Lean-Agile evangelist who will train, mentor and coach people.
My favourite topics are: Lean thinking, principles and practices; startup mentality in the enterprise; agile Product Ownership and scoping (eg story mapping); DevOps & continuous delivery.”

BIO: Alek Kozlov Product Success Catalyst and Designer. I love to see how people uncover innovation by finding very simple and elegant solutions. But even more I love to see how these innovations help to understand and spin new business models.

From Tayloristic to Agile organization

What is common to Ford factories around 1900 and the collapse of Nokia Mobile Phones 2011? What leads most corporations towards Tayloristic organization? What is the other path to success?

“What is common to Ford factories a hundred years ago and Nokia about 20 years ago? In our session we explain the logic that takes the vast majority of leaders and corporations towards Tayloristic organization. We will also show the necessary and adequate changes to move from Tayloristic to Agile organization. Agile Adoptions tend to fall back to the old status quo. This happens for several reasons. First, a partial adoption introduces changes, which make the socio­techno­-economical system inconsistent and uneconomical. Second, partly because of the previous, the old status quo remains more comfortable for the individuals, and the new practices do not sustain. Third, the fundamental leadership assumptions have been cemented in the culture.
We will shed light on Taylorism versus Agile using several approaches: Ouchi’s theory of organizational control, Hackmann’s research on High­Performance Teams, Lean product development, Large­Scale Scrum, Complexity theory, history of Leadership, and our 20+ years of experience.”

BIO: After studying structural mechanics Ari built fault tolerant embedded real time systems for ten years. He has been full-­time organizational therapist since 1997. He has deep experience in organizational and group dynamics. He likes to explore and publish about patterns and unconscious phenomena in organizations. Ari is working with international Large­Scale Scrum (LeSS) adoptions, and contributing actively to the framework. In private life Ari listens to strange classical music (now playing), lifts iron, runs after the ball and tries to sit quietly in zen meditation.

Hear ye, hear ye – after a short break Agile Saturday is back and it’s almost here!

So clean your schedule for April 16th and see you at the Agile Saturday XII at Hotel Euroopa!

Register at Eventbrite

Creating Value with Software: A Blueprint for Continuous Experimentation

Finding the right scope for product development in order to build products that customers want is crucial for success. An important approach for steering development towards the right scope is to continuously conduct experiments. Insights from such experiments directly influence frequent iterative deliveries. Success cases from industry show that such an approach helps companies to gain competitive advantage by reducing uncertainties and rapidly finding product roadmaps that work. However, defining and conducting the right experiments can be challenging:

How can we identify the relevant questions we need to answer for making good product decisions? How can we find the right hypotheses to test? How can we define metrics that inform product decisions? How can we justify the efforts for experimentation? How can we link the experimental findings with product decisions and dynamically change a product roadmap? This talk answers the questions above and provides a step-by-step blueprint to put continuous experimentation into action.

BIO: Jürgen Münch is a Professor of Software Engineering at Reutlingen University, Germany, and a Research Director in the Department of Computer Science at the University of Helsinki, Finland. He specializes in software engineering, in particular data- and value-driven software development, product management, agile engineering, and innovation. Results are documented in five books and more than 150 refereed publications. Jürgen has been a principal investigator of numerous research and development projects. He regularly teaches product management courses and helps companies to develop innovation capabilities and new digitally-enabled products and services.

Register now to the next Agile Saturday  http://bit.ly/1Ybv3oK and see you already on the 16th of April!

Hello all Agile Saturday fans, friends and speakers!

We are glad to tell you that after a short break we are back! So book the date in your calendar (16th of April) and submit your abstract or several abstracts as the Call for Papers is now open!

We invite you to share your experience (good, bad and ugly) and submit an abstract or several abstracts to present on XII-th Agile Saturday in Tallinn, Estonia on 16th of April.

The Submission will close on the 17th of March.

If you have any questions don’t hesitate to ask – team@agile.ee.