About Liberating Structures

Liberating Structures offer a revolutionary solution to collaboration in groups. Invented by Henri Lipmanowicz and Keith McCandless, Liberating Structures are a set of microstructures (33 at the moment) that use a handful of simple rules to unleash and involve everyone - no matter the size of the group.

About the CASE:

In this CASE study, I will demonstrate the power of Liberating Structures in 90-mins quick Immersion using Strings (I will string 5 LS together to solve a problem to demonstrate participants how we used them in one of the Organizations that I worked to enable Organizational Agility. We used a string of LS and involved 3 in a box leaders to unleash collaboration among the 3 in a box leaders ( Program, Product & Engineering) and enabled the leaders to build consensus and unleashed collaboration.

PS:

There won't be any slides for this workshop. The entire activity will be demonstrated using number of LS.(Strings) and the participants will be able to easily apply them at their work.

You could find some pictures of LS workshop from the website of mine. I am happy to provide more information if you want. I have been running the same as part of my meetups.

Format of Running:

Participants will be engaged throughout the session using the Structures mentioned below. For the detailed session, Please refer the Structure of the presentation.

When can we use them?

1. We can use LS to engage and achieve 100% participation from a Larger Crowd

2. Build Consensus from different groups

3. A Facilitation Technique that unleashes the power and intelligence of people.

Where I used them?

I used LS when i was working with one of the Financial Product Companies on their Agile Transformations journey. We brought the 3-in-a box leaders together using the LS Structures and we are going to demonstrate them with a simulation of the same during this 90 mins hands on session.

In 2003, I started my first internship at a small company. It was simple and yet amazing to integrate different open source products into a working solution to provide customer value.

It was not a picture cut into the puzzle pieces and ready to assemble again, however, it required some code understanding and interface tweaks to make the user application flow smoother and easier.

But what does it have to do with Agile Coaching journey? Yes, it does!

In this talk, I will share my experience from developing software as a nerd to developing people. It is a reflection of my past 10 years. It further discusses the importance of self-awareness, continuous learning, patience, facilitation, experiments, team dynamics, powerful questions, and "patience" again.

I will further share the leadership and coaching models, books and workshops which had a huge impact on me and helped me to stay motivated on this course. I will share what worked for me and what didn’t.

What I realize now is that I am combining different personalities to build teams and organizations to deliver value by understanding them and help adjust behaviors as per values. It is important to have empathy to build high-performing teams.

This is a tale of a scrum master who wishes to ascend the pinnacle of master level in scrum master role. But owing to numerous challenges, this dream is not taking place . After several years of soul searching, he reaches to an agile baba for enlightenment advice expecting something miracle will take place. Agile Baba took several Gyan session to establish wisdom in scrum master’s mind. Once Scrum master back to the war field with rejuvenated wisdom and start his course for the mastery level, he realizes that it is a mirage. How long it took? Is it possible to fasten the process? Let us deep dive into the life of an enlightened scrum master and learn from this story.

Coaching leaders is an art and a science. While attempting to coach leaders (especially the CXOs and senior leaders), it is very important to assess the coachability aspects of the leaders before proceeding.

In this hands-on workshop, I would be sharing a few tips on assessing coachability aspects. I would also demonstrate LIVE, a few coaching conversations with leaders (participants need to volunteer to be coached).

In addition, participants can practice what they learn through coaching simulations with peer participants.

The main challenging reasons why organizations are struggling to appreciate scrum implementation in their context today are of two folds:

1. Scrum is an agile project management framework. This focuses on maximizing “Return on Investment (ROI)”. Scrum, however does not define how to manage and track costs to evaluate actual ROI against the set vision.

This is preventing product owner community to prioritize maximum ROI features to the team sprint after sprint based on a rational performance assessment yardstick. Instead, they are proceeding with their expert gut feel. Some are hitting the target and most of them are falling apart the target.

This is making organizations endure some benefits that come out of discipline that scrum is institutionalizing. But most of the organizations are struggling to reap further benefits beyond certain level as they lack performance yardstick that guide them meet their set vision.

2. On the ground, most of the scrum teams work in their silos. That is, they dwell in their own sprint planning, sprint goals, retrospectives etc. They do not even get time to think on how their peer scrum teams are contributing towards overall project goal. Finally, we witness disjointed teams lacking understanding on “Where our current overall project stands? Do we reach our vision if we continue with the same rate collectively?”

In essence, scrum and leadership teams lack complete picture of project performance on the ground. That is why, they are struggling to take efficient and effective decisions based on current information. This is preventing organizations reaching their vision. They end up working for scrum instead of scrum working for them.

In this session, we shall learn a rational performance measurement yardstick called Agile EVM (Earned Value management) that integrates scope, schedule, cost parameters adapting to scrum values and principles. We shall take an agile scrum project as an example and learn how to calculate EVM indices that give below beautifully "carved interpretations" during scrum project's journey (after sprint 2 in our specific example):

1. We are currently behind the planned scope by $ 5,000 worth of work.
2. We are currently running over the budget by $ 7,000.
3. Rate at which the planned scope is realized is 80%.
4. For every one dollar we put into our project, we are getting 74 cents worth of work back.
5. If we continue at the same productivity rate, the expected total cost of completing the project is $ 67,500. Thus, we incur additional budget of $17,500 compared to our original budget.
6. If we have to complete the project on the original estimate of $50,000, all our scrum teams have to demonstrate 30% more productivity in the upcoming sprints. Else, we should be prepared for deviation.

This way, product owner can take rational decisions based on current information sprint after sprint and release after release. Also, teams on the ground can have complete picture on where the project stands and collaborate towards achieving maximum ROI.

We use the concept called value points in arriving at EVM indices for the targeted release wise business value. In some project contexts, we may experience imperfections in arriving at value points. That’s okay… because “Imperfect leading metrics are generally more valuable than perfect trailing metrics, since the leading metrics give us the opportunity to re-plan our approach”.

Agile EVM is must-to-have “AID” for product owner community because it enables them to prioritize high ROI features to the team early in the project journey. It thus enables them to take rational decisions based on current performance information. Agile EVM helps collaborate all the scrum teams well towards set vision by visually depicting the current performance and predicted future state at any stage during agile project life journey.

Unless we achieve maximum possible ROI, team collaboration keeping end customer satisfaction into our mission, no methodology or framework survives in the long run…. Let SCRUM work for us fully when we work for SCRUM fully.

We must admit that we are living in the age of conflict. We all are surrounded with conflicts in one form or the other. More than 20% of current leadership team's bandwidth is estimated to be going on resolving one or the other types of conflicts.

Whenever people come together to solve problems, there will be difference of opinion and competing interests. Thus, conflicts are normal and inevitable. Coaches, Scrum masters and managers often feel obliged to help resolve conflict, but before rushing in, it is best to observe the situation to get a better view of the issues.

Some degree of conflict is healthy, to ensure that ideas are sufficiently tested before they are adopted. However, we need to make sure the conflict does not escalate beyond healthy levels, else we will end up with a negative and repressive team environment.

Speed B. Leas Framework can help us objectively assess the severity of a conflict on severity scale of Level-1 to Level-5. In this session, we shall discuss Leas’ framework by detailing below topics:

1. Objective assessment of conflict levels (Level-1 to Level-5) based on environment and language being used.
2. Suggested conflict resolution approaches for different levels.

Thus, this session will equip you with Leas’ framework that can help you revisit your team level conflicts objectively by separating emotions. This way, you can create an environment in which people can use conflict constructively towards development of successful people, projects and products where each idea is successfully tested before it is adopted.

Many organizations today, struggle to switch from traditional project mindset to product mindset. The reason is NOT the lack of knowledge/skills about product management. It is because of lack of awareness and orientation on "Product Thinking & Discovery" for everyone involved in the entire value stream. What makes the implementation more complicated, is the lack of ability & execution skills to do customer & product discovery in real world context. Most challenges are rooted in the questions like "what does Product Thinking & Discovery mean for me?", "how does it impact my day-to-day work?" and "what additional skills/competencies are needed to do continuous product discovery?"

In this experience-based presentation, I plan to delve deeper into heart of this topic and share real-world experience of creating organizational structures that embrace product thinking and defining/refining various roles needed to do product discovery and development with agile and lean approaches. I would be clarifying the real meaning of buzz words like collaboration, ownership and agility in the context of a large-scale transformation involving global roles and distributed teams.

During the onset of software based technological advancement, it was argued whether the elephant can dance? This argument was later settled by the book of Louis V. Gerstner, Jr titled “Who Says Elephants Can't Dance? “

Even though Elephants were dancing, people still felt that something somewhere is missing. These thoughts lead to what we now know as “Agile Manifesto”.

Incidentally, Agile Manifesto didn’t state on whose tune one should dance? The soul of the manifesto was to get things done by giving value to some aspects over others, which is applicable to all dancers, whether it’s an Elephant or a Rat.

During the later years of the 21st century, Scrum became one of and by far the most successful framework for software development by teams so much so that the name Agile and Scrum become synonymous

However, organizations, especially Elephants rather than Rats wanted to dance not only at the team level but also at the organizational level.

This lead to one of the most selling terms of today called “Scaling”. Thanks to some of the pioneers of our industry, Elephants got what they were asking for i.e. Framework(s) for Scaling to make Elephants dance again using Agile Moves.

Nevertheless, it doesn’t make life easy for Elephants as there emerged multiple dance forms competing to get the attention i.e. LeSS, SAFe, [email protected], Nexus etc.

The idea of this session is all about identifying frameworks for elephants and how you make sure that you’ve chosen the right one

All the industries are disturbed due to disruptive technologies. The more vulnerable industries are due to new technology introductions are Retail, Banking, Telecom, Health care, etc. As a Change agent, if we are working for those organizations, we have to lead with an absolutely unique strategy.

What type of Transformation solution or medicine you will present? Vitamins or Aspirin ?

Vitamins are optional for most individuals. In comparison, aspirin solves immediate, painful problems and finally is often simpler to sell.

If the transformation is something that can enhance an organization’s existence in the prospect, the transformation is like providing vitamins.

If the transformation is something that can get rid of a pain now, we are providing aspirin.

Let us deep dive into these challenges and I share my stories with you.

Many aspiring and practicing coaches (especially Scrum Masters and Agile Coaches) fall into the trap of what I call as "teaching is coaching"

In this short talk, I would share a few tips on identifying myths around Agile Coaching career and TOP 3 tips to build a solid coaching career (especially in Agile and Lean space) along with possibilities in this career.

We are delivering products, but are we delivering with required "productivity"? – This is the question, each of us need to retrospect. In the current era, agility is becoming buzzword. We witness scenarios, where people are implementing agile just because they are asked to do. We witness prescriptive agile events, where team members do not engage to the required level during agile events. If this trend continues on the ground, the result is "unproductive agile events" wasting team's productive time. If we do not correct this pattern in time, agile leads to fragile on the ground.

Stemming from my practical insights on ground zero, I wish to share with you, the top 5 scenarios where sprint planning event can turn unproductive. For each of the 5 scenarios, I will explain

1. Scenario Context
2. How it went unproductive
3. Practical problem solving

This way, audience can take preventive steps so that the stated scenarios (from practical insights) will not recur in their sprint planning events. It helps them to retrospect what is going wrong in their sprint planning event and take steps to conduct sprint planning events through excellent team engagement. This way, they can contribute to “productive” sprint planning event.

The very thought that “How something can go wrong” can also trigger further thoughts to make other agile events productive.

This talk-presentation is focused on Product Management - a 360-degree view of its initiative, vision and measurement.

What are the simple ways we can contribute to driving business, key objectives and outcome-outflow based results?

What are the key drivers for a business and what we should measure? Yes, you heard it correctly - Evidence-Based Management plays a vital role in identifying and measure each step.

Demystify Psychology of what you Measure for the business $$$$$$$$ !!

Most of the organizations focus on adherence to frameworks, Agile practices, restructuring of teams & roles as part of Agile Transformation with minimal focus on cultural transformation. Even the very few organizations that do focus on Cultural transformation focus primarily on practices and policies than on mindset, values and purpose.

Every organization that is looking to transform has an existing culture that is driven by its core values, beliefs and undefined practices. This defines how people operate on a day to day basis, how the transformation exercise is kicked off and the way it evolves. However, for the transformation to be successful, it is imperative that the transformation team Identifies & outlines the existing culture and is able to define the cultural aspects that need to change for it to be an Agile Organization. This needs clear understanding of various aspects of organizational culture, leadership agility levels, what can be done to identify the current culture and what is needed to be able to define the target state.

The intent of this workshop (No PPT) is to get the audience to understand the importance of cultural transformation, the aspects that one needs to focus on and also the means needed to define the organizational culture than it defining the individual.

The hands-on interactive session will introduce the audience to the Cultural Iceberg, Language, Habits and Mindset template to be able to clearly distinguish the need for focusing on Organizational culture, Leadership Agility Levels and the active involvement of the C-suite and Senior Leadership in defining the culture needed in the new ways of working.

Product, Process & People constitue the DNA of an organization, transformation better know as 'change for better' cannot happen, if we focus only on individual team behavior. Instead, we should take an overall systematic view, overcoming challenges across People, Processes and Product.

Being part of agile-based software organizations, I wish to share couple of learnings and experiences, as to how agile practices can help us, to 'deliver early business value' and 'higher levels of customer satisfaction', through a shorter delivery cadence, with continuous focus towards 'enhancing' product and 'improving' process by 'involving' people.

By comparing couple of past scenarios, I aim to clearly elicit the differences, in order to understand how 'change for better' will help to foster faster delivery. I wish to focus on below listed core domains and improvements under each domain.

#1. Enhance Product

1. Deliver product increment early.

• A new product increment should be made available regularly to customers, with an aim of 'couple of months' to 'couple of weeks'.
• Shortening delivery cycle can tremendously help to reach market early, there by reducing time-to-market.

2. Projects initiated based on customer(s) demand instead of market research.

• Project initiation is driven by demand from customer(s).

3. Shorten agile release plans, to frequently deliver product, for early feedback.

• Enhance release planning exercises, by focusing on delivering 'Minimum viable product', during the early sprints.

4. Shared team commitment for 'Definition of done'.

• Align definition of done for Task, Story, Release and Sprint.

#2. Improve Process

1. Quality:

• Follow best engineering practices to enrich product quality, in a rigorous manner.
• Revisit code-review process to identify opportunities for improvements and fix gaps.
• Integrate code-base with automated quality tools, increasing transparency of existing/new code smells.
• Promote Test-driven development ('built-in' quality), while developing new features.

2. Automate & refine build processes to reduce delivery cycle time.

• Enhance build parks by adding more infrastructure, for faster delivery.
• Separation of concerns by improving development strategy.

3. Cloud adoption.

• With cloud adoption, new product increments can be seamlessly deployed and made available to customers much early.

4. Integrate home-grown tools to have 'single source of truth'.

• Integrate knowledge base and other tools, for better information sharing, transparency and visibility.
• Keep information radiators always up-to-date, reflecting today's situation.

5. Refine processes(remove wastage) to reduce lead/cycle time.

• Stream-line processes by identifying and removing bottlenecks, waiting time etc. for faster results.

#3. Involve People

1. Structure speed-boat teams.

• Do one thing correctly, with clear vision and focus.
• Teams can be better restructured to have a clear vision for product delivery.
• Product teams focus on existing product delivered to customer(s) while Project teams are spun-off for each new project, to develop new features for customer(s).

2. Regular training's to impart and enhance skills.

3. Encourage teams to share improvements/ innovations, with other teams for continuous learning and knowledge sharing.