Scaling Agile is the hot trend these days. There are various options people are currently using to scale agile across their organization ranging from the trendy SAFe through the evolutionary Kanban all the way to classic LeSS. As an enterprise agile coach with straddling both the Kanban and SAFe worlds with experience helping various global enterprises to be more agile at scale I have a wide perspective of the agile scaling approaches landscape which I will share in this session. Together we will look at the various leading approaches to Scaling and understand how they compare, where each is appropriate, how to mix and match them. We will also spend some time discussing change management/implementation aspects of using the  the various approaches and how to move through the selection, kickoff, stabilization and recharge phases and ideally move to improve mode at some point. 

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.

ScrumBan is a hybrid Lean/Agile approach combining Scrum and Kanban. It combines the team-focused rhythmic nature of the Scrum Framework with the Lean/Flow focus of Kanban to create a winning combination. This session provides attendees with sufficient knowledge about Scrum, Kanban and Scrumban to decide whether they want to pursue ScrumBan as the next step of their agile journey

In fall 2014 there is no question that business agility is required. You will also be hard pressed to find anyone arguing against the core principles of lean/agility or against most of the practices. But most enterprise organizations have not yet reached the levels of agility you read about in books or hear about at conferences. Lean/Agile is now trying to cross the chasm into the mainstream enterprises where effective change management for today’s context is the name of the game. Through stories from the trenches of enterprise change management we will discuss different approaches to change and when each is appropriate. We will see how a combination of the Kanban evolutionary approach to change combined with "free market / pull based change management" helps accelerate the journey towards agility without risking its stickiness, and share some hard-learned lessons that resulted in patterns like “Manager’s first”, “Document/Methodology later”, “Market & wait for Pull”, “Case Study”, “Opt-in vs Mandate”, “Guidebooks OVER guided tours”. 

Every Company is trying to surpass its Competitors in this ever changing World.  Today, World is changing so fast, that every company needs to Iterate faster after reading the Customers’ insights. The transition happened from the Industrial Age to the Waterfall Age. The Waterfall resolved the concerns to an extent; however, it laid the foundation for a new set of issues. Then the focus shifted to RUP, Spiral, V models and finally to Scrum, XP, Lean, Kanban, Scaling Agile, etc. 

However, no framework or methodology can solve the concerns without having a Good Engineering Culture.  The Culture undoubtedly consists of People and the surrounding Processes & Practices to help them (& not act as Blockers) to achieve the ever changing Definition of Success.

In this context, this talk will emphasize to shift our focus from the Leadership-Powerpoint Slides to our Engineering Culture. It will highlight the Problems and an attempt to answer the same by taking good case studies of Companies like Spotify, 3M, etc. We will talk about philosophies like M3.0, Holocracy, Tribal Leadership, etc and Engineering practices like Pair Programming, Continuous Integration, etc. We will also focus on the Roles of PO, SM, Developers, UX and the Leadership to shift to better Engineering Culture for the overall success of the Employees, Teams, Products and the Company on the whole.

Ina a nutshell, this talk underlines the importance of Alignment of Leadership’s Vision with Actual-on-the-ground Engineering Culture to achieve a Win-Win situation.

Thanks,

Gurpreet

The transition of Waterfall to Agile methodologies is never easy. The Waterfall approach consisted of these documents as a way to analyze the User needs: BRD (Business Requirement Documents), FRSs (Functional Requirement Specifications), SRS (Software Requirement Specifications), PRDs (Product Requirement Documents), etc. After the initial agreements, the development starts. In Scrum, the most important artifact to map User needs is the User Story. However, sometimes, the User Story is too big or too small or too abstract or never ending. This often lands the teams in difficult situations. So, it is vey crucial to Identify the Ideal Bite Size -- to identify the ideal size of our User Stories, yet keeping these Effective!

Introduction
------------

Continuous Deployment is the natural evolution of continuous integration and delivery. It is the ultimate culmination of software craftsmanship. Our skills need to be on such a high level that we have a confidence to continuously and automatically deploy our software to production.

We usually start with continuous integration with software being built and tests executed on every commit. As we get better with the process we proceed towards continuous delivery with process and, especially tests, so well done that we have the confidence that any version of the software that passed all validations can be deployed to production. We can release the software any time we want with a click of a button. Continuous deployment is accomplished when we get rid of that button and deploy every "green" build to production.

We'll try to explore the goals of the final stage of continuous deployment, the deployment itself. We'll assume that static analysis is being performed, unit, functional and stress tests are being run, test code coverage is high enough and that we have the confidence that our software is performing as expected after every commit.

The goals of deployment process that we should aim for are:

* Run often
* Be automatic
* Be fast
* Provide zero-downtime
* Provide ability to rollback

**Deploy Often**

We'll try to explore why it is important to deploy often. What are the pros and cons deploying on every commit instead once a month or few times a year? What are the prerequisites for successful deployment?

**Automate everything**

Why automation? What are the pros and cons of provisioning tools like Chef and Puppet? What are containers (e.g. Docker) and how do they help? Do we need provisioning tools if we adopt containers?

**Be fast**

Speed is the key. Can we deploy often if the process is not fast? What is the relation between fast deployments and time-to-market? What is the acceptable deployment duration?

**Zero-downtime**

We cannot deploy often without zero-downtime. If there is any downtime during deployment, it will be multiplied with the number of deploys we do. We'll go through one blue-green deployment as one possible way to accomplish zero-downtime.

**Ability to rollback**

Unexpected happens sooner or later and the ability to rollback is a must. How can we accomplish automated, fast and reliable rollback? What are the major obstacles?

Deployment Strategies
---------------------

We'll explore different strategies to deploy software. This session will in no way provide an exhaustive list of ways to deploy applications but will try to discuss few common ways that are in use today.

Each of the strategies presented is based on practical experience and each of them created a different set of issues. We'll go through both concepts behind those strategies and specific issues we faced when implementing them.

**Mutable monster server**

We are used to build and deploy big mutable applications. That's how we did it during most of the short history of software industry. What are pros and cons of "mutable monster server"? Can we deploy it often with zero-downtime and easily rollback? Is automation of such a server the way to go? Can it be fast? Are there any alternatives?

**Immutable servers**

What are immutable servers? How can we deploy them? What is blue-green deployment in the context of immutable servers? What are the benefits?

**Immutable microservices**

What are microservices? Why do they fit perfectly into the concept of immutable servers?

Summary

-------

Continuous deployment sounds to many as too risky or even impossible. Whether it's risky depends on the architecture of software we're building. As a general rule, splitting application into smaller independent elements helps a lot. Microservices is the way to go if possible. Risks aside, in many cases there is no business reason or willingness to adopt continuous delivery. Still, software can be continuously deployed to test servers thus becoming continuous delivery. No matter whether we are doing continuous deployment, delivery, integration or none of those, having automatic and fast deployment with zero downtime and the ability to rollback provides great benefits. If for no other reason, because it frees us to do more productive and beneficial tasks. We should design and code our software and let machines do the rest for us.

We know that agile methodologies work at the team level, and there is now even an effort to scale into whole organizations. 

There is a clear reason behind this: we found ways to improve performance, by analyzing situations better, and making better decision. Every organization wants to apply this in every level. Like in the late 90s, new ideas are coming out that challenge the way we think, and this time they don't just answer development. Ideas like Beyond Budgeting, Lean Startup, Cynefin, Real Options, Feature Injection, SAFe, Design Thinking, #NoEstimates, Cost of Delay and others are spreading out, and while we know not all will last, you never know which might fit your situation.

In this session, I'll give a summary of what's hot around the agile world, with some criticism and application in the real world. 14 years after the original manifesto, organizations start to experiment again. I always wished I was there when the first conversations took place. I encourage you to join in on current conversations. Let's start.

You’re in that zen mode, ready to go into designing code with tests. You know all about emerging design, your mind is empty, and off you go.

But wait.

What scenario do you pick to start with? How do you translate not-so-specific requirements into example tests? What happens when you run out of examples? Do you ever get back to the first requirement, or skip between tests as more bright ideas flash into your mind?

Over the years, I’ve discovered patterns I use in TDD. From improving names, mutating tests to create more examples, picking scenarios and differentiating them from their siblings. I’ve noticed others doing them too.

In this session, I’m going to tell you about my experience, and what methods are effective for me. I’m going to show examples, explain the thought process, and tricks that help me along the way.

This workshop will help your team in improving their trust relationships and gaining a deep understanding of trustworthiness.

Learn to use the Team Trust Canvas methodology to strengthen your team performance. During the workshop, participants will learn which factors are essential for trust and how to use this new capacity to create an environment that brings the best of people.  The content is very practical. Most time of the day participants will do hands-on step-by-step exercises with the differents tools and games.  You’ll be able to use those right away when you go back to work.

Software projects are notoriously complex making them hard to successfully manage. Or are they?

In this talk I will demonstrate, through the Cynefin framework of Complex Adaptive Systems, what makes projects complex, what common strategies lead them to failure, and how to increase early and frequent decision making that promotes either an early termination of a failing project, or a successful ending.

We come with the best intentions, go to workshops and conferences, get the best coaches, and then when we look at our process what we find is a classic Waterfall!

What happens between the time we decide to go Agile until we discover that we find ourselves in the same old patterns, just calling it Agile?

In the first part of the talk I will present some of the familiar patterns that "help" us re-implement the same process in other names.

In the second part I will share some tips to make a change that sustains agility.

During the talk I will share success and failure stories of my own and of others.

This talk is intended for managers and manager-wannabes who wish to implement an Agile transition that, unlike Waterfall, holds water.

After revolutionizing the automobile industry, Lean principles have been successfully applied to different knowledge areas including software development. This workshop is intended to master Lean concepts like Waste, Push&Pull systems, systems thinking, Kaizen etc. & practicing cross-functional collaboration, self-organisation and safe-fail experimentation! In this interactive game, the participants will work in a small production lines, experiencing problems and applying Lean practices to overcome them.

Being worked as Agile practitioner for many years, I became known face of Agile among my colleague and I was started feeling that I know everything about Agile, but one day my friend from outside IT world asked me very basic question which brought me down in a moment.  He asked me what kind of work you do in office. As usual being Manager I explained everything in management terms. Somehow I felt he is not convinced. He asked next question if you say Agile Methodology is inspired from life then can I give him simple real time example which is not related to software world which will help him easy to understand. To be honest that time I was completely speechless, then decided to give them real time example so it can be relate with it.

There are 2 aspect of this article. First implementation of Agile in real life example and story of development of farm house.

Every Company is trying to surpass its Competitors in this ever changing World.  Today, World is changing so fast, that every company needs to Iterate faster after reading the Customers’ insights. The transition happened from the Industrial Age to the Waterfall Age. The Waterfall resolved the concerns to an extent; however, it laid the foundation for a new set of issues. Then the focus shifted to RUP, Spiral, V models and finally to Scrum, XP, Lean, Kanban, Scaling Agile, etc. 

However, no framework or methodology can solve the concerns without having a Good Engineering Culture.  The Culture undoubtedly consists of People and the surrounding Processes & Practices to help them (& not act as Blockers) to achieve the ever changing Definition of Success.

In this context, this talk will emphasize to shift our focus from the Leadership-Powerpoint Slides to our Engineering Culture. It will highlight the Problems and an attempt to answer the same by taking good case studies of Companies like Spotify, 3M, etc. We will talk about philosophies like M3.0, Holocracy, Tribal Leadership, etc and Engineering practices like Pair Programming, Continuous Integration, etc. We will also focus on the Roles of PO, SM, Developers, UX and the Leadership to shift to better Engineering Culture for the overall success of the Employees, Teams, Products and the Company on the whole.

Ina a nutshell, this talk underlines the importance of Alignment of Leadership’s Vision with Actual-on-the-ground Engineering Culture to achieve a Win-Win situation.

Thanks,

Gurpreet

We’ve always been told that because anything has both cost and value, we should make decisions based on Return On Investment.

The problem is that nobody told us that it’s just plain stupid.

ROI as a decision mechanism doesn’t work. It is possible to get the cost part right (maybe), but the value cannot be measured. We don’t know when to measure and even how. And because of the complex world we live in, the success of our next product depends on the one we’re working on now. Frankly we don’t know the impact of our current investment.

Take testing for example: How do you measure value? Bugs caught before release? General customer impression a year from now? We can put a number on the investment, but not on the return.

At this talk, I’m going to make the controversial claim that ROI can no longer be used as a planning tool. Organizations using it are risk-averse, deciding based on costs, rather than opportunity.

Join me and the modern world, and leave the metrics of old behind!

Take 100 people, send them to good introductory Scrum training, then back to their desks and expect Scrum and Agile.

What was missing.

How we bridged the gap in an unexpected, can't-be-ignored way.

Large or small, experienced or new startup, started with Agile and Scrum already or not, the first step everyone takes is setting up Scrum Teams.

Follow the rules and it should just work: deliver software at least 4 times faster and not disturb the rest of the organization. Based on standard Agile and Scrum training materials, a reasonable expectation. But anyone who thinks they can get away with introducing Scrum, getting the benefits, while not disturbing the rest of the organization is in for a big shock.

I will share my experience with an Agile transformation in a 100-person subset of a large software project, in the context of a 27000-person worldwide software development organization going Agile. The good, the bad, and the ugly. What we did about it and what remained to be done.

If you're new at it, so that you won't be shocked. If you're already into it, to understand what that nagging headache is and how to start feeling better.

Agile is mainstream method used in IT project management. Yes, method and no longer a philosophy. Everyone want to ‘do’ agile, so want to ‘be’ agile as well :) What are the common mistakes in applying agile? Join my talk & find out!

Agenda:

1. Bitter truth about IT projects

2. Complex projects nightmare

3. Are we *agile*?

4. Deadly sins

5. Ok, what next? We know what is wrong, how fix it?  

Some of the main Scrum goals are to be able to prioritize often and have less paperwork done. This contradicts with the project-based software development where project scope and deadlines are pre-defined and signed-off by the customer. This session presents how Videobet has implemented Scrum in a business environment that requires project style formalities.