Uncategorized

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.

 

 

Code DOJO

What is it?

Dojo is the Japanese term for “place of the way”, but it mostly describes a training place for
martial arts. For us, it is a training place to learn more about writing good quality code and
gaining tremendously valuable insights into the way other people solve problems.

Who is invited?

Code Dojo is open to everyone. Regardless of your skill level or your job description in
Outlook email signature, you are welcome. This includes junior testers, senior architects,
project managers, analysts, lead programmers so well versed in their craft that the only
challenge they have in their daily work is the tough decision which flavor of syrup to add
to their coffee on this particular morning, programmers yet to discover the joys of Extract
Method refactoring shortcut key and you. Especially you!

Why do it?

To become better, practice you must! Two hours in a Code Dojo will teach you far more than
a month grinding out one Model-View-Controller after another. Solving seemingly simple
problems in different ways and under different restrictions will challenge your mind, seeing
how other people steer their solutions to glorious victory through the rocky Red-Green-
Refactor cycles will broaden your own approach and improve your skills. You are guaranteed
to walk away with multiple invaluable insights.

How do we practice?

We will solve a kata, a simple programming challenge using Test-Driven Development
methods. You are free to come and practice alone. I strongly encourage you to bring a friend
or find a partner in the Dojo and work on the kata together as a pair. To make things even
more fun, we also try randori, free-style practice where multiple people line up to solve the
kata on a single computer. The first person writes a failing test, the second person makes the
failing test pass and then writes the next failing test before passing the turn to next person in
line.

I have never used Test-Driven Development. Can I still participate?

Yes! You should definitely come. If you are not familiar with TDD, you can try solve the kata
without it, but be warned, you will be missing out on a lot of fun. I recommend pairing up
with someone or taking a turn in the randori line when you think you have gotten the gist of
it. Test-Driven Development methods used in Code Dojo are very easy to learn.

Which programming languages do I have to use?

You can use any programming language you are familiar with. Unit testing frameworks exist
for most languages (Java = JUnit, C# = NUnit, JavaScript = Jasmine, Scala = ScalaTest, Ruby
= Test::Unit, etc.) and for nearly all of them IDE support is available. So you can write your
tests in your favourite programming language (or the one you want to practise) and run them
in your favorite development environment.

MVPs – how to build as much as needed and as little as possible

Building software that fulfills its true purpose can be easier than you expect. Most requirements are premature and are only validated by real-world feedback. The easiest way to solve any problem is to realize you don’t need to solve it at all.

The acronym MVP gets thrown around a lot, even outside the startup world. What does it really mean to build a minimum viable product? Does it mean we can sacrifice in quality? Join me on a hackathon to find out how much product we can ship in 45 minutes.

BIO: Peep leads one of the product engineering teams at TransferWise, constantly looking for ways to make life better for customers, the business, and engineers.

Agile is a bad strategy or 5 things every Agile practitioner should know about strategy.

Many people confuse strategy (the “what”) with operations (the “how”) and as a result spend time spinning their wheels without getting anywhere. Actually Agile is not a strategy at all, its an ongoing operational priority.
Agile might help you get to your destination faster, but if the destination is wrong the last thing we need is to get there sooner.

Sometimes business executives or customers come to us with vague images that are short on the what and why and rich on the how. Company strategy, product strategy, Agile strategy, strategic agility, key growth strategy, business strategy. Strategy this and strategy that. In order to help them and yourself you need to think at a higher level of abstraction.

Come and find out what strategy is and how to implement it. As a result you will know how to think strategically and help executives do the same.

Teaching young hackers

I bet we all started with games, mods and trying to make the environment around us cool/fun/interesting. Now we are going to schools and trying to make everybody learn “programming” – this trend must stop NOW. What are the cool activities that might require IT skills – from solving puzzles to building robots & better paper airplanes? And how to turn these activities into “formats” that can become viral among teachers and students? Peeter has been speaking to teachers after helping to localize some Codecademy courses and would like to bridge the gap.

BIO: Peeter might have been the first in Estonia to talk about agile in mainstream media – back in 2005. Likes blending together code, design & usability, but could be best in selling really expensive stuff to very large clients. With vision. Is often feeling depressed (and unemployed) by the fact, that he has never had a chance to work in real development.

Introduction to SAFe (Scaled Agile Framework) – Good, Bad, Ugly

You can find in the Internet a lot of voices raving against this approach, as a try to commercialize Agile.

On the other side a lot of big companies are very into this model and they find it very helpful in understanding how one Agile Company should be structured.

I have reviewed SAFe model and in my session I will share pluses and minuses that I have found in it. Overall I satisfied with they way how Dean Leffingwell been systemized the “”How”” one enterprise can work in agile setting. I have some smaller concerns to share with you and, in my humble opinion, one big architectural flaw that should be changed/addressed.

Come and discuss these topics with me and take away understanding about how does this model can be used in your settings.

Typescript sugar with nuts 

You will learn how to write compile time safe JavaScript code and be confident in it. In TypeScript you can use classes, enumerations, modules, describe nested structures and still be able to use dynamic nature of JavaScript And the most attractive is that you do not have to learn new language!
The world where you come from, does not matter: Java, .NET, PHP, Ruby… TypeScript is friendly with everyone and all popular IDE-s support that.

Introduction: what, when by whom, strongest “selling” parts of TS.
About me.
What project did I remake to use TS language.
What are the problems with JS?
TypeScript can be just JavaScript.
Demo: How to start using TS in VisualStudio.
Demo: Remaking small JS code piece to TS code and benefits.(VS)
Other IDE-s supporting TS.
How to set-up TS support in JetBrains WebStorm.
Small comparison with other frameworks which compile to JS.
TypeScript pluses.
Compiler is open source.
Some theoretical dive into TS constructions. (I will reduce the amount comparing to DevClub)
Demo: Generics
Demo: External type definitions
Demo: WebEssentials. The same in NodeJS by it’s nature.
Small demo: tricks with Any and Structural Typing by mocking function, object and constructor.
Resources.
Questions.”

 

BIO: From childhood had three passions: physics, IT and theatre. Got good results in state physics contest. For a long time played in amateur theatre before and after university.
Studied Physical Information Technology and Applied Physics in Tartu University. Now studying Computer Systems in Tallinn University of Technology.
Working in IT almost 10 years. Started from test automation and now trying to do everything as senior developer in Fits.me.
Physicists need to explore and see picture of nature very thoroughly to do conclusions. I think the same approach should be in IT industry.

Agile pitfalls in large organizations, how to not fail the programs

You will gain insight into more common pitfalls and learnings from running large architectural programs in agile environment and how to make them successful from company perspective.

Session will give an insight to the practical side of running a large programs in agile environments.

– How to manage the expectations of stakeholders, set achievable goals and deliver real products in predictable time-frame.
– Difficulties in defining the business value, making it clear and understandable for everyone.
– Role of a product owner in this environment and requirements for other roles.
– Avoiding duplication of work and making sure that the time is spent in the right place.

The talk is based on the real life experience in running the programs that have involved around 100 developers and multiple scrum teams.

 

BIO: Currently on a VP of Engineering position in Fortumo, one of Estonian companies offering mobile and micro-payments in the world around 80 countries.

Previously have been working as a project manager in EMT working on the data services and actively involved in introduction of early mobile portals, MMS and some other services to Estonian market.

After that have been working for 8.5 years in Skype, actively been involved in project and program management, also participating heavily in introduction of agile methods to Skype and running very large programs in Agile environment.

The Soul of a Developer

List of subjects discussed in no particular order:

– The soul of a developer – what sort of people common developers are.
– Way of thinking – binary logic.
– Introversion
– Attention disorders
– Laziness
– Teamwork
– Rivalry
– Trust
– Management communication barrier
– Motivation
– Developer burnout

BIO: Software developer in various companies for over 10 years. Worked in both agile and waterfall companies. Doing hobby projects in various areas of programming and computer arts.

 

I stumbled upon a blog of Dave Thomas, a signer of the Agile Manifestor, where he very reasonably complains about the misuse of the word “agile” and misuse of the whole concept.

According to him, here is what it is all about:

What to do:

Find out where you are
Take a small step towards your goal
Adjust your understanding based on what you learned
Repeat

How to do it:

When faced with two of more alternatives that deliver roughly the same value, take the path that makes future change easier.

A good read:
http://pragdave.me/blog/2014/03/04/time-to-kill-agile/

Introduction to 3D Graphics in your web browser with three.js

Browser technology has made a huge leap in past few years. It wasn’t long ago when web was mostly text with some pictures and hyperlinks, but now most internet sites we visit are built as massive client side applications with the browser doing as much work as the server.

Only recently it also became possible to do actual full blown, GPU accelerated 3D graphics using merely the browser. The new technology, called WebGL, makes it possible to create stunning games, business graphics or real estate presentations among other things, which work on many operating systems, devices and browsers without the need to install any extra plugins or extensions.

Only problem with WebGL is the fact it is a low level API and although extremely flexible, it requires quite a commitment to get started with. Fortunately, it didn’t take long for high level APIs to pop up, one of which, Three.js, we are investigating. One thing is for sure: it has never been quite that easy to get into the world of interactive 3D.

What exactly is GPU accelerated 3D? How it works? How to get started with it? How to use agile methods for developing your next sparkling 3D project? These and hopefully many other questions will be answered during the presentation.

Test Driven Development: An Essential Practice To Go Fast

Test Driven Development is a software development process that relies on short cycles of writing test code and making the tests pass by writing production code. I will give an overview of TDD and talk about my own experience using TDD.

We will talk about the reasons why development teams slow down over time, and how that process can be prevented by a comprehensive suite of tests. We will discuss the three laws of Test Driven Development – the central discipline of TDD, and the benefits of following these rules: increased quality, reliable low level documentation, decoupled design, and no fear of change.

Using and abusing metrics for improvement on personal, team and company level

Understanding how to use and abuse metrics, charts, KPIs and indicators for personal, team and organisational improvement. Why would I want to have measures or metrics for anything in the first place and how do they work in an organisational context? How can a metric be more than just a tool for a command and control styled management and help us in improvement?

Mashing up customers, users, product and business

Finding a product that people want to buy and use is common problem in software product development.

I will present a “how-to” for achieving viable software product business by combining Customer Development, Lean Startup, Business Model Generation, User-Centered Design and Agile software development.

Bio:
Marko has co-founded two companies, built concepts from idea to product, sold IPRs, coached AaltoES startups and been executive advisor for Finnish Deloitte TOP10 growth companies. He has applied Lean Startup in both product and service innovation context and has done several public speaking appearances regarding lean, agile and product development. Currently Marko is a partner at Gosei and helps companies to become better

Continuous Deployment – Fact or Fiction?

In this session I’ll describe my experience with making the biggest Agile “leap” in a consumer facing web application: From releasing a product version once every 2 months to releasing a version every other day – what does it take to make the release cycle totally Agile?
Agenda

• Why Continuous Deployment
• Setting the goals
• Development using Kanban workflows
• Some critical development technics
• Making the leap
• Some unexpected results that came out of the change
• Q&A

Challenges of implementing SCRUM in a large scale public sector project

Estonian Employment Information System (EMPIS) is one of Nortals largest development projects and the biggest in Public Sector Business Unit. Alar Huul will talk about the mistakes they made and challenges they faced in turning the development team of 20 specialist and the Product Owner agile.

Practicing Advanced Unit Testing with the TCG Kata

Doing Code Katas alone or in a Dojo can help sharpen our elementary skills as software developers. Practicing IDE shortcuts and TDD mini-step cycles is very useful for the daily business, yet I find some existing Code Katas too far away from real-life programming situations. That’s why I came up with the Trading Card Game Kata – which is (very loosely) based on Blizzard Entertainment’s free-to-play online-game “Hearthstone – Heroes of Warcraft”. This Kata is focused on practicing TDD in a slightly more complex (but not complicated) situation where you might have to think about rules like Single Responsibility Principle or Command Query Separation and might even feel the urge to use a Mocking framework at some point.

First I will introduce the ideas of Katas and Dojos in general and explain the TCG Kata rules to you. Then I will demo some real-life best-practices for writing good developer tests, using my TCG Kata sample solution as a showcase. This will include:

• Picking the right Test Double
• Test Data Builders
• Behavior Tests with BDDMockito
• Prose-like Assertions with Hamcrest
• Readability Sugar

PS: In the meanwhile, if anybody’s up for a little duel in the original Hearthstone, here’s my Battle.net tag on the EU server: koshiii#2720! 🙂

Toyota Kata – habits for continuous learning and improvements

“We are what we repeatedly do. Excellence, then, is not an act, but a habit.” – Aristotle

What are the habits, routines, behavior patterns, needed to strive for excellence every day? How do we create a culture of continuous learning and improvement?

Building on the power of habits, Toyota Kata will help you build a culture of continuous learning and improvement, a kaizen culture.

In this session, you will be introduced to the two main Kata* of the Toyota Kata, the Improvement Kata and Coaching Kata. You will learn how the Improvement Kata and Coaching Kata can become your “muscle memory” for continuous learning and improvements in your organization. These daily habits or routines will help you to strive towards your vision, your state of awesomeness, in small experiments focused on learning. The Improvement Kata will form the habits of doing small daily experiments focused on learning and improving. The Coaching Kata will form the habits of the leaders of the organization to help the learners learn and improve.

In this session, we will take Toyota Kata out of the manufacturing context and put it into the knowledge work context. You will learn how you can start applying the Improvement Kata and Coaching Kata in a software development context tomorrow.

Time to stop collecting problems and start forming new habits of learning and improving!

(*) Kata means pattern, routine, habits or way of doing things. Kata is about creating a fast “muscle memory” of how to take action instantaneously in a situation without having to go through a slower logical procedure. A Kata is something that you practice over and over striving for perfection. If the Kata itself is relative static, the content of the Kata, as we execute it is modified based on the situation and context in real-time as it happens. A Kata as different from a routine in that it contains a continuous self-renewal process.

Bio:
Håkan Forss is a Lean/Agile Coach, public speaker and author. He coaches, mentors and teaches Lean/Agile thinking, methods and tools to organizations, teams and individuals. He develops people’s ability to continuous learn and improve how work is done.

Håkan is an active member of the Kanban, Lean and Agile communities. He is an Accredited Kanban Trainer (AKT), a Kanban Coaching Professional (KCP) and he serves in the Kanban Coaching Professional Advisory board. He was also nominated for the Brickell Key Award 2013.

You can find Håkans random thoughts and thinking at http://twitter.com/hakanforss  and http://hakanforss.wordpress.com