Ineffective release planning makes teams oscillate instead of iterate

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.

 
65 favorite thumb_down thumb_up 7 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

(1) Why release planning exercise is significant?  - What can be potential impact felt if there exists a mismatch between 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”.

(2) List of potential and probable anti patterns that can derail teams from achieving their expected release planning exercise outcomes.

(3) Potential probable anti patterns in detail

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

(4) Key Levers for successful Release Planning exercise

(5) Conclusion - If performed well, advantages with successful release planning

Learning Outcome

(1) Why release planning exercise is significant?  - What can be potential impact felt if there exists a mismatch between 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”.

(2) List of potential and probable anti patterns that can derail teams from achieving their expected release planning exercise outcomes.

(3) Potential probable anti patterns in detail

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

(4) Key Levers for successful Release Planning exercise

(5) Conclusion - If performed well, advantages with successful release planning

Target Audience

Scrum masters, Product owners, Development Teams

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Balaji.M
    By Balaji.M  ~  1 year ago
    reply Reply

    Hi Krishnamurthy,

    Please can you share the draft version of the deck which you would be using for the talk

    also, please can you brief the anti-patterns which would be discussed during the session.

    Best Regards

    Balaji.M

    • Krishnamurty VG Pammi
      By Krishnamurty VG Pammi  ~  1 year ago
      reply Reply

      Hi Balaji,

      I have uploaded my draft presentation @ https://drive.google.com/file/d/0B2mjbui65byOUnNPdE00c3ZuYVU/view?usp=sharing. Plesae let me know incase you see any issues in accessing the link

      Regards,

      Krishnamurty

    • Krishnamurty VG Pammi
      By Krishnamurty VG Pammi  ~  1 year ago
      reply Reply

      Hi Balaji

      I am currently preparing my draft slides. The key anti patterns include but not limited to,

      1.    Clarity missing on “why we perform release planning exercise?”

      2.    Teams do not know what they are expected to achieve at the end of release planning session

      3.    Teams on the ground, are not aware of their  product vision

      4.    Teams are not aware of product roadmap outcomes and themes (or guided goals) for current release planning exercise

      5.    Area wise product back log is not prioritized and most of the backlog items are coarse grained

      6.    Prioritized backlog does not have story points for most of the stories by the time they attend the release planning session

      7.    Acceptance criterion missing for most of the stories and team works with product owner to establish acceptance criterion that covers functional and nonfunctional goals during release planning session

      8.    Individual teams come unprepared for the release planning meeting and thus discovers 95% of dependencies, risks and issues during release planning session

      9.    Required stakeholders are not invited to the release planning event

      10.  Invited “key” stakeholders do not attend the release planning exercise

      11.  Teams does not prepare the release planning room with updated information radiators before start release planning exercise

      12.  Teams are not updated with release planning agenda

      13.  Team performs release planning exercise whenever stakeholder in power visits their site instead of performing the function at the expected periodicity

      14.  Team wise Definition of Done” and “Definition of Ready” are not kept current

      15.  Teams take their respective optimistic velocity into consideration while forecasting

      16.  Release planning event opening was not performed with key stakeholders does not open the release planning exercise with product vision, progress and release goals

      17.  Team does not take participant feedback into the planned agenda before start of the release planning exercise

      18.  Working agreements are not formed for effective release planning facilitation

      19.  Team conversations does not address challenges involved in bridging the gap between 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”

      20.  As a team, business and development team does not perform trade-off decisions when required

      21.  Team notes cross team dependencies, risks, issues at the “end” of the session

      22.  Team does not note the decisions taken during release planning event

      23.  Other locations are unable to contribute to release planning exercise

      24.  Baselined release planning artifacts are not communicated to stakeholders

      25.  Brief retrospection was not performed at the end of release planning event

      26.  Team commitment is not sought on release planning goals

      Regards,

       

       

      Krishnamurty

  • sesha srinivas
    By sesha srinivas  ~  1 year ago
    reply Reply

    Most of the projects, commonly slip both in  timelines as well as in quality  levels when  tops down view and bottoms up view of project risks and dependancies are not aligned,  well ahead of the delivery dead lines. This is deadly trap  for  projects , which every body wants to avoid. This presentation/discussion looks promising as it aims at reversing this pattern using release planning exercise methods.

    • Krishnamurty VG Pammi
      By Krishnamurty VG Pammi  ~  1 year ago
      reply Reply

      Thank you! I wish to unfold key anti patterns so that agile community takes note of them and take actions to prevent them

  • Karthik Kamal Balasubramaniam
    By Karthik Kamal Balasubramaniam  ~  1 year ago
    reply Reply

    Hi 

    Could you please elaborate on the list of Anti-patterns which would be discussed in this session?

     

    Regards

    Karthik Kamal B

    • Krishnamurty VG Pammi
      By Krishnamurty VG Pammi  ~  1 year ago
      reply Reply

      Hi Karthik,

      The key anti patterns include but not limited to

      1.    Clarity missing on “why we perform release planning exercise?”

      2.    Teams do not know what they are expected to achieve at the end of release planning session

      3.    Teams on the ground, are not aware of their  product vision

      4.    Teams are not aware of product roadmap outcomes and themes (or guided goals) for current release planning exercise

      5.    Area wise product back log is not prioritized and most of the backlog items are coarse grained

      6.    Prioritized backlog does not have story points for most of the stories by the time they attend the release planning session

      7.    Acceptance criterion missing for most of the stories and team works with product owner to establish acceptance criterion that covers functional and nonfunctional goals during release planning session

      8.    Individual teams come unprepared for the release planning meeting and thus discovers 95% of dependencies, risks and issues during release planning session

      9.    Required stakeholders are not invited to the release planning event

      10.  Invited “key” stakeholders do not attend the release planning exercise

      11.  Teams does not prepare the release planning room with updated information radiators before start release planning exercise

      12.  Teams are not updated with release planning agenda

      13.  Team performs release planning exercise whenever stakeholder in power visits their site instead of performing the function at the expected periodicity

      14.  Team wise Definition of Done” and “Definition of Ready” are not kept current

      15.  Teams take their respective optimistic velocity into consideration while forecasting

      16.  Release planning event opening was not performed with key stakeholders does not open the release planning exercise with product vision, progress and release goals

      17.  Team does not take participant feedback into the planned agenda before start of the release planning exercise

      18.  Working agreements are not formed for effective release planning facilitation

      19.  Team conversations does not address challenges involved in bridging the gap between 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”

      20.  As a team, business and development team does not perform trade-off decisions when required

      21.  Team notes cross team dependencies, risks, issues at the “end” of the session

      22.  Team does not note the decisions taken during release planning event

      23.  Other locations are unable to contribute to release planning exercise

      24.  Baselined release planning artifacts are not communicated to stakeholders

      25.  Brief retrospection was not performed at the end of release planning event

      26.  Team commitment is not sought on release planning goals

      Regards,

       

      Krishnamurty


  • Liked Jaya S
    keyboard_arrow_down

    Scrum Dev : An effort towards Developer Friendly Scrum Practices

    Jaya S
    Jaya S
    schedule 1 year ago
    Sold Out!
    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

    ScrumBan: Best of both worlds - A Fertile Hybrid

    Jaya S
    Jaya S
    schedule 1 year ago
    Sold Out!
    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.

  • Jayaprakash Puttaswamy
    Jayaprakash Puttaswamy
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Advanced

    This talk is an experience sharing session about what it takes to realize business benefits in a large-scale (beyond 100 people) agile transformation. Having driven more than 4 large-scale transformation initiatives (of scales 160 to 700 people) over last 5 years, I would be sharing a couple of case-studies where I worked recently and I would discuss various challenges of implementing large-scale transformation and possible approaches to handle them. Participants would be engaged through interactive discussions on mutual experience sharing with a focus on key dimensions of agile execution.

    As the title reveals, the talk would focus more on execution challenges and approaches to handle them at all levels of stakeholders involved in a transformation. Levels include developers, architects, managers (project/engineering), senior management (delivery/program management, directors) and CXO's. More details in Outline section. 

    The key dimensions to be covered include

    1. Building and sustaining learning culture (approaches include Community of Practice, Guilds and Joint Workshops)
    2. Causing the mindset shift in engineers (different approaches for developers, architects and engineering managers)
    3. Enabling managers to create and nurture agile engineering culture (approaches include effective metrics about quality of code, tests, application and build)
    4. Inverting the Test Pyramid (approaches include test automation strategies, BDD, dealing with Legacy using Strangler pattern, Component Guardian pattern)
    5. Leadership Agility (approaches include catalyst style of leadership, risk driven decision making, leading the change)

     

  • Liked Krishnamurty VG Pammi
    keyboard_arrow_down

    Lean Scrum - The need of the hour

    Krishnamurty VG Pammi
    Krishnamurty VG Pammi
    schedule 1 year 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...

     

  • Jeganathan Swaminathan
    Jeganathan Swaminathan
    schedule 1 year ago
    Sold Out!
    90 mins
    Tutorial
    Advanced

    Being an Agile Coach & TDD Consultant, I have helped many product companies during their Agile transformation journey. I have observed many interesting good, bad and ugly practices followed in industry in the name of TDD. I would like to share my experience with the audience and guide them towards the correct direction and help them extract the true benefit of TDD.

    To give a simple example, using code-coverage as a metrics to measure the effectiveness of the Unit Test Cases is one of the common mistakes committed by many companies. 

    In my presentation, I would like to demonstrate hands-on and discuss, how to effectively follow TDD and what to watch out and avoid bad practices in TDD.

  • Liked Rahul
    keyboard_arrow_down

    How to measure the outcome of Agile transformation?

    Rahul
    Rahul
    schedule 1 year ago
    Sold Out!
    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.

  • Liked Naveen Kumar Singh
    keyboard_arrow_down

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

    Naveen Kumar Singh
    Naveen Kumar Singh
    schedule 1 year ago
    Sold Out!
    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

    Building Cross functional teams by example.

    Krishnamurty VG Pammi
    Krishnamurty VG Pammi
    schedule 1 year 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.

     

  • Deepak K Gupta
    Deepak K Gupta
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Beginner

    What

  • Deepak K Gupta
    Deepak K Gupta
    schedule 1 year ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    Test

  • Liked Madhavi Ledalla
    keyboard_arrow_down

    Gamification –an essential element for vibrant retrospectives.

    Madhavi Ledalla
    Madhavi Ledalla
    schedule 1 year ago
    Sold Out!
    90 mins
    Workshop
    Intermediate

    High performance agile teams are always striving to achieve an effective retrospective that enables the team to discuss the success criteria, and define the areas of improvement further.  This is an important aspect for cross functional teams – the development, operations, database administrators, systems administrators, QA testers, product managers - to focus on excellent communication and collaboration. 

    Over the years, my experience has been that retrospectives can get monotonous with time, and hence tend to become ineffective. The more I engaged with the process, the more I felt the need to revolutionize the process, bring out something new, fun, and exciting to make the retrospectives vibrant.  The other interesting aspect I came across during my research into the subject was the theory of gamification and the universality of its application. 

    During this session the audience will understand how the concept of gamification brings in a completely different dimension of thinking while maintaining the element of fun as we try and apply it to a few everyday situations!

     I have leveraged Luke Hohmann’s Innovation Games, The Conteneo Collaboration Could platform for this concept of gamification so that distributed teams can benefit by this.  

     

  • Liked Vijay Bandaru
    keyboard_arrow_down

    Enterprise Agility - Not a Cakewalk

    Vijay Bandaru
    Vijay Bandaru
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    I worked as a coach and have experience ranging from team level to large scale agile transformation that involves:

    - Multiple teams from different locations
    - Different cultures
    - Variety of structures
    - Component teams
    - Strong silo working culture
    - Legacy code base
    - Different release schedules and processes
    - Wide range of tools
    - And many other challenges

    As part of working on the assignments to help the organizations transforming into agile, I had come across various anti patterns and road blocks at various
    levels. These anti patterns are very critical to understand and help the organizations to tackle them effectively without compromising on the core agile
    values and principles.

    It is very easy for any organization to kick off the transformation but it is very hard to maintain the sustainability and become a matured agile organization. During this period there will be many traps that will force the organization to take a U turn and get back to where they started. Lot of effort, money and time gets wasted in this process. It is important to understand the key areas of enterprise agile pathway and decide the roadmap for the transformation with a clear vision and goal. Periodic inspection and adaption is also critical in this whole process to successfully achieve the vision and goal of transformation. top to bottom of the organization will play very vital role in this journey, without proper collaboration, communication and understanding among these teams, organization cannot transform. 

    Once the transformation kicked off, organization will go through a whole set of different challenges during their release planning, sprint ceremonies, collaboration issues, cross location team challenges, tools and processes and these are also critical humps to crossover successfully. 

    Another important area that usually will not get enough importance in transformation is the "communication" part. Agile emphasizes more on "face to face" communication. But is it just enough talking face to face? Conflict --> Communication --> collaboration --> Value delivery. This path has to be clearly understood at all levels of organization. 

    My topic is going to cover these anti patterns that I had come across in my coaching experience and share them with the audience. As part of this session, I am also planning to conduct a survey to see how many of these anti patterns are common to the organizations that are transforming into Agile. I will collect the survey information from the participants by providing them a quick hand copy of the survey form. This information will help me for my paper that is in progress on the "Enterprise Agile Transformation".

    I am also planning to have some activities within the session by giving the audience some challenges of transformation and try to find suggestions to arrive at solutions to tackle those challenges. This part will make the session interactive and two-way knowledge sharing.

    The anti patterns will be mostly around the following categories:

    - Management responsibility
    - Structural challenges
    - Product teams
    - Portfolio management
    - Scrum teams
    - Scrum Master
    - Support teams (Sales, Marketing, HR, Admin etc)
    - Communication
    - Continuous improvement
    - Tools
    - Processes

    I will also cover, what was done for some of the key anti-patterns to address them as part of the transformation engagements.