Clients come to us with an idea for a product and they always ask the questions - how long will it take and how much will it cost us to deliver? They need a delivery date and a budget estimate.
I will show how to use Monte Carlo simulation for predicting the delivery time for your next project.
I will go pretty quickly through the slides and focus on how to simulate project delivery time using Monte Carlo simulation in MS Excel.
The method presented can be used by any team that uses user stories for planning and tracking project execution no matter the development process used (Scrum, XP, kanban systems).

(Everyone is welcome to leave a comment on this submission! Click on headline to do so)

There is a lot of attention given to Lean/ Agile product development teams around the work done and the (Lean/ Agile) processes adopted in by the Dev team once a set of features (backlog items) have been identified for a set of sprints (scrums) and/ or Releases.

However, how do those features get to the team, nicely bunched up in Releases and Sprints? There is a lot of upstream effort by Product Management that goes in 'herding the cats' - defining and maintaining the Product Roadmap with input from myriad and often conflicting sources, abstracting features and requirements at the right level, getting stakeholders to agree on their priority, and then decomposing them so that the Dev teams are continually churning out quality code and product features in a 'just-in-time' manner.  The work that the Product Management team does is at a different cadence than the Dev team.  Most organizations and teams have not yet understood the criticality of managing this upstream work well, nor the effort that needs to be put in so that the Dev team is continually supplied with User Stories at the right time and stakeholders are satisfied the right work is being done at the right time.

This talk focuses on this challenge and describes what we have done as a small product company, where managing the Product Roadmap and successful delivery of releases is critical; and how we have improved over the last 30 months since we adopted Kanban in our own Product Development organization, with specific focus on synchronizing work upstream and downstream for a unified flow.

(Everyone is welcome to leave a comment on this submission! Click on headline to do so)

Slack or free time, also known as Google 20% or Fedex Day, is an essential ingredient for improvement and innovation.

But how to introduce slack in an environment where resource usage is a main KPI and managers measure progress by the amount delivered features?

Slack can result in a lot of positive effects but slack is not for free. But it is clear: successful organizations use slack.
I was inspired for this presentation by a blog article from David J. Anderson. The more I talk about slack with teams or on conferences, the more I see that we still have too less of it. And often it is either sacrificed or used ineffectively.

(Everyone is welcome to leave a comment on this submission! Click on headline to do so)

Kanban is a change management method and without reflecting how we work and what we work on, change will be random, inexistent, or even towards worse.
But why teams forget to retrospect? Why do they postpone retrospectives? From consulting and coaching more than 20 teams, I discovered some patterns I want to share with the audience.
Here one example: Improvement task identified in the retrospective are put into the product backlog. There, they remain forever. What a frustration for the team: they identified an issue, found a solution, agreed on the importance but they don’t work immediately on it. Why then wasting time in  retrospectives?
Talking to the teams, sometimes providing a refresh of some agile basics, most of the teams started thinking about how they want to reestablish a reflecting culture.

(Everyone is welcome to leave a comment on this submission! Click on headline to do so)

The United Internet AG and the incorporated firms (like e.g. 1&1) have almost 7.000 employees in more than x countries.
About 2.000 employees are working in development, operations, and data centers. They are mainly located in offices in Karlsruhe, Munich, Montabaur, Berlin (Germany), Bucharest (Romania), US, UK, and Spain.
Since three years, we are constantly working on creating and maintaining a network or community of all interested in agile. Currently, we have identified more than 200 colleagues.
One impression: Twice a year, in spring and in autumn, we organize a two day internal conference, 1&1 Project/Agile/Scrum/Kanban Days. In March, on our 5th event, we had over 120 attendees, 15 sessions, 12 open spaces, 3 Pecha Kuchas. Feedback: This conference can compete with payed conferences!
In my presentation, I want to explain what we started, what we stopped, what we continue and what is still in our idea backlog. One secret I already can reveal: It is really challenging…

(Everyone is welcome to leave a comment on this submission! Click on headline to do so)

In LKNA14, Keren Yahalom and I  told the story of implementing Kanban in the amdocs delivery organization where in a year and a half we implemented kanban in ~30 projects with over 1500 people.
In this talk we would like to tell about our coaching experiences: The good, the bad and the ugly.
Throughout the implementation experience our 10 people implementation team was in contact with around 300 managers in various levels. we will give examples for good experiences, for challenging experiences and for experiences that we were at a loss with.

(Everyone is welcome to leave a comment on this submission! Click on headline to do so)

Writing code is fun: It’s great to build something that works. But more so, it is very satisfying to create a software product that does a great job for the users and customers and fulfil its business goals. But who are the customers and users? What problem does the software address or which benefit does it provide? What are the business goals? I find that many teams struggle to answer these fundamental questions running the risk of creating software that is not very useful or fun to use.

This talk introduces a simple tool - the Vision Board - that helps you write software that is beneficial and desirable.

(Everyone is welcome to leave a comment on this submission! Click on headline to do so)