The principles of agile are so simple that its simplicity eludes many practitioners. Pulling in a white board with sticky notes, writing user stories instead of business requirements document, avoiding developing any document, and use of some agile popular tools does not mean that agile has been implemented. 

In this presentation, I provide an approach to how agile transormation begins. Fundamental to agile is the self-organization and if one doesn't think (T) agile, become (B) agile by following the recommended steps, and develop (D) on practices to refine agile in the specific industry, agile will not solve the business challenges. The personality traits of those leaders that attempt to transform into agile will lead to incorrect implementation.  Often, in such cases if Agile fails, it is because we failed agile! 

Breaking on the TBD approach, this presentation will explore additional topics that start with us, team, and the organization to truly transform into agile methodology.

33 favorite thumb_down thumb_up 14 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session

  • 5 min - Introduction
  • 10 min - Leadership Challenges to Agile Implementation
  • 10 min - TBD Framework
  • 15 min - Agile Transformation starts with you, team, and organization
  • 10 min - Q&A and Summary

Learning Outcome

  • Self-evaluation
  • Team evaluation
  • An individual development plan for the TBD
  • Training opportunities for the new roles for the agile transformation

Target Audience

Product Owners, Project Managers, Account Managers, Program Manager, Team Leader, PMO Managers

schedule Submitted 4 years ago

Comments Subscribe to Comments

comment Comment on this Submission
  • Tathagat Varma
    By Tathagat Varma  ~  2 years ago
    reply Reply

    Sriram, I would be interested to learn of applying this 'model' into a real-world problem and sharing those experiences. Can you share more on that?

    • Sriram Rajagopalan
      By Sriram Rajagopalan  ~  3 years ago
      reply Reply

      Hi Tathagat,

      First, my apologies for the delayed response. 

      In a response to Doc Norton, I expanded on this model further. While the concepts of the ToBeDone (TBD) is fairly straight forward, I will share my personal real world experience. 

      1. In one of my earlier organizations where we delivered notifications to the clients, we began using agile. Little to no agile training was provided to any of the team members. I was not fully Scrum Certified at that point and faced the challenge as a Project Manager of getting the team to deliver in iterations. How could the team practice agile when we couldn't think agile? The seeds of self-organization however was present that a member of the team and I attended a number of sessions on our own and together at places likes Thoughtworks, webinars, etc. so that we can bring that cumulative knowledge to the team to meet the expectations. 

      2. Expanding on these, I recognized the need to learn agility and scrum in detail where the journey continued - becoming agile. I experimented these beyond software development where I also taught some of these principles at 6th-7th grade students in the first lego league in their implementation of robotic programming and their community projects. Seeing the self-organization and collaboration at such a level where they formed their own tasks, timeline to complete, dividing work among themselves and using tools like Trello to work in a distributed enviornment was great. 

      3. With this continuing journey, I started my own networking sessions bringing subject matter experts and lean coffee type of discussions in my community. As I develop agile for the community, I develop myself. I brought these learnings to my organization in various teams as well. 

      Although I am answering you at a personal level leaving the organization and team specific things I have addressed to ensure anonymity, I hope you can relate to this. If you still have any question, please let me know. 


      • Jerry Rajamoney
        By Jerry Rajamoney  ~  3 years ago
        reply Reply

        Hi Sriram,

        Thanks for the response. If you take away the "Scrum" part from the response how it add value? I am sure you agree that there are many others ways you can be Agile. Do you have more points to share to show the mapping between TBD to Agile Transformation?


  • Ram Srinivasan
    By Ram Srinivasan  ~  4 years ago
    reply Reply

    Hi Sriram,


    Thanks for submitting a proposal. Can you please elaborate on your proposal, more specifically, the sub-topics? Why is it challenging for leadership to adopt Agile? How does TBD help? What is TBD framework?



    • Sriram Rajagopalan
      By Sriram Rajagopalan  ~  4 years ago
      reply Reply

      Hi Ram,

      Greetings and thanks for the great questions. As organizations embraces agile, very often challenges arise when the leadership team fails to embrace the self-organized team structure allowing the team to collaborate. These challenges can be grouped into six different categories ( I am summarized these below.

      1. Resistant: Generational gaps with conventational management styles unwilling to embrace change
      2. Never heard of Agile: Their unfamiliarity with Agile is marked by the missing drive to learn current trends and implement the transformation
      3. Big Vision: This group is willing to experiment new ideas but limit their delegates to business transformation
      4. Misinformed: This group has experienced some failure and hasn't resorted to enhanced learning from failure and adapting changes
      5. Metric Oriented: This group uses the conventional metrics to evaluate agile product development comparing one agile team to another and drawing incorrect references
      6. Insufficient experience: This group draws on expertise of other members but fails but these leaders fail to properly assess the organization and its industry requirements to properly implement agile instead of bringing in the same tools, processes, and technologies from their previous experiences

      These above reasons lead to leadership not understanding the fundamental agile principles. Here is where I propose TBD because leadership is an ingredient in self-organized teams and is not attributed to top management. I believe every individual in the organization is capable and responsible to highlight the proper implementation of agile but several fall into what the organization should do to them to implement instead taking it on themselves. So, I propose TBD framework where the thinking, becoming, and developing becomes an integral framework for individuals to enterprises to challenge the transformation towards successful implementation. 

      Please let me know your thoughts.



      • Doc Norton
        By Doc Norton  ~  3 years ago
        reply Reply

        Following up on Ram's comments - Can you make the TBD framework a little more concrete? I believe I understand what it is to think, become, and develop, but don't believe I understand what this framework actually is. What are some of the tools/techniques/activities that one might us in each stage? Are these stages?


        I am also unclear on the presentation itself. When does the Individual Development Plan activity occur? You're largest time slot is 15 minutes and it covers individual, team, and organization. Is this were you also run an IDP session at the tables?


        • Sriram Rajagopalan
          By Sriram Rajagopalan  ~  3 years ago
          reply Reply

          Hi Doc,

          Thanks for the note.  Agility revolves around self-organized teams. This means the change needs to come from within the individuals that make up first. Based on experience, when the individuals don't step out of the comfort zone and the organizational fabric is not setup for individuals and team to fail fast and learn from that failure to adapt, agility will not succeed. Predominant literature in agility transformation starts with leadership to establish a culture. While that is definitely required, I approach it from the individuals to wake up and smell the industry changes and adapt. As a tool for this, I recommend the ToBeDone (TBD) approach. 

          I challenge the conventional thinking of thinking of these as linear stages. This is exactly what made the original software development model as a linear thinking. These are continuous improvement paths where depending upon the career stage that an indivdual is in, they have to evolve in one or more of these paths. But, all the three are required for the transformation.

          For instance, say you are at the QA member in an organization that is trying to adopt agile. If this individual chooses to ignore being part of the design and "think" of the test driven development stages succuumbing to the conventional thinking, then the individual is not failitating the success of the team adopting agile. Alternatively, consider a customer-facing account manager or project manager in the middle management in a team evaluating agile. If these individuals refer to RACI and avoid "becoming" invovled in acceptance testing, they will not be able to get new features and refinements from the customer creating delays in product improvement and customer satisfaction as the product backlog is groomed. Now, consider upper management like a Vice President of Development. If this individual doesn't relate to the use of documentation requirements in a regulated environment and doesn't "develop" the agile principles to the industry demands, then, the individual is not contributing to agility. 

          What are the tools? There are many personal development tools that can aid in every one of these stages and these need not be reinvented. Examples include your own SWOT analysis, 5W1H (Who, what, when, where, why, How), Personal Reflective Grid, Situational Leadership grid, Balanced Score card, etc.  

          The way I plan to use my 15 min slot during individual, team, and organizational agile transformation section is to form some tables represent individual, some tables represent  team, and some tables represent organization. Then, I plan to have members in the table engage in a dialogue so that tables in the individual group recognize something that need to learn more about agile that they don't have much exposure to (thinking), members in the "team" level start discussing about their own team challenges and come up with an action item to address by their own training initiatives (becoming), and finally the membres of the organization table discuss what they can do develop agile (bringing more networking events themselves to the organization, using community projects with agile principles, etc.)

          The takeaway I want to leave individuals in the session with is an action item that they individually want to accomplish. 

          I hope this makes sense. Please let me know if you still have any question.




  • Ramesh Nagarajan
    By Ramesh Nagarajan  ~  3 years ago
    reply Reply

    Very interesting Sriram, looking forrward to hearing more.

  • Mani Gunasekaran
    By Mani Gunasekaran  ~  3 years ago
    reply Reply

    Think Become Develop Agile! Good luck Sriram.

  • Brian Peters
    By Brian Peters  ~  4 years ago
    reply Reply

    Good Job Sriram.  I found it interesting.

    • Sriram Rajagopalan
      By Sriram Rajagopalan  ~  3 years ago
      reply Reply

      Thanks Ram & Everyone. I don't envision this approach to replace Scrum. An essential ingredient for agile and scrum to succeed is the self organized team. If the team has the transactional mindset and don't have a self-initiated development plan, then their agile journey won't scale with the organizational needs. So, my approach is an individual's agile tool similar to INVEST and DEEP as means to characterize user story and product backlog. 


  • ram iyer
    By ram iyer  ~  4 years ago
    reply Reply

    Hi Sriram,


    Great job!

    I encourage your idea of "bottom up" approach. My question to you, would you envision TBD, a framework that supplements SCRUM?

    Wish I could attend the conference. 


  • Raju K
    By Raju K  ~  4 years ago
    reply Reply

    TBD was misleading at first. But later found out what it meant. I support your idea. Looking forward to the event.

    • Sriram Rajagopalan
      By Sriram Rajagopalan  ~  4 years ago
      reply Reply

      Thanks Raju. Yes, I didn't think of TBD myself but it evolved. I thought of doing ToBeDone but felt TBD will raise curiosity. Appreciate your feedback.


  • Liked Fred George

    Fred George - Enabling Emergent Technologies

    Fred George
    Fred George
    Fred George Consulting
    schedule 4 years ago
    Sold Out!
    60 Mins

    The latest new, cool tool comes along. Will you be allowed to use it? Probably not! So how can you change that?

    This presentation looks at the introduction of new technologies at three companies, The Forward Internet Group in London (a start­up originally, now grown to 400+); MailOnline, the online version of the Daily Mail newspaper from London (a very old organization with an existing IT shop); and Outpace, a Silicon Valley startup.

    In both cases, Programmer Anarchy was introduced. This managerless process (not unlike GitHub in its value propositions) empowered the programmers to make technology choices and to freely experiment with new technology. In the case of Forward, massive growth and profits ensued. In the case of MailOnline, re­development of core systems into new technology has been launched, and expectations significantly exceeded.

    This presentation will touch on the various aspects of implementing Programmer Anarchy at MailOnline:

    • Team building through programmer training

    • Pilot project without managers, BA’s or dedicated testers

    • Reinforce the model with new HR structure emphasizing skills over titles

    • Create self­organizing teams of 5­8 developers (multiple such teams)

    • Charter teams with a specific project, and let them deliver

    • Avoid artificial schedule pressure

    The intent is to provide a possible roadmap to get your latest technical toys moved into production systems. 

  • Liked Patrick K Phillips

    Patrick K Phillips - Understanding Lean and How it Can Scale Agile

    60 Mins

    Is business process improvement part of Lean IT? What about best practices and benchmarking? Is agile software development a Lean IT practice? What about IT operational excellence and the ITIL service management framework? How about performance management dashboards and scorecards? Is applying Lean techniques to project management considered a Lean IT practice? And is cloud computing relevant in a Lean IT world? The answer to all these questions is yes. But Lean IT is much more than just a set of tools and practices; it is a deep behavioral and cultural transformation that encourages everyone in the organization to think differently about the role of quality information in the creation and delivery of value to the customer.

    Lean IT enables the IT organization to reach beyond alignment toward fundamental integration, cultivating an inseparable, collaborative partnership with the business. Whether you are new to Lean, or a seasoned veteran, in this book you will find new insights into the power of Lean and the critical impact of an integrated IT function. In this discussion Patrick Phillips will explore all aspects of Lean IT within two primary dimensions:

    Outward-facing Lean IT: Engaging information, information systems, and the IT organization in partnership with the business to continuously improve and innovate business processes and management systems

    Inward-facing Lean IT: Helping the IT organization achieve operational excellence, applying the principles and tools of continuous improvement to IT operations, services, software development, and projects These two dimensions are not separate but complementary.

    The adoption of the term Lean software development is more than a name change. While agile is a set of development and life cycle management tools and methods focused on the just-in-time development of quality software, Lean software development addresses a larger context: the environment within which the software operates, the value streams of the enterprise. For example, in a business application, properly functioning software is viewed as a supporting element of the business process. In an embedded software application (such as the operating system of a smartphone or the control systems of a jet aircraft), the software is part of the overall product design and value proposition to the customer. Lean emphasizes seeing the whole through the eyes of the customer, not its component parts through the eyes of the designer or developer. “Lean software development views all Agile methods as valid, proven applications of Lean thinking to software,” says Jeff Sutherland, a signer of the Agile Manifesto. “It goes beyond Agile, providing a broader perspective that enables Agile methods to thrive.”

    In the words of Mary and Tom Poppendieck, “A Lean organization optimizes the whole value stream, from the time it receives an order to address a customer need until software is deployed and the need is addressed. If an organization focuses on optimizing something less than the entire value stream, we can just about guarantee that the overall value stream will suffer.” We have witnessed many skilled agile practitioners fall into the common Lean trap: focusing on tools and techniques rather than solving problems and eliminating waste. Lean software development expands agile’s focus from optimizing the software development process toward improving entire value streams. Thus, Lean software development must integrate and synchronize with all business processes, management systems, and kaizen activity, supporting the Lean transformation of the overall enterprise.  This session will take you into a discussion with a practitioner who is one of the industry's leading figures in understanding and utilizing lean. 




  • Naresh Jain
    Naresh Jain
    schedule 3 years ago
    Sold Out!
    90 Mins

    In order to achieve my goals, as a buyer of your product, I want awesome feature.

    AT: make sure your users stories don't get in the way.

    Users Stories, the tool teams use to break big ideas into small demonstrable deliverable, are easy to describe and challenging to write effectively. In this hands-on workshop you'll learn how to write great user stories that adhere to the INVEST principle. We'll learn various techniques to slice your stories using the vertical-slicing approach. We will discuss what elements should be included in the stories, what criteria you should keep in mind while slicing stories; why the size of your user story is important and how to make them smaller and efficient.

  • Liked Raju K

    Raju K - Applying Agile Material Science for High performance teams

    45 Mins

    Human body is made of lot of materials. Mother Nature has natural science properties and wonderful logic on these materials. In this presentation, I present how we can Identify the good materialistic science properties that Humans possess, how we can leverage and encourage them to build high performance teams.

    Using a natural way to groom your team members, motivate them to deliver and work together towards success. You will be surprised to know how by having a deep understanding of these properties, you can transform an ordinary individual and medicore teams into highly charged, motivated and super delivery teams.

    Nature is awesome. So are humans. Come and join me in using a natural way to build high performance teams.