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)

 

 
15 favorite thumb_down thumb_up 24 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

Section 1 - Introduction and Context setting - 5 mins

In this section, the context setting and a brief introduction to the dimensions mentioned in the abstract would be provided.

Section 2 - 30 mins

First 15 mins: Case-study 1

  • This is a case-study of large scale transformation of two entities merged to provided an integrated solution using Agile and Lean practices across the organization. The teams were distributed over more than 4 different countries.
  • Key challenges and approaches used to handle them would be explained highlighting any of the 5 key dimensions along with a few practical examples/situations.

Second 15 mins: Case-study 2

  • This is a case-study of large scale transformation of a large enterprise that got acquired by a global organization. It involved about 700 people, but almost all co-located with some dependency on third-party vendors for a few hardware drivers and related software.
  • Key challenges and approaches used to handle them would be explained highlighting applicable dimensions from the 5 key dimensions along with a few practical examples/situations.
  • Experience sharing on transforming engineering practices at scale also would be part of this experience sharing.

Section 3 - 10 mins

Q&A about the experience shared and conclusion with summary of key takeaways.

 

Example practical situation (that would be shared):

Dimension: Inverting the Test Pyramid

Situation:
Assume that a legacy multi-tier enterprise application exists with less than 10% automated unit tests and integration tests. Also assume that the teams have challenges in building necessary automated testing infrastructure to following reasons:

  • Lack of skills to distinguish between unit tests and integration tests
  • Lack of enough time
  • Delivery pressure on developing more and more features

Wearing a Technical Coach or Agile Champion's hat, how would you enable your teams to write and automate relevant unit tests and integration tests impacting the application quality positively while keeping in mind the current team challenges? You recommendations should contain at least two practical tips to tackle the situation realistically.

 

Learning Outcome

At the end of this interactive talk, participants would have understood and/or gained better insight on the following:

  • How to approach and analyze execution challenges of large-scale transformation
  • How to cause mindset shift of engineers to build and sustain agile engineering culture
  • Pragmatic approaches to deal with challenges posed due to Legacy enterprise applications and complexity of large-scale transformation
  • Coaching tips on dealing with leadership style changes needed for effective implementation of large-scale transformation
  • Setting up learning culture based on lean principles and using light weight structures like CoP, Guilds, etc...

Target Audience

Delivery Managers, Engineering Managers, Architects, CXO's

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • HARISH THAMPI S
    By HARISH THAMPI S  ~  1 year ago
    reply Reply

    Interesting and worthwhile topic.. Looking forward to be in this. 

     

    • Jayaprakash Puttaswamy
      By Jayaprakash Puttaswamy  ~  2 years ago
      reply Reply

      Thanks Harish. I'm looking forward for review committee to get back.

  • Ravi Kumar
    By Ravi Kumar  ~  2 years ago
    reply Reply

    Hi JP,

    Great topic and I truly believe the "devil lies in the execution" as well and this could be so context specific since every organisation/enterprise is so different. That said I think this topic will be good for a talk over a workshop.

     

    My suggestions is to bring cases from your experiece on the 6 dimensions that you talk about and how did you overcome them. For ex.

    • How did you engage with key stakeholders to implement the 6 dimensions?
    • What uniques choices and strategies you had make that differed in each of the organisations and Why?

    The talk will be awesome with some real data points and outcomes achieved. What do you think?

     

    Best,

     

    Ravi

     

    • Jayaprakash Puttaswamy
      By Jayaprakash Puttaswamy  ~  2 years ago
      reply Reply

      Thanks Ravi.

      I have both spoken and driven workshop like activities on each of those dimensions in different forums (focusing on one or two topics) earlier. My experience and participants feedback was favoring more on activity driven discussions than plain talk and hence the proposal of workshop. Whether its a talk or workshop, I would be sharing the real data ensuring client confidentiaility.

      But your feedback also triggered a thought about time management and I felt it could be little tight to demonstrate 3 dimensions. Thanks for triggering the thought.

      How about restricting demonstration through activities, to only 2 chosen dimensions and presenting the rest as an interactive talk? But, I would still like to call it a workshop though since people need to get that its about participative learning.

      - cheers

      JP

      • Ravi Kumar
        By Ravi Kumar  ~  2 years ago
        reply Reply

        Hi JP,

        Each of the dimensions could be potential topics. I don't think the audience will reap full benefit by participating in couple of demos. I'm strongly tending towards a talk and not a workshop. Here's why...

        • Given that this talk is at a advanced level I expect participants who are already in the agile space for some time and enagaged in some transformation journey.
        • If I were to be the participant I would like to see how to apply the dimensions in various contexts and complexity of the org much more than participate in a demo/activity. People get the challenges but "how to get over" is the sticky one.

        So I would structure the talk around the experiences from the 4 large companies

        1. Large company context - challenges, expected outcomes etc.
        2. Application of dimensions - Challenges in applying, strategies that worked in each context, what outcomes were delivered and most important what are still bothering and pending implementation.

        Also, what could be killer is to have a customer along as co-presenter who has gone through the journey if possible.

         

        Hope this helps,

        Ravi

        • Jayaprakash Puttaswamy
          By Jayaprakash Puttaswamy  ~  2 years ago
          reply Reply

          I see your point.

          Given the nature and complexity of the topic (on transformation challenges and ways to get over it), I don't think we can do a justification in demonstrating solution approaches in a 45 mins talk. Objective of the workshop proposal was to let participants see several dimensions to a transformation challenge and realize that each needs a different solution approach.

          However, if you insist that I do a talk, can I get 90 mins slot? If not, I can only share the experience based on your structure for about 2 large companies and still ensure quality of discussion.

          Let me know the maximum slot duration for a talk and I would restructure it accordingly to make it an experience talk.

           

          -JP

          • Ravi Kumar
            By Ravi Kumar  ~  2 years ago
            reply Reply

            45 min for a talk. Looking forward to see the reworked proposal.

             

            Best,

             

            Ravi

            • Jayaprakash Puttaswamy
              By Jayaprakash Puttaswamy  ~  2 years ago
              reply Reply

              Hi Ravi,

              Revised the proposal. You almost dictated what I need to do as a speaker, but I still do respect your suggestions.

              I'm not sure if you have prior experience of sharing the challenges and solutions approaches of large scale transformation in a 45 mins talk. But I have. It can become ineffective if irrelevant audience participate in it. (example - people asking basics when rest are talking about scaling scenarios).

              However, I can manage such situations effectively if you provide an additional 15 mins, with a total duration of 60 mins.

              I would leave it upto you. If you still say 45 mins, I would be agile enough to skip a case-study based on situations that arise.

              • Ravi Kumar
                By Ravi Kumar  ~  2 years ago
                reply Reply

                Hi JP,

                My comments in line to your response.

                >>You almost dictated what I need to do as a speaker, but I do respect your suggestions.

                I’m reviewing your proposal in the best interest of the conference and suggesting ideas to shape the proposal. Dictating what you need to do as a speaker is not my interest here.

                >>I'm not sure if you have prior experience of sharing the challenges and solutions approaches of large scale transformation in a 45 mins talk. But I have. 

                As far as my experience goes in this context I’m not as distinguished as you are or at least I don’t make such claims.

                Given that you have a lot of experience then I suppose you can put out a compelling proposal with data points that would stand on its merit and swing in favour of a 90 min over a 45 min talk. I hope you agree on this. 

                That said, it’s seldom the case we’ve come across instances of a great 90 min talk.

                >>It can become ineffective if irrelevant audience participate in it. (example - people asking basics when rest are talking about scaling scenarios).

                Agree. The proposal is marked ‘Advance’ which should take care of the audience. Also, I’m sure you would set expectations at the beginning of the talk accordingly.

                >>However, I can manage such situations effectively if you provide an additional 15 mins, with a total duration of 60 mins.

                Make a compelling case for it and I don’t see a reason why it cannot be done. We have a very good committee capable of deciding on this.

                >>I would leave it upto you. If you still say 45 mins, I would be agile enough to skip a case-study based on situations that arise.

                Actually I leave it upto you to consider the suggestions/comments. If you think the suggestions don’t make sense then you must not consider. That’s what I would do. Last thing we want is someone to go up in front of the audience without conviction in what they are going to present.

                • Jayaprakash Puttaswamy
                  By Jayaprakash Puttaswamy  ~  2 years ago
                  reply Reply

                  Thanks Ravi for your suggestions.

                  Let me be very clear. I'm not okay with your misinterpretation and playing with the words. What I asked for is either a 90 mins workshop or 60 mins talk time.

                  You are indeed dictating me on the "objective and delivery style of my proposal".

                  The objective of my original proposal was to "let participants see several dimensions to transformation challenges and realize that each needs a different solution approach" and NOT to provide any solution. As per my experience, realizing about those dimensions and arriving at relevant approach it self is half the solution. Rest is specific to the context of the organization getting transformed. Hence the proposal of a workshop to make participants understand the dimensions through practical situation driven activities/discussions.

                  You forced me to change my objective it self to talk about solution approaches and like you rightly recognized elsewhere, each dimension and solutions approach qualifies a focused workshop by it self.

                  Here is my final ASK.

                  Many aspiring participants have shown interest in the topic I proposed originally and are looking forward for it and it is evedent in this comments thread.

                  If your claim is in the best interest of the conference audience, you either provide me a 60 mins slot for the talk or feel free to reject my proposal.

                  I wouldn't be able to discuss client specific data points in public due to confidentiality terms and ethical reasons. If you are keen, feel free to call me on +91 8971198198 and I would be happy to provide by justification needed.

                  • Ravi Kumar
                    By Ravi Kumar  ~  2 years ago
                    reply Reply

                    The review committee will decide and get back to you. Thanks.

                    • Jayaprakash Puttaswamy
                      By Jayaprakash Puttaswamy  ~  2 years ago
                      reply Reply

                      Hello Ravi and other committee members,

                      Any updates on my proposal status?

                      -JP

                      • Tathagat Varma
                        By Tathagat Varma  ~  2 years ago
                        reply Reply

                        JP - we are in the process of collating all feedback across all themes and will communicate accordingly. Should have more details in couple of weeks.

  • Prasad
    By Prasad  ~  2 years ago
    reply Reply

    JP 

    lot of things cover in your proposal, IMHO will have more impact if we focus on 1-2 outcomes

    • Jayaprakash Puttaswamy
      By Jayaprakash Puttaswamy  ~  2 years ago
      reply Reply

      Thanks Prasad. That was my plan too.

      Not sure if you have gone through the comments  thread below. I'm waiting for review committee's response to know the final structure and duration. Once I get it, I would refine it accordingly.

  • Kiran HG
    By Kiran HG  ~  2 years ago
    reply Reply

    Looking forward for your session JP.

  • Ramesh Bhat
    By Ramesh Bhat  ~  2 years ago
    reply Reply

    This is a great topic I was looking for. Most of our program initiatives undergoing agile transformation are plagued with practical issues in making agile work at multiple levels. Especially with decision making at management and leadership level, motivating engineers to adopt test automation and sustainting that motivation is a big challenge. We need more practical approaches to do all these things.

     

    Eagerly looking forward to participate in this workshop and learn from each other!

    • Jayaprakash Puttaswamy
      By Jayaprakash Puttaswamy  ~  2 years ago
      reply Reply

      Thanks Ramesh. Appreciate your passion towards agile execution.

  • Gururaj Kuruba
    By Gururaj Kuruba  ~  2 years ago
    reply Reply

    Hi JP, great topic. Execution is the key in creating value to every customer. How would Agile make the paradigm shift in every delivery manager's mindset, I would like to hear more on this from your session. 

    Most business schools teach "Business is making money", but they have changed the punchline to "Creating Value", how by execution excellence. so this session would be to all Management aspirants as well!!!.

     I am sure it would be great session like in the past!. eargly look forward!!!

    • Jayaprakash Puttaswamy
      By Jayaprakash Puttaswamy  ~  2 years ago
      reply Reply

      Thanks Gururaj. In this workshop, apart from the mindset shift needed, I would also be simulating practial situations we encounter during implementation phase and enable discussions about pragmatic approaches to deal with them.

      It would be wonderful to have you and looking forward to have insightful discussions during this workshop.

  • Prashant
    By Prashant  ~  2 years ago
    reply Reply

    Interesting JP...Looking forward for your session

  • Babu Ajay Kumar
    By Babu Ajay Kumar  ~  2 years ago
    reply Reply

    Looks quite interesting, i am interested in attending it.


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

  • 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 Jaya S
    keyboard_arrow_down

    Jaya S - Scrum Dev : An effort towards Developer Friendly Scrum Practices

    45 mins
    Talk
    Beginner

    When faced with some challenge we try various things and finally find one silver bullet.  Further we make use of the same silver bullet by incorporating it as part of Process and make it a rule to follow.

    SCRUM as a framework has originated in similar situations and become the silver bullet for avoiding the ills of waterfall method. Scrum is successful and now widely used within multiple organizations.

    Since SCRUM is almost 20 years old and 20 years of usage must have generated enormous feedback for the framework itself. Maybe it’s time to look at those feedbacks and do a retrospective on the way we’re using SCRUM.

    My experience with multiple scrum projects taught me that one of the biggest de-motivating factor of working with scrum sprints are their monotonous nature of work.  The sprint cycles with sprint planning and retrospectives becomes too repetitive to keep up the initial momentum.

    We use the word “Just for change” quiet often for our own well being and happiness. SCRUM Dev is the same “Just for change” development practices incorporated within sprints.

    These sprints contain unplanned working to themed based working which breaks the monotonous cycle of work and help maintaining the team momentum. At the same time it also benefits the product and its quality.

  • Liked Jaya S
    keyboard_arrow_down

    Jaya S - ScrumBan: Best of both worlds - A Fertile Hybrid

    45 mins
    Talk
    Beginner

    We're living in the days of fusion where fusions have created extremely useful products. There are fusions like western music with Indian classical, Pizza with Indian dishes like Paneer etc to name a few.

    Scrumban is also a fusion generated by combining the best practices of Scrum and Kanban. Scrum is an excellent framework for delivering the software by using iterative incremental way while kanban "Just in Time" technique enables us to handle on demand agility for frequently changing and dynamic working environments.

    Scrum framework consists of artifacts and roles while kanban is a visual board which deals with Work in the form of Work in Progress limits. There are situations where our product development environment faces ever changing priority and requirements.

    ScrumBan is an effort to combine the iterative development and role based responsibilities of Scrum along with capability to handle the adaptive dynamics of Kanban.

    Scrumban can be used effectively for product development as well as for maintenance purposes. In scrumban we do a Release Planning but not sprint planning. Planning on Demand is the characteristics of Scrumban where based on the items on the Scrumban board we decide to do planning or product demonstrations.

    Scrumban also imbibes some new concepts of release planning called Triage & feature freeze which greatly improves the product quality.

  • Liked Vijay Bandaru
    keyboard_arrow_down

    Vijay Bandaru - Let's solve a practical problem together using Lean Principles

    Vijay Bandaru
    Vijay Bandaru
    Agile Coach
    IVY Comptech
    schedule 2 years ago
    Sold Out!
    45 mins
    Workshop
    Beginner

    This topic has popped up in my mind through an observation of a practical problem I found yesterday. I thought to apply some lean principles to resolve this problem. I am proposing the problem statement here in this forum and the idea is to have an interactive workshop to come up with possible solutions to address this problem using Lean thinking/principles. Here are the details.

    Yesterday I visited Hyderabad Zoo (Nehru zoological Park) along with my cousins families. We are 12 members including adults and children. Earlier till November 2014, visitors cars were directly allowed inside with an additional fee of 200 rupees per car. I visited the Zoo before 2014 November and it was an awesome experience going by our own car and stop wherever you want for however long you want. Now, as they stopped allowing private cars inside, they arranged electric cars rides inside the Zoo. Below is the process and problem statement that I observed.

    1. The fee for one adult is 50 Rs and child is 30 Rs for Electric car

    2. Tickets will be given only at the entrance of the Zoo that is located outside the compound wall (You will not know how many members are waiting for electric cars inside)

    3. Tickets once sold cannot be refunded or exchanged

    4. There are limited electric cars available to cater the crowd (I got the info that around 25 cars)

    5. Each ride takes 40 minutes. It will stop at various locations where you can get down the car and visit the animals and come back to go to next stop

    6. Each car can take up to 12 members including the driver (

    7. You have to get onto the car at only one starting location and get down at the same point after the ride is complete. If you want to give away the ride in between its fine up to you

     

    The problems I observed and want to solve these problems by applying lean principles:

    1. At the time of buying the tickets:

         a. I did not have any clue on how many cars are there inside

         b. How long each trip takes

         c. How many members are in waiting

         d. Whether I can take the car and leave it at some place and visit the animals and by the time I come back after my visit there can be some other car available to take me to next stop or not

    2. I had to wait more than 1.5 hours to get my turn to have a car available

    3. The driver told that if I can give him 300 Extra we can take our own time to visit and he will not mind (this is the primary cause of the long queues I observed)

    4. Weekend visitors are more than 2 times of weekday visitors

    5. The queue is not properly managed so at times I observed people are joining in the middle of the queue and making it even more worst

    What I want to resolve:

    1. Reduce the waiting time

    2. Address the loophole of extending the ride by giving bribe to the car driver

    3. Address the queue management inconsistencies

  • Liked Krishnamurty VG Pammi
    keyboard_arrow_down

    Krishnamurty VG Pammi - Lean Scrum - The need of the hour

    Krishnamurty VG Pammi
    Krishnamurty VG Pammi
    Agile Coach
    IVY Comptech
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    The 2015 state of scrum report published by Scrum Alliance states that the outlook of scrum is highly favourable. Virtually all consider it likely that their organization will use scrum in future. While this is good, the survey also noted one of the key challenges observed by survey respondents as “Product owners and teams were just not willing and/or enthusiastic about Scrum best practices”. Thus, although scrum methodologies have greatly increased productivity, scrum is not without its problems. We need to quickly address this gap.

    Keeping scrum values at the core, scrum methodology is mostly visible to teams on the ground in terms of three pillars (1) Scrum roles (2) Scrum artifacts and (3) Scrum events. While Scrum has kept scrum roles and scrum artifacts lean, it has empowered teams on the ground to learn the art of performing scrum. Scrum prescribed guidance on scrum events with clear purpose, frequency, maximum duration and recommended attendees. It recommends teams to learn the art of performing scrum events through their experience stating “scrum is easy to understand and difficult to implement”

    While some scrum teams mastered this art, I find most of the scrum teams are still struggling in this process. I come across situations where teams are not finding scrum events interesting primarily because they find these events unproductive. The result is that we see less interactions and cooperation from the teams during scrum events. This is impacting basic agile manifesto “Individuals and interactions over processes and tools". In net, there is no surprise when product owners and teams were just not willing and/or enthusiastic about Scrum best practices.

    Lean Scrum is the need of the hour. As part of lean scrum, we will adopt scrum methodology at the core and we implement lean framework to address the pain areas witnessed by teams

    As part of this talk, I will share my experiential insights on

    1. Outlook of scrum is highly favourable. Although scrum methodologies have greatly increased productivity, scrum is not without its problems. We need to quickly address these gaps
    2. While scrum has kept scrum roles and scrum artifacts lean, it has empowered teams on the ground to learn the art of performing scrum events. Are we keeping these events lean and Valuable?
    3. Lean scrum – The need of the hour
    4. What is Lean Scrum
    5. Anti-Patterns/Most frequently faced challenges/ wastes experienced by scrum teams in each of the scrum events (case findings based on my experience)
    6. Where do the scrum teams stand on "expected scrum patterns" in each of the scrum events (case findings based on my experience)
    7. Leverage "Lean Framework" to craft scrum events towards value generation. How to draw "AS-IS" and "TO-BE" Value stream management maps for two scrum events.
    8. Leverage "Lean framework" to help scrum teams to learn the art of performing scrum events through realizing value and enhancing their reach on "expected scrum patterns".
    9. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” The term value is increasingly becoming starting point of what we do. We need to keep questioning everything we do using customer value generation as the yard stick

    Unless, we drive scrum events towards value generation by continuously eliminating waste/ anti patterns, there is no surprise that “Product owners and teams were just not willing and/or enthusiastic about Scrum best practices” as observed by "The 2015 state of scrum" report.

    This is where Lean-scrum could prove to be powerful...

     

  • 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 Rahul
    keyboard_arrow_down

    Rahul - How to measure the outcome of Agile transformation?

    45 mins
    Case Study
    Beginner

    With many organization moving to Agile environment, it is important to have a model that can help us identify if the Agile Transformation is resulting in the expected outcome. This session would present different measurement models to measure the outcome of Agile transformation in an organization.

    The paper covers various measurement models that can be used during different phases of Agile transformation. The session also presents outcome of a survey conducted by the author on how different organizations, Agile coaches & leaders are measuring effectiveness of their Agile implementation. It would present a research on how different organization perceive success of Agile adoption, what are the parameters used by different organizations and how different people present the changes observed by adopting Agile environment.

    e.g. 20% respondents each said ‘Delivery cycle time’ & ‘Delivering business value’ as the key parameters. And other 20% mentioned ‘Working Software’ / ‘Customer Satisfaction’ & ‘Reduction in defects, waste & risks’ as the parameters for measuring success of Agile.

    The session also presents a case study of Agile transformation where these different effectiveness measurement models were applied successfully. It covers various aspects like Business case definition of Agile implementation, Agile Transformation roadmap, Agile readiness assessment, Agile current state assessment, Agile effectiveness evaluation and ROI of Agile implementation.

    The session would also include an Agile Innovation Game, where the attendees would brainstorm with their peers on how they currently capture the changes brought by implementing Agile in their organization.

  • 45 mins
    Talk
    Intermediate

    Effective "Code-branching" strategies are still one of the most ignored in Agile development world. In this talk, using case-studies, I would like to present what is wrong with traditional strategies, how it hinders teams to deliver continuously and why Trunk Based Development (TBD) is a durable solution. Furthermore, the talk aims to explore various strategies (code/dev and ops) that enable teams to attain TBD. Finally, the talk ends with successful TBD case-studies.

  • Liked Naveen Kumar Singh
    keyboard_arrow_down

    Naveen Kumar Singh - Large-Scale Scrum (LeSS) - Journey from component team to customer-centric feature team

    90 mins
    Case Study
    Executive

    Will share LeSS (Large-Scale Scrum) implementation journey and challenges encountered during transformation from component team to customer-centric feature team. Journey that covers defining product, building feature team through changing organization design and descaling organization through lean thinking. Talks will cover challenges in adoption and difficulties in retaining agile values beyond single team. Will also talk about key engineering practices that helped in resolving integration challenges and roles of management after adoption.     

  • Liked Krishnamurty VG Pammi
    keyboard_arrow_down

    Krishnamurty VG Pammi - Building Cross functional teams by example.

    Krishnamurty VG Pammi
    Krishnamurty VG Pammi
    Agile Coach
    IVY Comptech
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Cross functional team (CFT) as a whole has all the skills needed to build the product, and that each team member is willing to do more than just their own thing. Agile methodologies recommend long lived CFTs to implement agile manifesto and principles effectively. CFTs have become more popular in recent years for many reasons that include but not limited to:

    1. They improve coordination and integration
    2. They are flexible to adapt to changing market needs
    3. They develop innovative products more quickly
    4. They span across organization boundaries
    5. They improve problem solving and lead to more thorough decision making

    To be precise, we are not fully agile if we do not nurture CFTs. Not far from now, you will see digital enterprises trying to compete with each other in developing and releasing their apps every 5 days.  CFTs will become one of the fundamental pillars for agile methodologies to adapt to such aggressive future needs

    Building CFTs is an art and nurturing collaboration among CFTs is even more challenging. In this talk, I will explain about

    (1) Building Cross Functional Teams by Example

    (2) Nurturing Cross-functional Team Collaboration

    (3) Imperative elements that need to be considered for succeeding with cross functional teams. Without proper attention to these elements, any cross-functional team will be fighting an uphill battle to succeed.

     

  • Liked Krishnamurty VG Pammi
    keyboard_arrow_down

    Krishnamurty VG Pammi - Ineffective release planning makes teams oscillate instead of iterate

    Krishnamurty VG Pammi
    Krishnamurty VG Pammi
    Agile Coach
    IVY Comptech
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Although agile methodologies have greatly increased productivity, Agile is not without its problems. Agile recommends adaptive planning through its multi-level planning events. Agile planning is expected to remain relevant in guiding teams till their destination as it incorporates the then risks, issues, assumptions and constraints into consideration while planning at last responsible moments.

    While it appears good on paper, I find challenges involved in this approach. Scrum teams on the ground may mostly focus their efforts on their team specific daily and sprint targets. They lack common understanding of team expectations on what is probable product that they think is possible at the moment with the list of the then risks, assumptions, constraints and dependencies. To be precise, teams on the ground lack this bottom up view of the integrated probable product in next 2 to 4 months

    On the other hand, enterprises spend efforts and money for their strategy, portfolio and product planning exercises. The result is that these planning events tell the top down view of “Where Product owner want to take the product to be?”

    When top down view and bottom up view are not properly balanced with proper discussion among stakeholders during release planning exercise, we see teams oscillating instead of iterating witnessing below symptoms.

    • Teams slips on their release forecast
    • Cross team dependencies are detected towards end of the release and there was not much time available to resolve those dependencies within the release
    • Key decisions that were supposed to be taken during release planning exercise, would be taken up towards final sprints.
    • Risks are identified towards the end and this gives less room to mitigate the risks

    When these symptoms recur periodically, as an enterprise, we would not be in position to provide the expected functionality to the end users. This may ultimately hit team’s morale and enterprise brand. Part of this chaotic pattern may be attributed to agile planning events.

    This can be overcome if we perform release planning exercise effectively. But surprisingly, not much literature is available on how to perform release planning exercise even though everybody underlines its importance. In result, we see anti patterns keep creeping and they derail release planning objectives.

    In this talk, I will be listing potential probable anti patterns that can derail teams from achieving their expected outcomes. I will introduce each pattern in the format

    • Anti-Pattern
    • Potential Impact
    • How to address this anti-pattern

    If performed well, release planning exercise makes stakeholders meet together and discuss the challenges involved in unifying the top down understanding of “What the product Owner wants the product to be” with the bottom up understanding of “what the development teams thinks as the possible product scope that can be accomplished”. This inturn will be input to upcoming product planning events. Release planning thus acts as a guide post to baseline current understanding of team expectations on what is probable product that they think is possible at the moment with the list of the then risks, assumptions, constraints and dependencies.

  • Liked Madhavi Ledalla
    keyboard_arrow_down

    Madhavi Ledalla / Devesh Chanchlani - Autonomy in Teams - Why & How !

    90 mins
    Workshop
    Intermediate

    This is a fast paced workshop of 90 minutes, split across 3 progressive parts/activities. The intent of the workshop is to bring out the challenges that organizations face due to their traditional structure, during their Agile adoption journey. In the workshop, we emulate such an environment and try to have a first-hand experience of the difficulties faced both at the team and managerial levels (Part A). Subsequently, we let people form their own teams which are "Autonomous". (Part B). Now, we deliver as newly formed teams. (Part C).

    The final debrief revolves around importance of "Autonomous teams" in terms of quality and individual motivation.

  • 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 Raji Bhamidipati
    keyboard_arrow_down

    Raji Bhamidipati - Remote working in an agile world

    45 mins
    Talk
    Intermediate

    Remote working in an Agile world

     

    My experience of being a remote tester in an agile team

     

    Main statement:

    What does it mean to you/your colleagues/your company if you are a remote worker? How is it different to being an ‘office worker’? Let’s find out!

    Abstract

    Picture this!  – I landed a job with a company and team that I had wanted for a long time. Everything was going to plan until after about a year when I faced relocating to a far off land due to personal reasons. Imagine having to give up a job that you love and believe is going to be good for your career progression. Imagine working for a company that’s so awesome that, when I told them I had to move, they offered me the chance to become a full time remote worker!

    This was about 6 months ago and I have been a full time remote tester since then. I have learnt a lot during this time and want to share my experiences with you.

    Geographical limitations no longer stop people from working on awesome teams, or stop companies recruiting the right testers for the job. There are huge benefits for the remote worker and the company alike.  However, there are also drawbacks on both sides and remote working is not something to take lightly.

    At NewVoiceMedia we run a ‘Remote Working Community of Interest’ where we tackle some of the difficulties faced by remote workers as well as enjoy the benefits. To make remote working work there have to be changes made by the remote worker, the company and the colleagues who work in the office.  I want to present what these changes could be and could potentially mean to you, and your team.

     

     

     

     

  • Liked ShriKant Vashishtha
    keyboard_arrow_down

    ShriKant Vashishtha - Completely Distributed Agile - A Case Study

    45 mins
    Talk
    Advanced

    What about a case where the whole team is completely distributed, i.e. every team member works from home, possibly from a different country or from a different time-zones. What about the challenges faced by a team where team-members are distributed with 7-8 time-zones.

     

    In the new era of Lean Startup, some startups are working and developing software in this fashion. This session is a case-study of one such startup which is completely distributed. How they are working, are they using Agile or have evolved some new practices which work for them. What kind of different challenges these teams face on regular basis and how do they solve them, these are some of the question this session tries to answer.