Technical debt is a very common phenomenon; in fact it occurs with virtually every line of code whether you want it or not. Although unoptimized coding due to the rush presented by management pressure may be one of the major reasons for technical debt, it occurs in various flavors based on the nature of execution. Sometimes, even the best written code may run into debt by introducing a minimalistic change in the business definitions, e.g.: a variable name that makes no sense anymore.

This debt cause and effect is exponentiated when scaled teams come into play. In many cases these teams are distributed and an optimized code for one team may become a debt for another. These debt dependencies between teams is what creates the "Valley of Debt". Unfortunately these cannot be avoided but good engineering practices coupled with lean principles may keep them confined for long enough in order to push the validity of software applications.

Sooner or later, the cost of change will outweigh the benefit of an application and turn it into legacy; the challenge is to keep it as far as possible by slowing down the fall into the valley of debt. In this (non-PPT) interactive workshop, we will witness first hand how debts are introduced and how these can be confined by utilizing good engineering practices coupled with lean principles.

 
8 favorite thumb_down thumb_up 6 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

The session involves scaled teams moving and interacting with each other in order to deliver. It is not suitable for participants if:

  • The participant is wearing high heels or foot wear that can hurt others
  • The participant is pregnant
  • The participant has had a recent surgery or is unfit for performing physical movements
  • The participant is expecting a PowerPoint presentation and doesn't wish to have fun while learning

The session is divided into 5 short iterations that address:

  1. Enthusiastic developers adding technical debt under management pressure
  2. Principles to tackle management pressure and refactor to remove technical debt
  3. Understanding what is legacy code and good practices to avoid it
  4. Bringing it all together and finding synergy with continuous delivery
  5. Repeating 4 just for revision and a little more fun

The workshop is ideal for after lunch, wake-up & learn session

Detailed Outline:

This simulation is built around individuals part of scaled teams and working towards a common product. The teams are responsible for running parallel iterations of 2 minutes each, while working on the same product. There's a role play involved where I play a demanding manager who pushes the team towards delivering more and more.

After the first iteration we evaluate how a demanding management can burden a developer to inject technical debts. We introduce these technical debts as obstacles for our teams; we also clarify what defines a technical debt and various sources for introducing it. After providing anecdotes for removing tech debts (e.g. refactoring) we move on with the next iteration.

The second iteration works towards implementing the learnings from the first one as we remove the tech debt after each delivery, but obviously add new ones as we move along. The demanding management still pushes the team which possibly adds more debts than engineering practices can reduce. The evaluation works towards the agile principle to work at a sustainable pace indefinitely and this is where we discuss the meaning of legacy systems or when does a system become legacy.

The third iteration works towards maintaining a sustainable pace and engineering practices to defer the evolution of a legacy system. But this is where we introduce the possibility of syncing release cycles between multiple teams and making sure that early feedback is possible. The evaluation points towards CI/CD and shorter releases which we incorporate in our simulation for the fourth iteration.

The final iteration is more of bringing things together as a formal revision to avoid the valley of debt and elongating the life of one's system from becoming legacy. Followed by Q&A.

Learning Outcome

  • The nature & reasons for debt
  • Engineering practices to confine debt
  • Lean implementations for management
  • Interactions within scaled teams
  • Combining the above for longevity

Target Audience

Software Engineers delivering value and Managers / Leaders demanding value

schedule Submitted 11 months ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Prasad
    By Prasad  ~  11 months ago
    reply Reply

    thank you Vishal.. I like your approach of delivery. These kind of topics could never create an impact using ppt. I would like to understand how are your organising and using  45 minutes. 

    • Vishal Prasad
      By Vishal Prasad  ~  11 months ago
      reply Reply

      Dear Prasad,

      This simulation is built around individuals part of scaled teams and working towards a common product. The teams are responsible for running parallel iterations of 2 minutes each, while working on the same product. There's a role play involved where I play a demanding manager who pushes the team towards delivering more and more.

      After the first iteration we evaluate how a demanding management can burden a developer to inject technical debts. We introduce these technical debts as obstacles for our teams; we also clarify what defines a technical debt and various sources for introducing it. After providing anecdotes for removing tech debts (e.g. refactoring) we move on with the next iteration.

      The second iteration works towards implementing the learnings from the first one as we remove the tech debt after each delivery, but obviously add new ones as we move along. The demanding management still pushes the team which possibly adds more debts than engineering practices can reduce. The evaluation works towards the agile principle to work at a sustainable pace indefinitely and this is where we discuss the meaning of legacy systems or when does a system become legacy.

      The third iteration works towards maintaining a sustainable pace and engineering practices to defer the evolution of a legacy system. But this is where we introduce the possibility of syncing release cycles between multiple teams and making sure that early feedback is possible. The evaluation points towards CI/CD and shorter releases which we incorporate in our simulation for the fourth iteration.

      The final iteration is more of bringing things together as a formal revision to avoid the valley of debt and elongating the life of one's system from becoming legacy. Followed by Q&A.

      I've executed this simulation twice before and it's a fun way for knowledge sharing.

      • Leena S N
        By Leena S N  ~  11 months ago
        reply Reply

        Hi Vishal,

         

        I assume you are not planning for hands-on coding sessions for the participants in this.

         

        Tthe question is, as Prasad mentioned above, on how to manage it within 45 minutes, can five iterations fit within 45 minutes?

         

        • Vishal Prasad
          By Vishal Prasad  ~  11 months ago
          reply Reply

          Hi Leena,

          I'm not planning any hands-on coding; these are simulations and physical activities to demonstrate good engineering practices and improving software craftsmanship. The iterations are only of 2 minutes each, the evaluation for each iteration takes around 5 minutes. This allows for smaller knowledge packs and faster learning feedback. And another 10 minutes for Q&A and fillers.

          • Joel Tosi
            By Joel Tosi  ~  11 months ago
            reply Reply

            Hi Vishal,

               If there isn't coding, what will attendees be doing?

            As an attendee, I would be less interested in 'how debt is created' and moreso what to do about it.  Would you feel the same or is the first section still necessary?

            Best,

            joel

            • Vishal Prasad
              By Vishal Prasad  ~  11 months ago
              reply Reply

              Hi Joel,

              Thanks for your comment, I really liked the second part of your question because it reminded me of a conversation I once had with one of my managers :)

               

              Your user story is:

              As an attendee, I would be less interested in how debt is created and more so what to do about it. Is the first section still necessary?

               

              My manager's user story was:

              As a manager, I would be less interested if the application is tested and more so if the programming is completed (that was his definition of done). Is the first section (of TDD) still necessary?

               

              In my humble opinion, both of these stories will lead to a technical debt. I believe that understanding the problem is more important than finding the solution, and skipping the first section in both of the above stories, skips the fundamentals of what we're trying to solve. This workshop is less about learning how to remove technical debt and more about identifying how these can be avoided in the first place. The identification of how the problem of technical debt gets introduced holds the solution to resolve it as well.

               

              What will the attendees be doing?

              The attendees are a part of a simulation, a game designed to mimic a real world scaled software development team(s). These teams are led by a demanding business representative (that would be me because of my varied experience of being on the receiving end), working on a single product backlog with dependencies between teams. I purposely introduce situations in every iteration and hope that it introduces scenarios for technical debt (which usually happens). Every time a debt is introduced, I create a small dent in the path for the team members to move around. The more the debts, the more the dents, the deeper the valley becomes (based on the explanation of the iterations provided above). These are accompanied by anecdotes about improving practices that help remove debts and every time the team removes a debt, I remove a dent, and the depth of the valley reduces.

               

              The idea behind this workshop is not only to teach practices for removing debt but making the participants think about the change in style of working that is necessary for avoiding debts in the first place. Hence no coding. This simulation would be similar to teaching agile software development or test driven development using Lego toys instead of a laptop. Hope this provides the necessary insight about this workshop.

               

              Regards,

              Vishal

               

              P.S.: Please ignore the dry humor in my comments


  • Liked Nilesh Kulkarni
    keyboard_arrow_down

    Nilesh Kulkarni - Why one size doesnt fit all? - Selecting scaling framework.

    Nilesh Kulkarni
    Nilesh Kulkarni
    Senior manager PMO
    Allscripts
    schedule 11 months ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Why one size doesnt fit all?  - Selecting scaling framework.

    This session will focus on what are the aspects organizations should consider when they want to scale agile implementation in organization.  There are several frameworks out there like SAFe, LeSS, Spotify, and so on. what is it that organization is trying to achieve and how a systematic approach of scaled agile implementation can help the organization.

    Attendees will be able to understand what aspects should be considered before organization decides to scale agile.  How to scale agile and when to do it largely depends on what organization is trying to achieve. Each organization is operating it in different way so there is no defined formula or framework that will work for all. But guidelines from this session will help the members to identify their needs and then take further action.  These guidelines can help the organization to successfully scale agile irrespective of which framework is selected.

  • Liked Vishal Prasad
    keyboard_arrow_down

    Vishal Prasad - SLICE - The Experimentation Framework

    Vishal Prasad
    Vishal Prasad
    Project Manager
    Springer Nature
    schedule 11 months ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Agile Principle # 12 defines that at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. From Scrum to Kanban and other agile frameworks, this is accomplished through retrospectives and continuos improvement processes. The key to being a successful agile practitioner is to identify areas of improvement and then experiment ways of improving it. But it doesn't stop there; positive improvements ultimately become success stories for other teams and motivates them to experiment with newer ideas which eventually leads to innovation. A negative outcome isn't bad either since it adds to the experience of situations where ideas may not apply. Thus the key to this process lies in being a child, an explorer, and inculcate an experimentation mindset. The SLICE framework addresses this in the following way:

    • S hare: Share an area of improvement
    • L earn: Explore the area for ways of improvement
    • I mplement: Search & apply the learning to identify the success factors
    • C ollateral: Publish blogs, white papers, presentations, etc. as observations of the implementation
    • E xpansion: Grow, Seed, and Split in order to explore new venues for success

    In this workshop, I create an environment that inculcates an experimentation mindset and utilize the SLICE framework to drive the exploration.

  • Liked AnkitTandon
    keyboard_arrow_down

    AnkitTandon - DIY Scaling Agile Framework

    AnkitTandon
    AnkitTandon
    Scrum Master
    Citibank
    schedule 10 months ago
    Sold Out!
    45 mins
    Workshop
    Intermediate

    Is the scaling framework your organization is on helping you to be Agile or pretend to be Agile? How about drafting one that stays true to Agile principles and helps with what your organization needs most while scaling

    While there are a many frameworks available to scale Agile it is important to see if these prescriptions address the real problems that an organization have while scaling up.  Does one size fits all? Is it worth adopting a framework and then retrofitting your organization into it or it makes more sense to understand the dynamics of your organization, the existing challenges and business objectives and carve out a scaling approach, keeping Agile principles intact, that suits the organizations needs best.

    This interactive workshop is about discovering the best approach to create your own scaling framework, one that is custom made to respond to your organization’s needs. 

  • Liked Vijay Wade
    keyboard_arrow_down

    Vijay Wade / Manjunatha M S Rao - Sick and Tired? You don’t need a Physician: Try Personal Kanban

    90 mins
    Workshop
    Intermediate

    All of us are simply getting stressed because of multiple events happening in our life and hence we are not able to achieve the greatest goal of our life in time and sometimes never.

    This session I shall talk about why this is happening to you and what is the solution.

    Idea of this session is to shed some light on power of Personal Kanban and real life examples to save from being Sick and Tired 
    Kanban can be implemented in most walks of life. Knowingly or unknowingly few of us use it in few aspects of daily routine.

    It would be focused on ways to improve productivity in your life and achieving your goals and biological and psychological aspect of it....

    It would be a workshop mode session where in we would understand whats happening to us in our life and activities that lead us in this situation and will figure out how to get out of this and lead to successful life (Personal and Professional).

  • Liked Kamlesh Ravlani
    keyboard_arrow_down

    Kamlesh Ravlani - Agile at Scale For Innovation and Growth

    90 mins
    Workshop
    Intermediate
    Bringing innovative and breakthrough ideas to market doesn't have to slow down due to multiple geographies and scale of product development. In fact that's an added reason to be agile, test the product-market-fit early and reduce risk. 
     
    How can organizations benefit from being Agile at Scale For Innovation and Growth? 
     
    What are the wastes in the traditional organizational structure at scale? and What does it take to build customer value delivering feature teams?
     
    We'll dissect a case-study, Kamlesh Ravlani - the presenter, was involved with and learn how Google brought one of their innovative idea rapidly to market that involved multiple partners and teams in multiple geographies.
  • Liked Manjunatha M S Rao
    keyboard_arrow_down

    Manjunatha M S Rao / Sriharsha B / Vijay Wade - Agile Clinic – Strengthen Your Organization Agility

    45 mins
    Experience Report
    Intermediate

    When a company thinks about transformation or a change from legacy traditional software development models to Agile, they first think of bringing in External coaches or Scrum experts. In another situation when the companies want to increase their maturity in agile, they still will want to hire people from outside who are experts in this arena. This discussion is all about how we could groom people internally to sustain and increase the credentials within the organization rather than relying always on external coaches.

  • Liked Vijay Wade
    keyboard_arrow_down

    Vijay Wade / Manjunatha M S Rao - Study of Agile Practices Implementation in Distributed Software Development

    45 mins
    Original Research
    Beginner

    This session is intended to provide an overview of status of agile implementation practices.  The findings are based on survey data collated from selected agile practitioners from 14 different software organizations spread across the globe. The survey was designed based on agile manifesto and Twelve Principles of Agile Software Development and most commonly used Agile Scrum and XP practices. The survey includes 54% of response from new product development, 32% from enhancement projects and remaining 14% from maintenance and support projects. Results are summarized as most effectively implemented practices, most widely recommended practices, least implemented practices and practices which always need modifications / tailoring based on any given project or organization environment.  

    The objective of this study is following

    • To do an in-depth analyze of implementation of established agile practices from practitioners point of view based on data collected from the survey.
    • Understand any correlation the survey results are having with the already conducted surveys and published literature on Agile practices
    • Provide food for thoughts to practitioners community to fine tune or elaborate agile practices which may lead to update of standard reference materials

     

     

     

     

  • Liked AnkitTandon
    keyboard_arrow_down

    AnkitTandon - Agile contracting- Starting with the right mindset

    AnkitTandon
    AnkitTandon
    Scrum Master
    Citibank
    schedule 11 months ago
    Sold Out!
    45 mins
    Workshop
    Executive

    One of the biggest challenges in achieving agility is the way contracts are written. More often than not, these contracts prove to be a deterrent to realize the ultimate benefits of Agile. The way contracts have done traditionally usually go well with the traditional way of building software where scope / time / cost are fixed. However when the focus is on delivering business value early to the customer for his competitive advantage, to reduce risk, cost by not building what is not needed, gain and retain users, traditional contracting does not help the cause. Agile is something that the entire organization has to embrace. It has to start with the sales team. It has to reflect in the contract. It has to start with the right mindset. It has to start with an Agile contract.

    Third value of Agile manifesto is Customer collaboration over contract negotiation. Not only should this collaboration be expressed during project development, it should be expressed in the contract language as well.

    In this talk + workshop session, I will be sharing various types of contracts that can be leveraged / customized for an Agile project, some good practices surrounding them and will be involving the participants into a small workshop of writing Statement Of Work (SOW) for Agile contracts related to a few real world scenarios.

  • Liked AnkitTandon
    keyboard_arrow_down

    AnkitTandon - Performance management in Agile: Time to plug the hole

    AnkitTandon
    AnkitTandon
    Scrum Master
    Citibank
    schedule 11 months ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Principles behind traditional performance management system are utterly opposite to that of Agile. While traditional one focuses on Individual ratings, surprises, one sided evaluation, Agile is built on the foundation of trust, transparency, respect and courage. Whole is greater than sum of its parts and individual ratings and outdated performance management processes may prove to defeat the bigger purpose. While aspiring for Agility both at team and organization level, it is important to ensure all the wheels are moving in tandem in the same direction. Technology has changed the way our people engage, work and communicate and the need for frequent and less formal points of progress reviews is in demand.

    Agile performance management is an attempt to plug the hole by providing an approach that compliments Agile values and proves to be a catalyst than detractor for a high performing team and organization.