Knowledge Era Paradigms - Fundamental Rationale behind Agile

schedule Mar 15th 10:30 AM - 11:15 AM place Esquire

In our coaching/consulting engagements we notice that when organizations embark on Agile transformation, typically they focus on the mechanics, ceremonies, tools - addressing 'what' to do and 'how' to do. There is less focus on 'why' certain practices should be done - the fundamental rationale behind Agile. Without understanding the rationale, instead of applying the Agile Principles & Values in the right context, organizations tend to make it a prescriptive process. Such Agile implementations are sub-optimal, often counter-productive, as true culture change does not happen.

This talk brings focus on 'why' aspects of Agile - fundamental rationale behind Agile. It shows how the traditional software production was influenced by the Industrial Era thinking, the changes needed in Knowledge Era context and how Agile provides the scaffolding to build true Knowledge Enterprises. 

 

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

Outline/structure of the Session

The talk covers the following topics (please see the presentation for details):

- Characteristics & contrasts of Industrial Era businesses & Knowledge Era businesses

- Five key paradigm shifts in Knowledge Era:

  - From Repeatable Processes to Contextual Processes

  - From Process-driven to Principle-driven practices

  - From 'Touch time' of tools to 'touch time' of minds

  - From Supervised to Self-managed individuals & teams

  - From Measuring to Sensing

The talk is interactive with provocative questions & exercises. 

 

Learning Outcome

The talk drives home the understanding of software production being very human-centric & knowledge-driven and how the engineering & management practices need to incorporate these aspects. It helps the practitioners, managers & leaders to apply Agile in true spirit and make the culture change faster & long lasting. 

Target Audience

Practitioners, Managers, Leaders

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Naresh Jain
    By Naresh Jain  ~  2 years ago
    reply Reply

    Hi Vishweshwar, Can you please provide a working link to a video from any past presentation?

    • Vishweshwar Hegde
      By Vishweshwar Hegde  ~  2 years ago
      reply Reply

      Hi Naresh,

      Though I have been giving several talks/presentations, I haven't been tracking to get the videos from those sessions. Will try to get some of them. Some of the presentations in the recent past:

      - In SLASSCOM (Sri Lanakan Assocociation for Software & Services Companies, similar to NASSCOM) in Colombo on Agile & DevOps last month

      - BSPIN Webinar hosted through Wipro last month on 'Changin role of Process & Quality Functions in the context of Agile & DevOps movement' where 300+ participants joined on WebEx and more on audio (as WebEx ports were not sufficient)

      - 'Decoding DevOPs' conference in Bangalore in April.

      - In Agile Ledership Network at Manyata Techpark few months back (ref: Thatagat Varma, Ravikumar)

      - And within many individual corporates 

      I'll try to get the video from some of them.

      Thanks

      Vishu Hegde

  • Anish Cheriyan
    By Anish Cheriyan  ~  2 years ago
    reply Reply

    Hi Vishweshwar,

    Thanks for the topic. Can you please share some specific cases or examples for the five paradigm shifts:
      - From Repeatable Processes to Contextual Processes
      - From Process-driven to Principle-driven practices
      - From 'Touch time' of tools to 'touch time' of minds
      - From Supervised to Self-managed individuals & teams
      - From Measuring to Sensing

    Regards,
    Anish Cheriyan

    • Vishweshwar Hegde
      By Vishweshwar Hegde  ~  2 years ago
      reply Reply

      Hi Anish,

      Thanks for the comments. The examples for each of the paradigm shift will be brought out during the presentation as talking points. Here are some examples:

      - From Repeatable process to Contextual process: Rather than forcing same templates & steps for all projects in traditional software development approapproach to empowering team processes & norms to emerge in Agile projects based on the context of that project/team.

      - Process-driven to Principle-driven practices: Typically in traditional approach, defect prevention techniques (CMMI Level 5) are driven through organization wide common checklists. When project/team variabilities are high (as in software projects), it doesn't work and teams hardly find those cheklists relevant in their contexts. Instead in Agile projects, the short iterative cycles with quick feedback loops and learn & adopt through retrospectives which are drivn through Agile principles, serve as mcuh moe effective defect prevent mechanisms.

      - From 'Touch time' of tools to 'touch of minds': In software development context, the transformation from raw material to finished products really happens in peoples minds - computer is only a tool to capture that. In traditional softeae development there has benn significant emphasis on logging time and deriving productivty measures from that. An engineer can log 8 hours, but his/her mind could be totally somewhere else (low wmotivation,  inerruption, ...). What really matters is how much the engineer's mind is engaged in transforming the raw material to finished product. Toucn time of mind (peoples level of engagement) really drives productvity & quality. In Agile several aspects drive the touch time of mind: building an environment of teams taking ownership & self-managing, scrum master helping the team to focus by removing obstacles & preventing interference, etc.

      - From supervised to self-managed:  Since the transformation of raw materil to finished product is happening in peoples mind, if someone from outside has to supervise & mange that process, the supervisor has to constantly keep checking with the engineer what is happening his/her mind - which is practically not possible. Encouraging people to take owernsip and self manage, brings the best out of individuals & teams.

      - From mesruring to sensing: As shown in the iceberg metaphor, most of the traditional metrics are like tip of the iceberg and are lag measures - for example schedule slippage, effort varience, defect containment etc. These have already happend; project teams can not do much with that now; they can analyze them for future improvments, but can not use them for mangeing the current project. But what contribute these outputs and which make or break projects are typically the invisible bottom of the iceberg like the motivation, expereince, collaborion, shared vision... in the team members. These are not very measurable, but they can be sensed. Managers/Leaders can sense the motivation, energy, communication, collaboration, ... by 'management by walking around' techniques - actually obsrving teams in action. These are mcuh more lead indicators which can be acted upon. 

      These are some examples. But the talk will bring out more such connects.

      Does this answer yur question?

      Thanks

      Vishu Hegde

       


  • Liked Vishweshwar Hegde
    keyboard_arrow_down

    Vishweshwar Hegde - The invisible, intangible bottom of the DevOps Iceberg

    45 Mins
    Talk
    Intermediate

    It’s a known fact that only 10% of the iceberg is visible and 90% is submerged & not so visible; what moves the iceberg is not the externally visible winds, but the subtle undercurrents beneath the surface. Similarly more than the hard, visible aspects like processes & tools, what makes or breaks DevOps is the soft aspects of people, leadership & culture, like self-organizing teams, collaboration across the organization at all levels & servant leadership. The talk elucidates some of the critical success factors in these areas while adopting DevOps.