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.

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.

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)

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.

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. 

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.