Notice: Use of undefined constant title - assumed 'title' in /home/abe/domains/ on line 13

Notice: Use of undefined constant ASC - assumed 'ASC' in /home/abe/domains/ on line 13

Session: Technical Excellence: Why does it not stick even now?

by Antti Kirjavainen

Presentation Slides

Technical excellence, meaning e.g. quality code, sound architecture, good test automation and coverage, continuous integration and continuous deployment, is the pre-requisite of sustainable software development. Sustainability of software development is essential for improving the Return On Investment and extending the life cycle of software products and services.

In my talk I will explain why the majority of organizations is still not making effective management decisions to ensure they get technical excellence.

I will argue that technical excellence is impossible to buy from a software vendor and impossible to enforce in contractual terms.

The other side to this subject is my second argument: the only way to ensure technical excellence is to have a skilled and motivated team that takes responsible of it, and giving that team the responsibility and means to ensure technical excellence

I will go over my personal experiences relating to management decisions regarding technical excellence and illustrate the thinking that is behind the ineffective decision-making related to technical excellence.

In conclusion, I will describe what kind of change of mindset is required for making effective management decisions regarding technical excellence.

Session: Five-Spice Scrum in Allegro Group

by Jakub Szczepanik agile transformation is quite well-known in polish agile community, being presented on several occasions during most important conferences throughout last year. But Allegro Group holds many more stories about agile transformation of different teams, developing different products. Each of those teams are working in their own specific context, which made their agile transformation unique. Kuba will present each “flavor” of those agile implementations and summarize all of them by creating a practical list of do’s and don’t’s in agile change initiatives.

Session: Keynote

by Jeff Sutherland


Session: Scrum Buts - and how to remove them

by Joy Kelsey

Presentation Slides

What I am going to be talking about are some of the scenarios I have come across whilst training or giving consultancy and even some scenarios within my own Scrum teams at some time or other over the last ten years or so.

We all get comfortable with what we are doing and maybe forget that it was hard to begin with so moving into something new can be daunting, if we struggle we tend to then fall back into old habits or what we were used to doing whether it was right or wrong, so what I will be doing is giving the ScrumBut then some suggestions on how to overcome them.

Please remember there is no right or wrong way for you to work in your Scrum teams and companies, I can only suggest or recommend doing it properly by following the Scrum Guide first and then adapting to what works for you, like anything Plan, Do, Check, Act.

Session: Keynote

by Jurgen Appelo


Session: Are we there yet? Or what a release plan is for

by Malcolm Peacock

Presentation Slides

One of the most frequently asked question by product owners and by passengers in your car is "are we there yet! or "when will I get my release?".

Looking at your release plan is like using the satallite navigation in your car. It provides some useful guides and helps you in decision making but does not guarantee you will get to your desired destination at the time origionally stated when setting out.

Obstacles such as roadworks, detours (both desirable and undesirable) can all influence when you arrive. You can increase speed and drop quality but the outcome isn't always as expected.

I want to discuss the use of the release plan in continually updating the Product owner and stakeholders much in the same way as you keep your passengers updated during a long car journey. I hope to provide you with a useful anology to help in those sometimes awkward conversations with the product owner.

Session: Planning for uncertainty

by Marcin Czenko

Presentation Slides

My last talk at the Agile By Example conference in 2012 was focused on sciences of uncertainty. One of the final conclusions was that we - developers, managers, everyone in the complexity business - may benefit a lot if we accept uncertainty rather than allocating enormous amounts of energy in trying to be certain, trying to be sure. One of the areas where the “certainty-virus” is especially harmful is planning. And even though a lot, if not everything, was already said about planning, looking at this important practice in the light of uncertainty may be very educative. Therefore, in this year’s talk I would like to focus on planning and its predictability. On the journey we will be dealing with the reasons for planning and estimating, the length of the product backlog, the length of the release, estimates in the sprint backlog, estimating defects and technical debt, to finally discuss what actually makes an estimate of a product backlog item. All these remembering that in the end, nothing can be certain...

Session: Building agile office with passion

by Marek Kirejczyk

As our company - El Passion - was growing, we realised that we're facing a number of new challenges. Rather then hire middle management and introduce new rules and regulations, we decided to build an office, that would solves many of those problems for us. We used lots of boards, many post-its and multiple visualisation techniques. Let me show around and explain what we did.

Session: Code review, do you speak it?

by Michał Ostruszka

It doesn't matter whether you work in in-office colocated team or you are part of fully distributed team, you still work on the same codebase together with your teammates. All of you should be familiar with the codebase, be aware of changes being introduced (to keep sneaky bugs away) and be able to take over work on any piece of project's code. There is pair programing you may say, but not all teams can afford that.

So code review to the rescue! I'd like to show you diffrent approaches to this process, how different teams do code reviews, what are common issues while doing code reviews (not only technical but also mental ones) and how to solve them. I'll describe how it relates to pair programming and what are benefits of doing code reviews for developers, managers and project as a whole. If you don't practice it yet, I'd like to try to convince you that this is great and powerful tool waiting for you to use. If you already do code reviews I hope you will learn some things that will help you to improve your existing process.

Session: Get agile and don't die trying

by Michał Prządka

Presentation Slides

I work in Millward Brown where I lead a small internal software house. In 2011, I decided to implement agile practices (mostly focused around scrum and kanban) in the team with no previous exposure to lean/agile. I imagined that this will be simple, quick and instantly gratifying and I was painfully wrong.

In my talk I want to share our exciting journey from the very beginning to where we are now. I will focus on failures rather than successes as I hope they carry much more value. Among other things, I will argue that:

You should not implement tools separately
You should not experiment without clear rules
You should not focus on pessimists
You should not be a “scrum nazi”
You should not use your process as an excuse
You should not underestimate the culture

and most importantly that:

You should not be afraid to fail (sometimes :) )

Session: My first five years with Kanban - harsh lessons on the quest for flow

by Paul Klipp

I was intrigued by the ideas presented in Mary and Tom Poppendieck’s wonderful book, Lean Software Development, which was published a decade ago, but it wasn’t until I came across the first articles describing the Kanban Method by David Anderson that I fully appreciated the practical implications of a lean approach to software development. In this presentation, I will share the lessons learned from my experience learning to work with Kanban on three very different projects. I will talk about adoption strategies, growing pains, implementation tips, and my teams’ current thinking about future ideas to further refine our processes

Session: Building Teams: We Got It All Wrong

by Pawel Brodzinski

Presentation Slides

Let’s talk for a while about how we build our teams. Best technical talent that we can find. Good engineering practices. Craftsmanship. Aren’t we full of that stuff? Oh yes, we are. Surprisingly enough that’s exactly the problem.

Last time I checked building software has been a team sport. So the question is: what does make a team effective? Once the question is answered we may want to rethink the ways we build our teams.

Session: Software Craftsmanship

by Sandro Mancuso

After over ten years since the Agile summit, software projects are still failing and developers are still behaving and being treated as factory workers. The software development industry is still very amateur when compared to other professions. How can we change this? Why Agile was not sufficient? Why so many clients are unhappy with their software projects? Why is it so difficult to find good developers? Our industry needs more professionalism and that’s what Software Craftsmanship brings to the table. In this talk Sandro will be explaining: what Software Craftsmanship really is, the value of technical practices, what it means to be a professional software developer and what to do to satisfy our customers.

Session: Agility is the Tool, not the Purpose

by Tom Gilb

Presentation Slides

The Agile Manifesto has its heart in the right place, I am only worried about its ‘mind’.

And its first principle “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”, is central to the ideas in this talk.

It is not strange that I agree, since many of the Agilistas, for example Kent Beck, explicitly point to my 1988 book as a source of some of their ideas.

My problem with agile is not in its ideals, but in the everyday teaching and practices we see.

What we see is the same problem that has been afflicting all software and IT projects long before agile appeared.

Our technocratic culture has forgotten our stakeholders and their values.

The practices are far too ‘programmer centric’, and far too little ‘stakeholder value’ centric. The result is that ‘working software’ is delivered to a ‘customer’.
However, necessary values are not necessarily, and all too rarely, delivered to all critical stakeholders.

Code has no value in itself. We can deliver bug-free code, that has little or none of the anticipated value.
We can deliver software functions, as defined in requirements, to the ‘customer’ – but totally fail to deliver critical value to many critical stakeholders.

Session: How I Became a Spaceship Commander

by Tomasz Borowski

Presentation Slides

I took part in the Agile by Example conference in 2011. It was then that a few speakers inspired me to undertake some specific actions within the area. So far I have managed to implement gamification in a 20-man Software Development House: Selleo. I can share my personal experience gained in the undertaking, especially what I have found out about the risks and benefits associated with workplace gamification.

Everyday at work we use myYouGame application. By sorting out their daily tasks and duties our developers (players) cooperate with each other to create human settlements in the most remote corners of the universe. The aim of this application is to grow engagement, promote best practices (e.g. proper task granulation, continuous progress updates, work planning and sharing the knowledge, etc.) and of course to add some fun to the workday.

My talk will be about the basics of gamification in working contexts and will feature a case study of a pragmatic implementation of the concept.

Session: Are we agile yet?

by Tomek Włodarek

Presentation Slides

These days agility becomes more and more recognized as essential to company's competitive standing. Agile championship moves from developers to managers and executives. Yet through the past years we, as community, did pretty good job preaching agility to developers, but we did rather lousy job explaining it to managers and executives. Resulting are rushed, half-baked agile adoptions. In this talk I will share some thoughts on how to make agility a solid, measurable enterprise goal, without compromising its empirical nature and without falling back to prescribed, overcomplicated processes.

Session: Stickies on the wall will not help you if you are building crappy software

by Wiktor Żołnowski

Presentation Slides

From very beginnings of Agile we are trying to improve IT organisation and make them “agile”. Many frameworks and methods like Scrum, XP, Kanban and finally Lean Startup have been created, so now we can use them to transform organisations into agile.

Unfortunately most of well known “Agile Gurus” are focused mostly on processes and tools like Scrum or Kanban. This methods became very popular so most of IT organisations try to implement them expecting great results. The true is that using Scrum without basic technical practices and knowledge will probably never be enough.

Stickies on the wall will not help you if you are building crappy software!

Agile is mostly about responding to changes, but many organisations still can’t respond to change fast enough. The problem is often in their products quality.

Yes! Your products also need to be Agile!

Building high quality products in contemporary software development means that you can respond to changes really fast all the time.

Product Agility is a possibility to introduce changes into your product in sustainable pace, every time when your customers or users need to change something. You can achieve it in many different ways but still there are some common practices which you should use.

Scrum, Kanban, Lean Startup became just another buzz words for Managers, so now they can play with them in their sandbox which has nothing in common with reality and day-to-day coding. The truth is that if you want to improve your software development process you need to remember about technical practices and code quality.

What about Agile/Scrum scalability? If you will look at organisations which achieve great results in this area you will probably notice that their products are scaled and decomposed into small sub-products. This is also good example of product agility.