schedule Mar 15th 03:45 PM - 04:30 PM place Grand Ballroom 1

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

 
3 favorite thumb_down thumb_up 1 comment visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  1. Typical problems teams/orgs face today and how we deal with them 
    1. Problem
    2. Typical "Agile Response"
    3. Problem with the typical "Agile Response"
    4. Antifragile way to dealing with that problem
  2. We'll address the following problems: (5 mins each)
    1. Lack of requirements & complexity coming up with the right priorities 
    2. Difficultly breaking down work and putting together a realistic plan 
    3. Poor predictability and quality inspite of all the rigour in the process
    4. Lack of innovation
    5. Team members getting burnt-out
    6. Unhappy employees due to performance appraisal 
    7. Complex Polices
    8. Difficultly in scaling/sustaining good practices
  3. Q & A

Learning Outcome

  1. Understand how we can leverage Volatility, Uncertainty, Complexity, and Ambiguity to make product development more antifragile
  2. Appreciate the importance of trial-and-error / safe-fail experimentation
  3. Importance of Polar strategies
  4. Why layers of redundancy are the central risk management property
  5. Understand how simple, clear purpose and principles gives rise to complex and intelligent behaviour vs. complex rules and regulations give rise to simple and stupid behaviour
  6. Appreciate the #NoEstimation movement (any system based on prediction will blow up)
  7. Use procrastination to free you from the hassles of backlog management (#NoBacklog movement)
  8. How being metrics obsessed (micro-management) can hurt you
  9. Some ideas on how to make Performance appraisal a more meaningful afair

Target Audience

Agile Experts, Management Consultants, Leaders, Companies struggling with Agile

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Ashay Saxena
    By Ashay Saxena  ~  1 year ago
    reply Reply

    Kudos Naresh! The proposal seems really exciting for the times we live in. This should resonate well with Agilists. Look forward to hearing from you at the conference.

     

    Regards,

    Ashay


  • Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 2 years ago
    Sold Out!
    45 mins
    Keynote
    Advanced

    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.

  • Liked Pavan Soni
    keyboard_arrow_down

    Pavan Soni - Does Agile Approach kill Creativity in Organizations?

    Pavan Soni
    Pavan Soni
    Researcher
    IIM Bangalore
    schedule 2 years ago
    Sold Out!
    45 mins
    Keynote
    Advanced
    The key tenets of Agile Software Development, or Agile Development, are shorter timescales, close-teamwork, continuous improvement, continuous customer involvement, and quick response to change, amongst others. Whereas the key tenets of creative thinking are deferring judgement, divergent thinking, individual time-out, overriding customers' demands, deliberately introducing errors and serendipity, and valuing improvisation over improvement, including others psychological practices. It is seldom realized that some of the principles of Agility might be at the very cost of Creativity. Are they opposites or complementary? 
    I propose a temporal and spatial complementarity model of Creativity and Agility along with innovation process, from idea generation all the way to execution. Doing so, I caution the adrant adopters of Agility on the risk of not fully utilizing the creative faculty of humans, and propose ways in which agility and creativity can co-exist. 
    Based upon understanding the developments in the field of creativity and innovation, and contrasting the same with the Agile tenants, I propose a few areas where the two converge, and where they diverge.
    The insights are mostly drawn from viewing firms in action, and from cases studies of building a culture of innovation in the organizations. 
  • Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 1 year ago
    Sold Out!
    45 mins
    Tutorial
    Intermediate

    A successful startup/product company needs to master the art of validating early product ideas quickly and effectively. Whether you are building a product, service or a new feature, the two most important questions to find out early are:

    • are we solving the right problem?
    • if yes, how do we pitch the idea to the target customer to generate a favourable action?

    During this session, we'll focus on various safe-fail experimentation techniques used by Lean Startups for quickly identifying and validating the customer's value hypothesis, without having to build the real product. You will leave this session equipped with various MVP design techniques, that will allow you to rapidly discover a viable product/service that delights your customers, without spending a lot of time and effort.

    Traditionally, entrepreneurs believed that the only way to test their product/service hypothesis was to build the best-in-class product/service in that category, launch it, and then pray. Most often, products/services fail, not because they cannot be built or delivered. But because, they lack the market-fitment and customer appeal.

    To avoid these risks, these days startups are focusing on building a "Minimum Viable Product" (MVP), a product that includes just enough core features to allow useful feedback from early adopters. This reduces the time to market and allows the company to build subsequent customer-driven versions of the product. Hence mitigating the likelihood of wasting time on features that nobody wants. MVPs are typically deployed to a subset of customers, such as early adopters that are more forgiving, more likely to give valuable feedback.

    However the problem with MVPs is that companies still spend too much time building stuff and very little time learning. Don't forget the purpose of MVP is validated learning NOT building. This session will give you ideas on how to quickly formulate and test your value and growth hypothesis in a scientific framework using extremely cheap MVP techniques collectively referred to as MVP Design Hacks.

  • Liked Rajat Talwar
    keyboard_arrow_down

    Rajat Talwar - Pains and Gains of being a Full Stack Developer

    45 mins
    Experience Report
    Intermediate

    As the industry is shifting towards an Agile (Continuous Delivery) style for developing products and services, (whether startups or large established organisation), everyone today has to thrive by innovating and adapting to the latest trends in technology. They have to keep themselves ahead in the race to delight customers. Full stack developers are key players in experimenting and delivering value consistently using varied tools and technologies throughout the stack.

    In this session I'll be share my journey of how I became a full-stack developer. Hopefully this will help others understand how they can target and plan to gradually become a full stack developer in their respective teams.

    Also I'll highlight the following topics:

    • What is the importance of a full stack dev?
    • What tools/resources/languages in my experience work best for full stack developers?
    • Downsides of being a full stack developer!
  • Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 2 years ago
    Sold Out!
    90 mins
    Demonstration
    Intermediate

    Over the past decade, eXtreme Programming practices like Test-Driven Development (TDD) & Behaviour Driven Developer (BDD), Refactoring, Continuous Integration and Automation have fundamentally changed software development processes and inherently how engineers work. While TDD has seen a great adoption on server side, developers still find it hard to apply TDD for developing UI components.

    In this hands-on, live coding demo, Naresh will build a web commenting and discussion feature (like Disqus) in React.js, 100% test driven. He will also demonstrate how TDD will help us drive an object-functional design to strike a pragmatic balance between the Object-Oriented and Functional Programming paradigms.

  • Liked Evan Leybourn
    keyboard_arrow_down

    Evan Leybourn - If you need to start a project, you’ve already failed #noprojects

    45 mins
    Talk
    Beginner

    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.

  • Liked Niranjan N V
    keyboard_arrow_down

    Niranjan N V - “If You Can’t Change, Who Can ? “ - Lean Agile Leadership for Enterprise Agility

    Niranjan N V
    Niranjan N V
    Chief Consultant
    Exelplus Services
    schedule 2 years ago
    Sold Out!
    45 mins
    Experience Report
    Advanced

    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.

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

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

    1. 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
  • Liked Jayaprakash Puttaswamy
    keyboard_arrow_down

    Jayaprakash Puttaswamy - Transformation - The Devil is in the Execution

    45 mins
    Talk
    Advanced

    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)

     

  • Liked Neil Killick
    keyboard_arrow_down

    Neil Killick - The Slicing Heuristic - A #NoEstimates Method for Defining, Splitting, Measuring and Predicting Work

    Neil Killick
    Neil Killick
    Lead Agile Coach
    MYOB
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Advanced

    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.

  • Liked Ashay Saxena
    keyboard_arrow_down

    Ashay Saxena - Researching Agile - Issues, Challenges & Solutions!

    Ashay Saxena
    Ashay Saxena
    Research Scholar
    IIM Bangalore
    schedule 2 years ago
    Sold Out!
    20 mins
    Pecha Kucha
    Intermediate

    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. 

  • Liked Karthikeyan Chellappa
    keyboard_arrow_down

    Karthikeyan Chellappa / Ashay Saxena - The Balancing Act of Distributed Agile

    45 mins
    Case Study
    Beginner

    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.

  • Liked Vijay Kulkarni
    keyboard_arrow_down

    Vijay Kulkarni - Mind shift for End-user documentation in Agile Methodology

    20 mins
    Talk
    Beginner

    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.