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.

What started off as a trial-and-error approach to improve the state of software development by a bunch of tinkerers, is today dominated by management consultants, "Thou-Shall" codified frameworks and rigid, expensive tools. Over the last 20 years, we've gone from, "I'm not sure, let's try this in a small-safe environment" to "you/your-team sucks; you guys have a very poor agile maturity because you are not doing _x_y_z_ (not conforming to the standards)." Along the way, we've lost the purpose of being agile .i.e. to embrace uncertainty via simplicity. Instead we've been forced to believe that consistency via top-down standardisation and predictability by increasing the rigour on process is our eternal quest. Anything that sounds simple and works 80% of the cases is discarded as being naive. What once drove thought-leader into agile, is now driving them insane. This is the unfortunate fate of Agile.

Luckily there has been some fresh perspectives from Nassim Taleb, author of Antifragile. His work explains how some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. More importantly why antifragility is beyond resilience or robustness.

In this talk, I'll use some of Nassim's thoughts (and some of my own) to explain what is wrong with our current approach to Agile and how we can bring life back into Agile. Particularly how we can leverage Volatility, Uncertainty, Complexity, and Ambiguity to make product development more antifragile.

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.

Most Lean/Agile team have had limited success in establishing a culture of Continuous Improvement. Retrospectives are done but in most cases they are done without a goal, a vision. Toyota Kata, as codified by Mike Rother, is an approach to put an culture of Continuous Improvement in a team/organization.

This full-day workshop focuses on applying Agile engineering practices to web development. We'll look at practices such as build automation, continuous integration, test-driven development, refactoring, and incremental design and see how to apply them to front-end web development. We'll cover topics such as cross-browser testing, JavaScript, and CSS.

Audience: This session assumes familiarity with Agile engineering practices such as test-driven development and refactoring. Experience with JavaScript, CSS, and other web technologies is recommended. Come prepared to code.

One common problem any delivery team struggles is to have a common understanding of "why" a product or feature is being built. The documents such as Project Charter, vision document etc. tries to solve this problem, but it’s common to see such documents exist in the repository, hardly known or read by anyone in the team. And this document rarely gets updated too. Ask your team members what is the goal of the project? You may be surprised to know how many actually know about it.

The so called "vision" or "goal" usually rests within Product Manager/Owner or any other stakeholder. There is no forum to converse about these goals or ideas as a team. The planning meetings [iteration or release planning] are supposed to take care of this, but there is no standard guidelines defined which would help to brainstorm these in a typical release/iteration planning meetings.

This is where Impact Mapping comes into the picture. It is a "Strategic planning technique", defined by Gojko Azdic, explained in the book Impact Mapping. It is a very simple technique based on the idea of "asking the right questions" which are:

• Why are we building what we are building? i.e., Goal(s) of the product
• Who we think are the actors who’ll get impacted?
• How do we expect to change the actors’ behavior?
• What are we going to do to create the impacts? i.e. the feature list / deliverables

Finally, by connecting the deliverables to impacts and goals, a map shows a chain of reasons that leads to feature suggestion. 

Fundamental of Impact Mapping is that Impact means a change in behavior of an actor which usually results in a positive impact either by Reduction in the Cost or Improvement in ROI for the business.

If you closely watch the sections in Impact Mapping, what to build i.e. the features or the so called backlog comes only at the end, whereas in the typical planning meeting we usually start with a backlog.

The above questions need to be answered by the entire team [the IT team, the business people and any other stakeholders, if any], and avoids the common anti-patterns during planning meetings:

• Ad-hoc planning
• Wrong Assumptions
• Pet features

The hands on workshop will cover the above mentioned concepts of Impact Mapping in detail along with exercising the same.

Below are a few comments that we received from our customers after being part of the Impact Mapping session:

• “It made me think about the real goals my product has to achieve during the initial launch.”
• “Wow, this is a great way of visualizing”

My talk is about how the leadership can play their role when we talk about the Software Enterprise Agility. As per Peter Drucker a well known management guru, “Workers themselves are best placed to make decisions about how to perform their work”. To effectively lead, the workers must be heard and respected. They have to have autonomy. Continuing innovation has to be part of their work, the task, and the responsibility of knowledge workers. When we talk about Scaling Leadership style for enterprise agility, The leadership should be ,

• Taking responsibility for Lean-Agile success,
• Teaching Lean-Agile behaviors to other employees, direct and indirect reports , teams, departments etc,
• Trained in practices and tools of continuous improvement
• Teaching problem solving skills and corrective action
• “Develop people” —People will develop solution, management need not worry too much on focusing developing solutions.

1. Brief description of the talk

My talk will initially consist of current challenges in the Leadership based on my experience in coaching, consulting and training

When we talk about the scaling leadership for Enterprise Agility, the most desired style is “Leaders should be developer of people”. Lean-Agile Leaders are lifelong learners and should help teams build better software systems through understanding and exhibiting the values, principles and practices of Lean, Systems Thinking, and Agile development

The main part of the talk is based on my experience of coaching, training and consulting. The Lean Agile Leaders for Enterprise Agility should

1. Have a Systems View:

That means today’s Lean-Agile Leaders should understand the economics, the full value chain, and the Cost of Delay, Optimize the whole, not the parts, the organization & software system. They should focus more on implementing Lean Budgeting rather than traditional project based budgeting.

2. Implement the Product Development Flow:

Lean agile leaders should know how to visualize work; expose bottlenecks, Reduce queues and backlogs. In Enterprise Agility , bigger the size of people, it will lead to more coordination issues, complexity increases, alignment to the business units . Implementing organization strategic goals becomes difficult and pose multiple challenges. Therefore we need to think of Reduce batch size, accelerate feedback, exploit variability using cadence and synchronization so that every team demonstrates value to the customers

3. Embrace the Agile values and principles:

In an Enterprise Agility, Lean Agile leaders should fully understand agile values and principles; such as focusing more on deliver more frequently and know how to implement XP, Scrum, Kanban more importantly Scaled Agile Methods such as SAFe, LeSS etc. Exhibit Kaizen mind and empower high-performing, cross-functional teams.

4. Strengthen the hidden potential and intrinsic motivation of knowledge workers

The lean agile leaders should focus more building a learning organization and emphasize lifelong learning. They should provide safe environment of mutual influence the teams and who ever work under them. They should foster decentralized decision-making with minimum specific work requirements. One of the ways of unlocking the hidden potential and motivation of the workers is ensuring the direct reports and team members have

• Autonomy
• Mastery and
• Purpose

This talk is an experience sharing session about what it takes to realize business benefits in a large-scale (beyond 100 people) agile transformation. Having driven more than 4 large-scale transformation initiatives (of scales 160 to 700 people) over last 5 years, I would be sharing a couple of case-studies where I worked recently and I would discuss various challenges of implementing large-scale transformation and possible approaches to handle them. Participants would be engaged through interactive discussions on mutual experience sharing with a focus on key dimensions of agile execution.

As the title reveals, the talk would focus more on execution challenges and approaches to handle them at all levels of stakeholders involved in a transformation. Levels include developers, architects, managers (project/engineering), senior management (delivery/program management, directors) and CXO's. More details in Outline section. 

The key dimensions to be covered include

1. Building and sustaining learning culture (approaches include Community of Practice, Guilds and Joint Workshops)
2. Causing the mindset shift in engineers (different approaches for developers, architects and engineering managers)
3. Enabling managers to create and nurture agile engineering culture (approaches include effective metrics about quality of code, tests, application and build)
4. Inverting the Test Pyramid (approaches include test automation strategies, BDD, dealing with Legacy using Strangler pattern, Component Guardian pattern)
5. Leadership Agility (approaches include catalyst style of leadership, risk driven decision making, leading the change)

How fast can you go from an Idea to Reality?

From an idea to the time you validate your solution with real users - not friends and family, how long does it take?
In case you are yet to start, how long should you take?

Lean Startup is a buzz-word these days. And for a good reason too - it works! But, there may be times when you get hung-up trying to validate with methods like landing pages, MVPs, MVFs and Interviews. And before you know it, a month has passed by, trying to generate traffic to your landing pages, making sense of analytics and polishing your MVP. 

The Google Ventures' Design Sprint is a framework for solving real-world problems through research, ideation, prototyping and talking to real users, in 5 days or less.

How will Design Sprint help?

• Focus. First off, design sprint will put you on the clock. 3-5 days of complete immersion. 
• Build the right thing. Taking a Design Thinking approach inspired by IDEO, will help you look at the problem the way your customer would. Then user your teams creativity to solve it in unique ways. 
• See the Truth. When you'll put the prototype to test in the hands of a real user, your team will see first-hand what works and what doesn't. It's the next best thing to reading your customer's minds.
• With a couple of days still left in the week, you relax with a cup of Earl Grey tea and do some more thinking. Probably, get ready for the next sprint.

When we conducted design sprints with our customers, we had some unexpected realizations:

• We saw that the ownership and motivation in the team improved significantly.
  They were mindful about "why" they were working on the features they were working on.
• Our customers would say, "This has completely changed the way I think about building products." 
  Going from a solution driven approach to problem-first approach and keeping the products very lean.

Code quality is being a topic in discussion for ages and we developers have been in the receiving end every time. The criticism developers receive on this is always subjective and representing someone's view rather than any objective decision. This is a case study of how those subjective comments can be transformed into Objective measures with some practical indicators. The example is a Project in which Exilesoft provided for a leading Norwegian Vendor of Learning Management Solutions. The project involved transforming their legacy application into a newly cast application Solution. During this session I will take the audience through the journey of the Case study on what are the challenges we faced during the implementation in terms of code quality, what are the measures we used to prove the code quality and the approach we took for improving the quality of the code base

“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.

Over the last decade, organisations have embraced agile approaches in a bid to uncover "better ways of developing software". Agile has fast-become the norm for software development owing to its credibility to be able to deliver continuous business value to the customer. Despite the promise, there are several grey areas expressed with the specific approaches (be it Scrum, XP et al) as well as ways in which teams practice them at a project level. Subsequently, several concerns have been raised by the practitioners. Consultants, Coaches and Researchers constantly dwell on these aspects and make an attempt to provide solutions to these existing challenges.

A succinct account of the status-quo is that practice has led research in the domain. However, there has been recent surge of Agile research playing catch-up with the various facets of Agile practice. This session shall dwell on the present state of Agile research. The issues and challenges concerning Agile research shall be presented. A brief discussion, in the form of "chit-chat", shall ensue to possibly lay out a bright future for Agile research. 

The need of the hour for almost any software organization today is being or doing Agile. It helps organizations deliver continuous business value to the customer. At the same time, some organizations may need to embrace distributed teams, working from multiple sites on a project, to capture global talent and leverage expertise at different locations.

In present times, software organizations are making a sincere attempt to successfully deliver projects following the distributed-agile approach. However, ‘Agile' and ‘ Distributed' seems to be at two opposite ends of a continuum, in terms of demands for flexibility and control to the approach of software development. In such a scenario, how does one manage to work with this approach in harmony?

We made an attempt to understand the drivers that leads to effective balance between the tenets of distributedness and agility in a software development team. Our research lead us to one of the leading agile practitioners viz. ThoughtWorks in a bid to uncover the mechanisms followed in their distributed agile projects. We interviewed several people in their organization including Developers, QA, Business Analysts, Project Leads and Managers working on a project to figure out just what makes distributed agile project(s) tick.

Our findings have led us to believe that the creation of a unique 'project context' is essential to effectively balance the conflicting requirements of distributed and agile development. Our objective is to share these findings with the agile community. We hope that our insights will help other agile practitioners working with distributed teams to execute their work more efficiently and effectively. 

Moreover, we would also dwell on the case study research approach to help agile researchers carry them out in a convincing manner. In particular, we shall focus on the process of site selection, data collection and analysis which could lead to good insights from the “field" on the researchers’ topic.

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. 

Do you really find meaning in all the ceremonies you do on an agile project? 

Let's consider, you were asked to build a project in 8 weeks that was originally for 6+ months. Let's add to the mix a few unknowns such as not finalized external API integration and a few spikes. Would you take it up? The first thing that would come to your mind would be long working hours and a totally burnt out team with very little chance of success.

Delivering this project requires thinking out side the box. The processes that we follow as chores such as standups, retrospectives, demo and others could become time sinks. We perform the ceremonies as chores and have lost the purpose as defined in the manifesto. 

You can call yourself agile as long as you define your own process and stick to the manifesto. We defined our own process in delivering the above mentioned project in 10 weeks. We call it the Burst Mode Development. 

Burst Mode is a mindset. Do not make the mistake of following it as it is. You want to stick to the purpose of each step and depending on the dynamics of your team, tweak the process to suit your needs.

High performance agile teams are always striving to achieve an effective retrospective that enables the team to discuss the success criteria, and define the areas of improvement further.  This is an important aspect for cross functional teams – the development, operations, database administrators, systems administrators, QA testers, product managers - to focus on excellent communication and collaboration. 

Over the years, my experience has been that retrospectives can get monotonous with time, and hence tend to become ineffective. The more I engaged with the process, the more I felt the need to revolutionize the process, bring out something new, fun, and exciting to make the retrospectives vibrant.  The other interesting aspect I came across during my research into the subject was the theory of gamification and the universality of its application. 

During this session the audience will understand how the concept of gamification brings in a completely different dimension of thinking while maintaining the element of fun as we try and apply it to a few everyday situations!

 I have leveraged Luke Hohmann’s Innovation Games, The Conteneo Collaboration Could platform for this concept of gamification so that distributed teams can benefit by this.  

I worked as a coach and have experience ranging from team level to large scale agile transformation that involves:

- Multiple teams from different locations
- Different cultures
- Variety of structures
- Component teams
- Strong silo working culture
- Legacy code base
- Different release schedules and processes
- Wide range of tools
- And many other challenges

As part of working on the assignments to help the organizations transforming into agile, I had come across various anti patterns and road blocks at various
levels. These anti patterns are very critical to understand and help the organizations to tackle them effectively without compromising on the core agile
values and principles.

It is very easy for any organization to kick off the transformation but it is very hard to maintain the sustainability and become a matured agile organization. During this period there will be many traps that will force the organization to take a U turn and get back to where they started. Lot of effort, money and time gets wasted in this process. It is important to understand the key areas of enterprise agile pathway and decide the roadmap for the transformation with a clear vision and goal. Periodic inspection and adaption is also critical in this whole process to successfully achieve the vision and goal of transformation. top to bottom of the organization will play very vital role in this journey, without proper collaboration, communication and understanding among these teams, organization cannot transform. 

Once the transformation kicked off, organization will go through a whole set of different challenges during their release planning, sprint ceremonies, collaboration issues, cross location team challenges, tools and processes and these are also critical humps to crossover successfully. 

Another important area that usually will not get enough importance in transformation is the "communication" part. Agile emphasizes more on "face to face" communication. But is it just enough talking face to face? Conflict --> Communication --> collaboration --> Value delivery. This path has to be clearly understood at all levels of organization. 

My topic is going to cover these anti patterns that I had come across in my coaching experience and share them with the audience. As part of this session, I am also planning to conduct a survey to see how many of these anti patterns are common to the organizations that are transforming into Agile. I will collect the survey information from the participants by providing them a quick hand copy of the survey form. This information will help me for my paper that is in progress on the "Enterprise Agile Transformation".

I am also planning to have some activities within the session by giving the audience some challenges of transformation and try to find suggestions to arrive at solutions to tackle those challenges. This part will make the session interactive and two-way knowledge sharing.

The anti patterns will be mostly around the following categories:

- Management responsibility
- Structural challenges
- Product teams
- Portfolio management
- Scrum teams
- Scrum Master
- Support teams (Sales, Marketing, HR, Admin etc)
- Communication
- Continuous improvement
- Tools
- Processes

I will also cover, what was done for some of the key anti-patterns to address them as part of the transformation engagements.

After a successful release, the product manager feels extremely happy that the team met the commitments and delivered the software on time. However, when he probes the actual users for the feedback, the first reaction is “documentation sucks”. Why does this happen? Most of the developers and testers still follow the traditional approach of involving documentation folks towards the end of the release! This is paradoxical because when you have development and testing happening in agile approach how can you have documentation in traditional approach?

This session deals with the mindshift change that the entire value chain needs to make end-user documentation a critical part of the scrum team deliverables and bring it on equal pedestal as any other deliverable.

It emphasizes that technical writers should not feel marginalized with the fast paced development, testing, and delivery cycles. Instead, they must work very closely with the developers and testers because they no longer require to sit outside the room and walk in only after the bell rings! And the developers, testers, product owners should not consider documentation folks as the last leg of the product delivery cycle. They must all work as an integrated team, start-to-finish.