Researching Agile - Issues, Challenges & Solutions!

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. 

 
2 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

Pecha-Kucha Style (possibly 20 X 20 approach)

  •   Agile Research - Where do we stand? (3 mins)
  •   Issues concerning Agile Research (2 mins)
  •   Challenges surrounding Agile Research (2 mins)
  •   Solutions for a 'better future' (3 mins)
  •   Discussion (10 mins)

Learning Outcome

Status-quo of Agile Research

Way forward to harness impactful Agile Research

Target Audience

Agile Practitioners, Agile Managers, Agile Consultants, Agile Researchers - Basically Agilists!

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Tathagat Varma
    By Tathagat Varma  ~  1 year ago
    reply Reply

    Ashay , it is not clear what will be covered in the talk. Can you elaborate on the key takeaways for the session?

    • Ashay Saxena
      By Ashay Saxena  ~  1 year ago
      reply Reply

      Hi Tathagat,

      The idea behind this proposed session is to inform the audience about the present state of Agile research. More importantly, the session shall draw attention towards some of the glaring concerns faced within the domain. Eventually, the idea is to move a step towards more collaborative efforts between researchers and practitioners.

      Key take-aways from the session:

      (1) Status-quo of Agile research: (a) Lay out where does agile research fits into the practitioners' world-view. (b) How has agile research addressed some of the concerns raised by practice. (c) Dominant research strategies followed by researchers. (d) Issues/Challenges faced while researching in the domain

      (2) Way forward to harness impactful agile research: This shall mainly dwell on the possibilities, through a discussion with the audience. I would explicitly lay out the need for agile research. Possible research agendas shall be ideated upon which could be taken forward.

      Thanks,

      Ashay

      • Tathagat Varma
        By Tathagat Varma  ~  1 year ago
        reply Reply

        Thanks Ashay. I am trying to align with the needs and expectations of the typical attendee of Agile India. IMO, they will be interested to know how the research relates to their work, and how can they remove some of the bottlenecks, or improve the quality or TTM, etc. Your focus on on the state of agile research. How can you bridge this gap, or align your talk to the participants's needs?

        • Ashay Saxena
          By Ashay Saxena  ~  1 year ago
          reply Reply

          That's a very valid point raised, Tathagat. The idea behind the proposed session was more to dwell on the meta-topic itself.

          However, in order to bridge the gap, I shall try to cover few instances which would give the audience a sense of how agile research has helped the community (while briefing about the state of agile research). These instances relate primarily with the managerial practices concerning the notions of control, coordination among others. Having said that, I shall refrain from getting very specific about a particular research topic. That shall deviate the session from the overall objective.

          Let me know if you feel the need for me to update the existing slides incorporating this aspect. Thanks.


  • Naresh Jain
    Naresh Jain
    Founder
    ConfEngine.com
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    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.

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

  • 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 Niranjan N V
    keyboard_arrow_down

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

    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 Karthikeyan Chellappa
    keyboard_arrow_down

    Karthikeyan Chellappa - 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 Pavan Soni
    keyboard_arrow_down

    Pavan Soni - Does Agile Approach kill Creativity in Organizations?

    Pavan Soni
    Pavan Soni
    Researcher
    IIM Bangalore
    schedule 1 year 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. 
  • 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.