On Agile teams, collaboration is the way of life. Our leaders want their team members to work closely with each other, have shared goals and even think as one entity. Why? Because we believe that collaboration leads to happier, more productive teams that can build innovative products/services.

It's strange that companies use the word collaboration very tightly with innovation. Collaboration is based on consensus building, which rarely leads to visionary or revolutionary products/services. Innovative/disruptive concepts require people to independently test out divergent ideas without getting caught up in collaborative boardroom meetings.

In this presentation, Naresh Jain explores the scary, unspoken side of collaboration and explains in what context, collaboration can be extremely important; and when it can get in the way or be a total waste of time.

We have been discussing a lot regarding Agile transformations and how such transformations can help organizations. The key is to base such a transformation on the concepts of agility such as self-organization, intrinsic motivation, collaboration, etc. But still the puzzle of how those can be used in practice is less discussed. This is where the emerging concept of "Learning Organization" from Peter Senge can help a lot.

The five disciplines of a Learning Organization lies in the heart of an agile organization. Therefore, exploring the learning organization within agile organization aids us find the "truly" agile organization.

This is an experience report of a journey where a mid-size offshore software development organization moving towards to become a learning organization.  

I want to be controversial for a moment and propose an end to IT projects, project management & project managers. I propose that the entire project process is flawed from the start for one simple reason. If you need to run a project, you've already failed.

By definition, an IT project is a temporary structure to govern and deliver a complex change (such as a new product or platform) into an organisation. However, to be truly competitive, an organisation needs to be able to deliver a continuous stream of change. Managed properly, this negates the need for a project and the associated cost overheads.

This is fundamentally what #noprojects is. The approach, structure, tactics and techniques available to successfully deliver continuous change. At its core, #noprojects is predicated on the alignment of activities to outcomes, measured by value, constrained by guiding principles and supported by continuous delivery technologies.

This presentation will introduce you to #noprojects. You will learn how to define an outcome and create an Outcome Profile. You will also learn how to manage change within the context of an outcome through the Activity Canvas.

This session will be a combination of both devops concepts and a case study of a practical implementation of deployment pipeline. Karma teaches us how each action leads to good or bad repercussions based on the nature of the action.  If we build the deployment pipeline in a way that we are allowed to push only the good deeds through, We will be achieving good repercussions. But if we are not ? 

This is a concept I devised a couple of years ago, and it seems there is a new #NoEstimates audience that would like to know more about it.

A Slicing Heuristic is essentially:

An explicit policy that describes how to "slice" work Just-In-Time to help us create consistency, a shared language for work and better predictability.

The Slicing Heuristic seeks to replace deterministic estimation rituals by incorporating empirical measurement of actual cycle times for the various types of work in your software delivery lifecycle.

It is based on the hypothesis that empiricism leads to smaller cycle time duration and variation (which in business value terms means quicker time to market and better predictability) because it requires work to be sliced into clear, simple, unambiguous goals. Crucially, the heuristic also describes success criteria to ensure it is achieving the level of predictability we require.

Its application is most effective when used for all levels of work, but can certainly be used for individual work types. For example, a User Story heuristic can be an extremely effective way of creating smaller, simpler work increments, allowing teams to provide empirical forecasts without the need for estimating how long individual stories will take. However, if you are able to incorporate this concept from the portfolio level down, the idea is that you define each work type (e.g. Program, Project, Feature, User Story, etc.) along with a Slicing Heuristic, which forms part of that work type’s Definition of Ready.

This talk will equip teams and organisations who are established on their Agile journey with a robust, clear and repeatable method for improving the quality and time-to-market of their software development efforts.

“When will it be done?” That is the first question your customers ask you once you start work for them. And, for the most part, it is the only thing they are interested in until you deliver. Whether your process is predictable or not is judged by the accuracy of your answer. Think about how many times you have been asked that question and think how many times you have been wrong. Now think about how much harder it is to answer that question when practicing Agile at scale. Your customers most likely feel like they have better odds of winning the lottery than they do of your next Agile project coming in on time. That you don't know your odds of success is not necessarily your fault. You have been taught to collect the wrong metrics, implement the wrong policies, and make the wrong decisions. Until now. This session will introduce how to utilize the basic metrics of flow to more effectively manage the uncertainty associated with very large scale software development. In it, we will discuss how to leverage the power of advanced analytics like Cumulative Flow Diagrams, Cycle Time Scatterplots, and Monte Carlo Simulations to drive predictability at all levels of the organization. Your customers demand better predictability. Isn’t it time you delivered?

The metrics of flow provide a comprehensive, analytics driven methodology for agile development at scale. By capturing real-time flow metrics and by using powerful analytical tools such as the Cumulative Flow Diagram (CFD), Cycle Time Scatterplot, and Monte Carlo Simulations one is able to more effectively manage the complexity associated with very large scale software development. Better management of complexity ultimately leads to better predictability.

Further, these metrics provide transparency at all organizational layers. At the team level the metrics provide real-time information and act as a catalyst for continuous improvement; and at retrospectives the teams will always have the most accurate, critical and objective information upon which to base any action. For Scrum Masters and the team the metrics provide insight and levers to pull. This level of visibility is crucial to decision making as most organizations and teams can perform multiple types of work across varied layers of work-units.

Similarly, at the enterprise and/or program level the metrics provide the transparency required to effectively manage complex and geographically distributed development and maintenance environments. One is able to track progress, productivity and pro-actively act on systemic issues such as infrastructure concerns, resource capacity, cross-team dependencies, and integration.

Flow metrics are the most effective means to manage to predictable outcomes in an inherently uncertain field. The use of Scatterplots and Monte Carlo Simulation based on real historical metrics eliminates any need for subjective estimation. At all levels of an organization, these metrics provide much higher levels of confidence and more realistic projections.

Manager in an Agile environment is responsible for the “gray area” surrounding agile teams and throughout the organization.

This workshop we would try to explore What role does management play in the agile world of self-organizing teams? What is the function of managers in this new world?  What does an agile organization need from its management team?  Where should the agile manager focus their efforts for greatest benefit?

The use of software development methods has changed many times up history. Since the early 2000 the Agile methods have been dominating the arena and have been investigated in several aspects regarding failures, success and critical success factors.
When it comes to Enterprise Software development, outsourcing plays a major part. It has become almost a norm in the world during last fifteen years. Research show that, during last few years outsourcing software development organizations have made a tremendous effort to gain advantage of agile methods and practices.

Most the software outsourcing organizations today carryout various projects in cross-cultural, cross regional and cross-company context. The practitioners argue that use of one agile process or template across projects does not work in such organizations. Still, due to scaling, training and other business and operational requirements of outsourcing companies, we see that there is a trend of bootstrapping agile projects in such organizations.

We will in this paper share our findings from investigating cross-cultural, cross-regional and cross-company projects in terms of critical success factors for bootstrapping agile projects in outsourcing companies. We will discuss the success and failures of bootstrapping agile projects in this context. Through quantitative data gathered from projects conducted, combined with qualitative data from interviews with developers and key staff from project management, we shed light on an less emphasized, but highly crucial, part of agile project management. 

Working over a decade in highly structured and process driven large organizations, all of sudden I made the move, to work in a completely agile organization. I knew that I am going to face set of completely new challenges after years of structured management experience, I could fail!!! Still I wanted to test myself in an extremely agile context and understand how I could change my management style and thinking patterns.

As soon as I started working in the new agile setup, everything looked a chaos, no defined process manuals, no one to tell me what to do, referential power had 0 value in management, self-learning and mastery was highly expected, basically I had to change my mental model and adjust to a way that I need to learn, think and act with best of my abilities, in order to be successful in the new company.

This talk will explain the methods I used to do the self-transformation, reevaluate my thinking, change and adopt to agile thinking patterns to take over a management position in an agile company successfully.

It’s a dream come true if every team has Super Heroes. But is that reality?

Gone are the days when there was a demand for super heroes. Agile has helped to overcome this issue with the environment it creates. The power that a strong agile team creates, goes beyond the power of super heroes.

The leadership skills that agile instills in the members, make them converge as a super team that has more power than a super hero.

This presentation shares the techniques and learnings, on how to create super teams in an agile environment, when the members are not super heroes.   

Providing a quality delivery quickly is the way to keep the customer happy.  This is where a stream lined DevOps framework comes into play. Having a comprehensive, tried and tested DevOps framework with tools that could help different technologies and engineers who can handle them well could be the next winning point when a client choosing a vendor for outsource development.

Everyone talks about DevOps today. But do you have a clear idea on how to set-up such DevOps framework for your projects?

This session will take you through simple guidelines to give you an idea of how to setup your DevOps framework in short steps based on a case study.