Result Authorizing tool gives  SM an understanding of what is blocking people from getting great everyday results and engagement and is an essential Scrum Master tool.  This tool reveal that how we internally speak about our result influences how we understand our result. Thisis al linked with neurotransmitters release (dopamine and serotonin in this case) and we will discuss how it feela and how we can manage that. There is a clear protocol how result authorising should be done, it was tested on hundreds of people, but at every test we find new patterns and blocks and my test is to confirm is that absolutely independent on the country-culture or there are any differences?

There is a clear protocol on how result authorising should be done, it was tested on hundreds of people, but at every test, we find new patterns and blocks and my test is to confirm is that absolutely independent on the country-culture or there are any differences?

I would like to run a Result Authorising exercise, it is 15-minute prep and about 20-minute exercise (in pairs) with a 10-minute discussion afterward. Would like to compare the results with the ones I already have.

I would be interested in ice-breakers and other techniques that can add fun to my training.

Constantly driving change is getting more and more important for companies to survive in this VUCA world. At the same time, it is (or should be) the core skill of every coach – no matter if you coach individuals, teams, or organizations. However, sometimes it seems every coach has to come up with her own experience on how to drive change successfully.

Our hypothesis is that for driving change, every coach uses so-called probes, that are defined by small, safe-to-fail experiments based on hypotheses derived from reflection on the current situation as well as on theory. So, probing allows discovering (based on the hypothesis) what’s working and what is not through one or several experiments. This allows to make sense of both the current situation but even more important of the situation we are aiming for. And if we create a knowledge base of our collective wisdom on probes we used (or intend to use) we can learn from each other.

As an experiment we want to invite this year’s coach camp participants to jointly discover, share, create, improve, and finally publish probes that help(ed) driving and sustaining change. As in a typical coach camp, we will use the Open Space format to explore different topics for driving change and we invite you to use probes to focus the discussions on these different topics. We anticipate as a result that the discovered and created probes will provide a foundation for such a knowledge base.

How do other coaches learn for themselves and how do they contribute to others learning?

I am an agile evangelist who's tried to use knowledge in technology to coach teams and organizations in improving their agility. My focus has been in the teams and leadership. Within teams after a few changes and coaching, the change that we bring in sustains for a long period of time if there are minimal anti-patterns introduced by the ecosystem. 

Breakthrough Changes and transformations do need a change agent to facilitate the change. I have seen it very successful when the change agents work in an independent unit to manage the transformation. 

There is a lot of focus on executive leaders and teams during the transformation. There has been less focus towards the middle management as well as enablers for teams after the transformation has been stabilised.

My hypothesis is that a self-coaching instrument would enable change stay in Teams. For leadership coaching, self-coaching instrument is vital to understand their own blind spots and seek feedback.

I would like to explore the technique of how the data / analytics teams are organising themselves and what are the learnings from such transformation programs. 

OKR definition is not easy for majority of people specially because it demands a clear vision of and a business strategy. I have noticed that in most of the OKRs sessions that I have took part, managers and employees get stuck and blank some times trying to identify how their work supports company goals. They see those goals quite far from they day to day and it makes OKRs definition more complicated. In the other hand, when upper managers get into a tradittional OKR workshop they face the challenge to agree witht the others managers about what is morre important due most of the times they are looking for silos goals. All of this comes with a too much complicated explanation of OKRs instead of making it easy for people.

Use gamification and a flowable session makes easy to design and identify OKRs, we starts from divergence to convergence. Gamification helps whatever learning and people engagement process due it can make something totally boring enjoyable for anyone. Regarding some stats from US people  anyone can be a gamer, and it is not only about video games, it is about all type of games due it is part of our human behaviour

https://www.broadbandsearch.net/blog/online-gaming-statistics

Introducing gamification and divergence-convergence approach into a OKR workshop will make OKR definition easier and more flowable. I would like to measure 3 things at the end of the session:  % of OKRs set by team comparing to the innitial goal of the team, second, I will test how OKR mastery team get during the workshop in terms of practical knowledge so I wil share a business cases that they will solve, and third time, I will compare how much time they took to define an okr before and compare

Upper managers from traditional organizacion based on jerarquias and command-control get stuck when they need to make agreements and define OKRs

While designing Coaching Agreements need of the hour is to ensure expectations are set clearly, agreed and shared between the involved parties (coach and coachee). This sets everyone up for success by creating a WIN-WIN situation.

During any new coaching engagement, designing Coaching Agreement is the essential element in the coaching journey that sets up the expectation and direction ahead of the involved parties (both Coach and Coachee).

Designing the Coaching Agreement is never an easy and straight forward ask!! Many times Coaches/Coachees miss few of the key elements during Goal setting part (it may be about : challenge to address, options to consider, current state aka as is state check aka etc.). This is normally because Coaching Agreement discussions are not recorded effectively using proper tools/frameworks/techniques.

So common questions that need to be addressed in this context are:

• How effective is our Coaching model ?
• How adaptive are we in terms of the approaches to manage Customer needs and challenges ?
• How are we evaluating the state of our Coaching journey along with our Customers ?

My hypothesis is that –

During our day to day working environment - especially in Agile WoW (irrespective of the frameworks being used) we have lot of opportunities to plan, strategize, brainstorm, innovate and generate ideas. These will always be incomplete without the application of Visualization techniques.

Agileo originators have provided a framework for improving innovation, but there has been a missing piece - Collaborative Frameworks (influenced by Innovation Games ideas) offer ideas, tools & practices to aid the innovation process at its most critical point - product management, particularly visioning & roadmap identification.

Key to innovation is creating collaborative, interactive, visually-oriented, fun, business-driven-environment for people.

Collaboration Frameworks which uses Visualization tools in any forum, help people to inspire creativity, focus and generate a shared vision. Usage of Visualization aid the collaboration between people, generates ideas and thought process by bringing better alignment at work. Being Agile in nature (adaptive, transparent) they are easy for humans to remember in a long run and at the same time less error prone !

In Summary, as per the Neuroscience Visualization tools (principle on which Collaboration Frameworks are based) always assist in better way of strategizing, planning and executing the tasks.

This hypothesis helps people with better management to address complexity and uncertainty in the Coaching journey by employing ADAPTIVE tools.  Collaborative Frameworks provide the necessary tooling support to make the life easy for people working in VUCA world and ensure optimization of Risk.

In my earlier work experience,

• I found people are more engaged, enthusiastic, energetic and collaborative in nature when any key discussions are replaced by Visual metaphor or Collaborative frameworks.
• Teams & Organizations have been successful to a greater degree to prioritize their organizational initiatives out of available options by better planning, strategy, brainstorming and idea generation techniques.
• Through these dynamic/adaptive coaching agreements teams & organizations were able to achieve business agility with minimal impact.
• With the usage of Adaptive tools coaching agreements can be easily manageable and maintainable throughout the journey (irrespective of the timeline)

I am a firm believer of continuous learning. As I am on continuous journey of explore, understand & learn how beneficial Collaborative Frameworks have been for organization & people, and what differences they are creating to deliver value and sustain in this VUCA world.

Would be curious to learn from other coaches/practitioners/change agents of different culture and take some new learning (for me personally) through other's experiences.

Many a times organisation structural constraints are impediments to agility - Siloed organisation structure or fragmented organisation structure creates waste in the system and is an impediment to achieve any benefits. Coaches on the ground should be aware of the these impediments and be able qualify these impediments to plan the next course of action

Hand-offs are the biggest impediments we encounter while striving to reap the benefits of agility. Hand-offs are due to constraints in the organisation structures , or inefficiency in the process or an issue due to poor decision making culture in the org

1)We perform an upfront assessment of the as-is state before starting off , upraise internal and other relevant stakeholders 

2)We introduced lead time and cycle time as key measures to translate the maturity 

Would like to understand if there are other ways to qualify and quantify organisation structure based impediments

Organisation design is a new buzzword , would like to hear from experts on the  approaches , experiences and seek guidance  . Would like to understand from the coaching community on how they address organisation structure changes / influence stakeholders 

A large organization acquired a smaller company in a different geography for a solution they had developed and the product had to be integrated into a larger platform of the parent company and owned by a team based in India

The team that was tasked with this, was more comfortable working as a 'large organization', leading to disappointments with the customer base

To identify specific interventions and inputs for the team, I, as their coach, needed to understand the individual attitudes of team members towards being 'intrapreneurs'

While the team members were technically capable, the cogency and common purpose was missing in the team

My belief was that the team members did not have a common understanding of what it meant to be a 'startup' under the umbrella of a large organization

A simple experiment of scattering some crumpled paper balls on the table and floor of a conference room just before the team assembled helped see the patterns of behavior of individuals as they walked in and later [for the first few minutes]

I used that to replay to the team about taking ownership and working towards the promises made to customers [the product promise], which then made it easier for the team to prioritize improvements - and experiments - they would like to take up

the debrief brought out certain reservations, skepticism as well as aspirations and misunderstandings among the team members

The satisfying result was that the team was ready and eager to take up the challenge of becoming a 'startup' within the large organization

I would like to learn how other coaches have approached continual engagement of senior leadership and middle management to be supportive of the teams over time

I would like to explore approaches and experiments to get people [irrespective of role] to share more regularly, even if informally - so that teams and organizations can build the collective knowledge relevant for software delivery

I am also looking for interesting coach stories for my podcast 'software people stories'

The success of transformation depends upon the proper way of facilitation. Facilitation is important because meetings of large groups of people can be very hard to organize as well as to control when they are in progress. A facilitator can help members of a group get to know each other and learn to cooperate.

To understand new ways of working in any organisation, we need to facilitate in such a way, where everyone can not only understand this but they also collaborate and contribute their inner thoughts. Lego and Liberating structure are the best facilitation tools for this.

LEGO bricks are medium for communication; participants could express complex ideas through metaphors and storytelling. Lego is a kinaesthetic learning approach where a person/group can predict their mind map through the use of plastic bricks. Person/groups construct mental models in order to understand the world around him/her by emphasizing the value of prior learning and experiences.

Liberating Structures are a selection of 33 alternative structures for facilitating meetings and conversations, they quickly foster lively participation in groups of any size, making it possible to truly include and unleash everyone. Liberating Structures are a disruptive innovation that can replace more controlling or constraining approaches.

These are one of the best facilitation techniques which are quite prevalent in the agile transformation journey.

My hypothesis involves:

• The use of these facilitation techniques in Portfolio, program and team level helps in engaging people at organisation level.
• It helps smooth of conduct of various agile ceremonies.
• It will fetch the solution to any complex problem in an easy way.
• These are one of the best facilitation techniques in which we can easily engage persons to build transparency and trust, by expressing a complex problem in an easily understandable way. It will give a tremendous amount of value in the transformation journey

I have tried these in my organisation with the various level of the hierarchy, such as:

• Facilitate to build psychological safety
• Generate innovative ideas with portfolio level
• Engage various department in the transformation journey through a mind mapping and easy way
• Organising group facilitation to understand and new ways of working through Lego and Liberating structure

• I would like to explore that if there are any other ways or usage of Lego and Liberating structure.
• I am also keen to learn if there are any other best techniques in the market from that I can easily build transparency/trust and get the easy solution to any complex problem.

Organisations are aware that to thrive in this VUCA world, they have to create a culture of learning and innovation.

In order to create this culture, people need to speak up, share ideas, feel free to experiment as well as share concerns freely without fear of any negative repercussions yet we have seen and experienced there is something which stops us from speaking up and sharing our thoughts and in turn leading to stress, causing us immense grief and pain.

As per research a mere 1 per cent, feel “extremely confident” voicing their concerns in the workplace in crucial instances. In another study, 93% of people say their organization is at risk of an accident waiting to happen because people are either unwilling or unable to speak up.

My hypothesis is that as much as we talk of creating a speak up culture, it is equally imperative that leadership (senior leaders, managers, change agents) encourage an ongoing dialogue and create a culture of listen up, being self-aware of how they  contribute to creating this culture and improve organisational agility.

Have tried and been working on some experiments to validate my hypothesis. This is specifically for leaders/would be leaders.

 Invite the leaders as part of leadership team or extended leadership  team to a session and:

1. Self-reflect and identify how their  behaviours contribute or impact the safety of people they interact with.
2. Identify actions which they need to take as individuals to help create a speak up, listen up culture.

After a quarter , run a survey with team members to see if they are feeling psychological safe to share new ideas. If successful, it can be rolled across rest of the business unit and then across the organisation.

Ways how other organisations are working on improving psychological safety in their work place and help creating a culture of learning and innovation.Would like to understand how they are able to sustain on the actions.

As change agents/coaches, we are also impacted . How as coaches we are working on creating a safe environment for ourselves to experiment and learn and create positive culture

Two essential things which Leadership should possess 1) Psychological safety 2) Emotional Intelligence. When organisations step into Agile transformation, people get into panic mode and transformation becomes chaos. Few places it had worked and few places it's very hard to get these ideas into people's mind.

I would like to understand from the fellow coaches, how these 2 aspects are being approached in their respective organisations to drive and sustain the change.  

When we are working with people there are various techniques to impart the ideas which would help Agile Transformation and Sustenance. Creating Safety net is essential for Psychological safety through Emotional Intelligence, is this a right way to do it?

Technique 1 - How to apply The Ventilation Fallacy how to Vent When You're Angry Prolongs Your Mood Rather Than End It. This helps Traditional Managers to manage their mood and think of how an agile project can be managed efficiently. 

Technique 2 - The Artful Critique - How To Criticize The Right Way, key for new agile managers to get their work done.

By running this experiment at Coach Camp, i will learn how people are different with whom i am working with, which will help to enhance my ability while working with the people.

Driving and Sustaining the change is the key aspect for agile adoption, understanding from change agents of how they are dealing with the situation will be a key learning for me.

The story goes ...

During the Agile Coach Camp at Agile India 2019, we had an interesting discussion driven by Woody Zuill around the concept of Organisational Inertia. This has been a topic of research since the early 80s with the newest research in 2000s as well. The research basically revolves around two aspects:

1. An organisation's incapability to keep up with major shifts
2. The resistance towards change

These don't necessarily stop change from happening but considerably slows down the shift. With organisations struggling to survive in a VUCA world, Organisational Inertia becomes one of the critical factors for consideration. Enter, an Agile Coach! Our industries have heavily invested in them in the recent past and continue to do so in order to help them survive in this VUCA world. Shane Hastie addresses this as the Golden Age of Agile Coaching in which coaches can help the poor souls navigate themselves during a period of turmoil. I respect that.

But my evil mind links the concepts of Organisational Inertia and the Golden Age of Agile Coaching differently; so during the Agile Coach Camp, I asked folks to run a Thought Experiment which I also mentioned in my talk during Agile India 2019.

My hypothesis is: "We can deploy Agile Coaches in organisations and hopefully the organisations will overcome their inertia in 10 years to provide a better work experience to their employees. Contrarily, if Agile Coaches cease to exist, organisations may crumble under their inertia in 5 years and the ones left will be great places to work" ... from a Behavioural Economics standpoint, the second option seems better.

I decided to SLICE and probe this hypothesis and began my experiments on 3rd June 2019, the day after I finished my last batch of ICAgile's Agile Coaching training. At the time of submitting this position paper, I've been running the below mentioned experiments, and it hasn't been easy to deliberately take a step back from coaching interventions. The observations have been interesting (if not amazing) so far and this is my experience that I wish to share during Agile Coach Camp 2020.

Below are the experiments that I have been executing, details and observations of which I would like to share and get views from fellow coaches.

1. Hypothesis: Anyone can be an Agile Coach, not everyone should.
   We have recently seen an explosion in the number of Agile Coaches, a lot self proclaimed and a lot driven by certifications. This hypothesis states that although it's fair to teach coaching skills, not restricting coaching as a practice to a select few may do more harm than good.
   
   Experiment 1.1: The effects of having a Code of Ethics for Agile Coaches.
   Experiment 1.2: The effects of making the Agile Coach certifications obsolete or extremely difficult.
   
   
2. Hypothesis: Not talking about agility improves agility for others.
   Although this takes a lot from coaching skills, this hypothesis states that just the act of limiting the propagation of information around agility can lead to an increase in agility compared to current rates.
   
   Experiment 2.1: The effects of social media on the knowledge of agility.
   Experiment 2.2: The effects of deliberate silence by experts around agile practices.
   
   
3. Hypothesis: Degree of agility cannot be measured objectively.
   This hypothesis states that any metrics to assess agility will yield incorrect results and cannot be considered as the basis of any change / transformation initiatives.
   
   Experiment 3.1: The effects of assessment surveys and variation in formats.
   Experiment 3.2: The effects of objective goals for organisations / teams undergoing a transformation.

I'm particularly interested in learning experimentation techniques used by fellow coaches in order to see how it differs / concur with my own technique (SLICE).

Do we really know why are we developing a certain piece of functionality or a product?

Do we know how to measure the impact of what is being developed?

& Are we really keen to evaluate what brings success to our business?

In this era of agile realm, a lot of talks, discussions & debates starts & ends with “VALUE” delivery to customers. Alas! even after that we see daily instances of changing priorities, unhappy customers, challenges of customer retention & adoption, business loss & instability, approx. 65% unused product features, misaligned teams at all layers, and a lot of daily life struggles to be agile amidst all this.

In summary, people face challenges in understanding what exactly is so called VALUE, how they need to derive it, and finally how to measure it from the intended dimensions of value.

By knowing how to determine value (internal or external), employees feel aligned with the business, besides having great sense of accomplishment when they deliver the value which creates an impact in people's life.

My hypothesis starts by -

- Creating basic understanding about Value at all levels of the organization

- Scaling the understanding to evaluate multiple dimensions around value

- Creating an “Organizational Value Framework” to help teams in deriving the relative value of organizational initiatives with customer being the focal point in all decisions making

- Finally, measuring the delivered value to accordingly plan/design their OKRs in sync with delivered value

This hypothesis helps the business people to understand how market needs & competition drives their business priorities in addition understanding their customer needs better, & at the same time creating alignment from top to bottom to effectively plan their program increments, sprints & releases to ensure happy customers, motivated teams & individuals and finally growing & stable business outcomes in this VUCA world.

In my earlier experiences with this approach, organizations have been successful to a greater degree to prioritize their organizational initiatives out of the available options by relatively measuring the value of those initiatives, helping teams to build their OKRs, then letting the teams to figure out what problem or need of customers they are going to solve to create impact on customer’s lives and finally measuring the success of customer experience to track the delivered value and at the same time helping the business to also measure the business outcomes to continuously inspect & adapt.

In simple terms, it’s a framework

- Which can help the business people to filter the priority value initiatives/ objectives

- Breaking them down into quarterly OKRs

- Identifying customer needs which would hit the key results & delivering them through EPICs/ user stories

- Tracking the customer experience through one of the Google frameworks

- Finally, measuring the intended business outcomes & ensuring a continuous PDCA

I am on continuous journey to explore, understand & learn what is VALUE in different contexts for different organizations & people, and how are they creating & delivering value to sustain in this ever changing VUCA world.

So, this is a try to learn, unlearn & re-learn different dimensions around value & it’s framework with other coaches in this camp.

Agile is more of a Mindset and Behavior. For any organization to be truly Agile, one needs to imbibe the Agile behaviors in the culture of the organization. With this as a context, we have tried out couple of experiments at my organization to see how Agile can be ingrained in the mindset.

The hypothesis for this premise is that change agents can drive change initially. The early adopters can be targeted first for the Agile mindset change. However sustaining the changed behavior across all teams is something that needs to be done differently. Practices need to be established at organization level so that Agile mindset becomes the default DNA of the organization.

There are couple of practical experiments that we have tried at our organization.
1. Lean Chai sessions - Roughly based on the popular Lean Coffee approach - however rather than being open ended, these are focused group forums. We have had a lot of learnings while setting up these sessions in terms of cadence, audience, topics , etc. Having tried this for more than 2 years - we have now come up with a sustainable approach to bring in the continuous  learning and sharing mindset across Agile teams.
2. Book Club Meet - Another innovative experiment tried and working successfully at team level. We are yet to scale this at organization level. However the idea is to use Mind maps as a tool and spread learning/knowledge via books.
3. Yearly Agile Day event - This is run as a yearly event in our organization in first week of December. We recently completed the 3rd edition of Agile Day in Dec 2019. We see this as an innovative way to ingrain the Agile Mindset within the organization.

Once teams undergo Agile transformation from a process perspective,  the most difficult part is to sustain the Agile mindset. I would like to explore how other coaches have run different experiments specifically to sustain the Agile mindset across teams. 

As we undergo digital transformations in organizations we bring in new tools to enable capabilities that will accelerate the delivery of value to customers. Problems occur in the traditional enterprise when they try to balance the adoption of these new tools with the operational overhead of managing them. Switching to SaaS solutions isn't always an option (data locality, scale, cost) and companies run into unexpected issues with managing their newly added complexity. Additionally, regulatory requirements may force organizations to internally manage these capabilities. Done poorly I've seen this badly impact the ability for teams to form. 

My hypothesis is to building this into the delivery platform itself allowing for the build-out of opinionated pipelines and the reduction in decision points in the delivery team. In order for this work, there needs to be a clear understanding of what is supported by automation. This is best achieved by having a central platform team responsible for seeing these capabilities are in place. However, advanced teams can often find this restricts them too much. 

Building a tools strategy, creating a community and appropriately allocating funds can all help. Allowing developers to experiment while still ensuring we have the right governance in place requires a careful balance. Understanding how different companies have approached this problem at the different stages of maturity and scale will allow us to see what is working and what is not. I've done this effectively within a few large organizations but adoption has been a problem. What have people done to solve this?

Ways to properly manage this tooling complexity and thoughts on the best ways to streamline the adoption of new tools. How do people manage governance within the delivery process at scale when the regulators come knocking?

Many delivery teams use velocity as a measure of productivity and even base performance predictions on it. Because of this idea that velocity is a meaningful metric for the productivity of a team, management continuously expects a better velocity and teams continuously find ways to improve the number. 
In observing multiple development teams and their estimation process, and running analysis on data that from their work tracking system, I have learnt that the use of velocity is a poor indicator for future performance. Additionally, I am convinced that the use of velocity can drive unwanted behaviours.

Given the challenges with the most common way to measure a development team's productivity, is throughput a much better indicator of productivity that can be used for forecasting and that drives behaviours that can sustainably improve a delivery team?

We have for multiple teams measured throughout while the team was still working with velocity. We have seen more accurate prediction of future performance. After demonstrating these findings to the team and introducing different ways of estimating work and tracking productivity, we have seen teams move towards delivering smaller slices of functionality, because that’s the only way to improve throughout besides actually improving productivity.

• What are various ways to use evidence and data for coaching teams?
• What is a minimal set of valuable metrics that teams can draw from and that drive desired behaviours?

Bringing in the DevOps culture in a service organization starts with the very basic aspect of the mindset of the organization. Shifting from a fixed mindset to a growth mindset is a huge shift and needs sustained efforts to do so. We have tried to bring in this mindset in our organization for the past 2 years which has been detailed out in the experiment related question. The context of the probe is to see how to bring in sustenance on the same.

Change has to start with the right mindset of the Leadership. A change agent has to be identified at the start of the journey. However just 1 or 2 people who are the agents cannot bring in the revolution in the organization. The hypothesis is to ensure sustenance across the organization, as the change agents interact with one set of people, they will need to identify a similar set of change agents across the organization.

Practical things done in our organization

• Identified the innovators and the early adopters in the organization.
• In terms of implementation, targeted the early adopters and on a cadence basis had touch points with the leadership to show the progress on the journey
• Published the DevOps Maturity Assessment targeting the entire leadership to bring in their focus on the availability of the same
• Implemented Lean Chai sessions with the DevOps enthusiasts across the organization. This is a learning forum with a monthly cadence.
• We have a tracker where we track the traction on the number of projects on a month on month basis.
• We publish the quarterly status of the initiative to our management and they same is then further published to the leadership
• Came up with Process documents that are available at an organization level.
• We would now like to identify more and more change agents for bringing in the DevOps Revolution in the organization. As and when such change agents are identified, we can get that specific business unit started on their journey (even here we would look at a focus few projects)

What has been done in other organizations is what I would like to understand more about at this coach camp.

While we know that transformation begins with a shift of mindset – a Growth Mindset, an Agile Mindset. However, this mindset is a key lever when it comes to an individual rather than to an organization level. In an organization with diversity of people with various mindset and motivation level, how can this be achieved, and moreover, how do we measure that the desired change in attitude is achieved?

We have been using various approaches for changing mindset, through motivation, by walking the talk, through coaching, by providing psychological safety, etc. However, not all initiatives are helping to drive the change fully. 

My hypothesis is that by giving an open and honest feedback to your peers, subordinates or managers you could help achieve this. However, would you dare to give an honest feedback to your manager? 

My experiment around this is instead of giving feedback to your peers once a year during their appraisal, and moreover, not even daring to give any feedback to your manager, let us gamify this. While doing your monthly meetings with your teams you could write your feedback to all your team members individually in stickies and stick them on their back. Everyone does this, and everyone receives feedback from the rest of the group. This shall introduce some kind of comfort in giving feedback, and the receiver would not take it personally either. After trying this for 6 months in 2-3 small teams we could do a survey to validate if this is bringing a positive impact on the mindset or people and if this is motivating the teams to perform better or not.  

I would like to know more about the experiences and approaches that our fellow coaches are using at their organization for driving change

Every organisation hopes / expects / demands high performance from their employees and teams. It's not very long ago when most effective organisations in the world had a ritual called yearly goal - setting. Many organisations still continue with this where the HR cascades a set of goals set by the organisation's leaders for their employees. This is usually followed by a quarterly to yearly review cycle which with most organisations are linked with incentives. In general terms, there ain't any flaw with this system; goal setting is an efficient way to continuously improve oneself. However, the execution of this process may be flawed and may lead to un optimized results. With the advent of business agility, this focus shifted towards continuously learning & improving organisations. This meant that faster feedback was highly recommended for performance improvement and the idea of year-long goal setting seemed a talk of the yesteryears. Many organisations embraced this change by completely abolishing the yearly goal setting practice and instead relying on mentor relationships for an individual's performance improvement. This did improve relationships at the same time hindered transparency since the organisation goals were no longer directly accessed by every employee.

When seen from the perspective of game theory, it's evident that optimum results are obtained when employees achieve goals which are highly beneficial to them at the same time aligned with the organisation's goals. With the former approach explained above, it's pretty clear that the employees in the first case were aware of the organisation's goals, even if the goals were not aligned with their personal goals. Whereas in the latter case, the lack of transparency meant that the individual's goals were highly focused and may not be in-line with the organisation's objectives.

I propose using the ‘Peer to Peer - Performance Kaizen method’ which aligns the above two systems with a flavour of Management 3.0 in order to create an optimum setup where high performing individuals, teams, and organisations can thrive. 

To validate this hypothesis, I conducted the performance assessment of 14 team members in the Kaizen way, where we met every month for peer to peer assessments and saw a drastic improvements in performance in a period of 12 months, Jan to Dec 2017(performance). Case study proceedings and finding attached here https://www.slideshare.net/secret/34MOUcoXnOKts1  

https://www.youtube.com/watch?v=RsjHao3OhWM&t=862s

In this coach camp I would like to share my experience of using this technique and learn what perspectives other coaches have to this approach, identify any areas of improvements and promote the peer to peer assessments so that I have a bigger group to further validate this hypothesis in different cultures and types of organisations.

After observing many different teams and being in different teams, what I've always experienced is that teams with people who can show up as themselves whilst showing great care and respect for their teammates always end up working better together and are aligned on producing the best possible outcome they can give. Authenticity creates a foundation for trust and understanding.

Before we can effectively collaborate with other people, we need to first understand each other as humans and build a stronger working relationship.

What would happen if we created a whole day to focus on setting up a team for success before throwing them into a space together to solve business problems?

If we just did this, we would see an increase in team happiness, engagement and trust with each other.

I have run a mini-workshop (1.5 hrs) with 10 people who haven't worked together before to share stories on their upbringing, getting out of their comfort zone and play a number of improv games to create an environment that celebrates creativity and mistakes whilst working together to achieve a better outcome. The used for the session was a set of psychological safety questions - the score was out of 5 and overall, it went up from 3.27 to 4.44

What I'd like to experiment this time is spend an entire day focusing on building a team rather than just 1.5 hrs

On a smaller scale, the experiment I'd like to run is focussed on building trust with each other through an activity or two that will be measured by the "Trust Quotient" by TrustAdvisor - https://trustedadvisor.com/why-trust-matters/understanding-trust/the-trust-quotient-and-the-science-behind-it

If I could explore only one thing, it would be to get everyone to self-reflect and share their own unique stories about their upbringing and what events as led them to be the person they are today.

Other techniques we could explore may include:

• Improv Games
• Collaborative Problem Solving that involves everyone to play their part to win
• Writing their own Identity card (what I value, my strengths, what I bring)
• Share their failure moments

In the Lean/Agile world, though these words seems to be very familiarly being used. But, the understanding differs with each individual or team or Project. This has gradually created a VUCA bubble in the work environment.

In my organization, we work with varied Business units, multiple location partners for product developments involving various lifecycles of hardware, firmware and software. Each of the Business units have their own defined array of processes, milestones and delivery timelines.

As a program we have to work together and fundamentally be aligned. Alignment had to be established at various levels like Business, processes, Product quality measures, release timelines, etc.

In order to set up a harmonized and synchronized understanding of process, I as a Lean coach in my organization wanted to bring in a common integrated process by defining and setting up a common software process which gradually brought in the culture of trust, transparency and ownership amongst the teams, management, partners we work with.

For any building, strong foundation is the basis. So, my hypothesis strongly emphasizes the quote from Peter Ducker that  “Culture eats strategy for breakfast”. Culture plays crucial role in any organization. It is an unseen power or institutional habit where everyone is part of, right from the top-level leaders to bottom level developers to support members, etc. when established positively reflects in business/organization success.

This arises few questions in this context:

• What is culture?
• Who are the ‘Culture Setters’ in the Organization?
• Who changes the culture and what are the challenges?
• What power does empowerment hold to proliferate culture?
• Is culture only means of success to Business or Organization?

My quest to get answers to above questions, led me to interact with various teams, roles, management, partners of the Business.

The first task as coach I did was to gauge the leader’s and team’s process awareness quotient. For this,

• I conducted couple of interviews with leaders and teams to know ‘What culture means to them?’
• Organized with few teams an interactive reflection workshops to enhance their understanding
• In batches, trained members with relevant case studies of impacts of culture
• Enabled the change influencers (like POs, Scrum Masters, etc.) to translate the understanding in to practice continuously
• Encouraged teams to ‘Fail early and learn fast’
• Guided team to stay focused for goals they had to set
• Enabled teams to define the value definition in terms of key KPIs
• Collaborated with various stakeholders to identify and address the pockets of improvement to strengthen and proliferate the positive culture

Currently, the management team of one of the business lines, saw the change in the way teams across locations communicated, collaborated, accepted and owned the success or failures with grace. The journey taken was worthwhile, but the momentum is on and is in progressive path of success.

One of the outcomes of the above exercise was Business Partner Satisfaction survey commendably changed from low rating to high rating. The trust, confidence established so far has paved path in gaining more business when compared to last year (from 2 projects to 7 projects)

This also has led to accomplishments of Business partners accepting and gradually adapting the process by establishing similar culture across globe (Multi locations).  When culture is set strong mindful and responsible decisions are taken to deliver a right product.

I am keen to learn

• How do we Sustain and revive the mindset without getting drawn to outside industry buzz words and practices?
• What does Value sustenance mean for an agile business/organization?

Constrains literally translates to “a limitation or restriction”. Often, we see constraints in a bad light. But are constraints always bad? Does it have a positive side to it? Can we see a constraint as an opportunity to think out of the box, does a constrain force us to innovate?

“Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage.” - 37Signals
 

So, if constrains can unleash creativity can we engineer a productive constraint that can improve the overall agility of teams? The line of thought here is that, when such creative constraints are carefully injected into a team in a controlled environment, the team could start thinking out of the box and reinvent themselves as a better mature agile team. Can they , can we as coaches use such constraints as a tool for coaching.  

In our experiments we exploring one such constraint called 2.5 days hyper sprints. In this experiment, we requested teams to volunteer to adopt the 2.5-day sprint challenge as a constructive constraint. The first thing that became visible when teams embraced the 2.5 days of hyper sprints was a never-ending stream of impediments. These impediments which were surfacing up most of them were new to the team. The impediments that were surfaced by each team were different and were very specific to their work context. A few examples of impediments were “our avg review cycle it’s too long more than 1 day”, “We need at least 2 days to test our story”, “our story is too big”, “Our PO is not available enough” ,..etc.. In due time some of the teams succeeded in resolving their impediments and some did not. We did such experiments across 20 + teams and hence had a lot of learning both bitter and sweet. The learning also pushed us to discover a few new practices to make hyper sprinting work.

We would want to run the same experiments in a different context to understand if the above results are consistent across different work contexts and generalized.

How to measure?

Measure the below data before the experiment and 3 months after the experiment

Data

Measure dimensions like cost, quality, speed, predictability

Conduct surveys to measure aspects like team engagement, work-life balance, Happiness etc 

any other experiments in similar lines, need to explore if there were any other creative constraints  we could explore and  experiment

 As an Agile Coach / Consultant for the last few years, I find each coaching engagement different.  The common thread across these engagements has been that if Coaches are able to “connect” with the leadership and the teams -  the ability to accept change becomes that much  easier.

It is said people do not resist change as much as they resist being changed.    This is applicable to members who feel they do not have a voice in some of the changes taking place in the organization. When big changes are thrust on to the teams,  we sense a lack of commitment to the change initiative.
I firmly believe that to make effective changes in an organization – we need to start from where they are now – understanding their current processes, respecting their roles and responsibilities,   borrowing from Kanban Change Management principle.     And then go on to make small evolutionary changes. 
An important aspect which would help in accelerating change is to develop trusted relationships with  key members and address some of their issues in a timely manner.  I feel building trust is the foundation to any successful transformation.

In one of my  Coaching engagements, I found that  there was a lot of resistance to Agile in one of the divisions of a large organization. Members felt Agile was thrust on them from the top – with the result there was a lot of reluctance on the part of  the leaders/managers to transform.  A rather unsuccessful  Agile transformation exercise earlier could also have been one of the reasons for their resistance. 

I spent a good amount of time in the initial stages to understand their current situation, what aspects can be continued and what needs to be changed.  I  tried to build rapport with four key members of the division using practices such as active listening, powerful questions and clear communication.   Over time they could the benefits of implementing Agile.

Just keen to meet and learn from others, ways to accelerate change in organizations.

In my interactions with several agile coaches and practitioners across many organisations, not many are talking about the core values and principles of agile, or how those basic foundations are being interpreted in individual environments to help the overall software development processes and outcomes. Rather the conversations have circulated more to see how certain framework and processes are being followed. I’m sharing a few of those excerpts. Following is a satirical attempt to those conversations:

Mr. Agile Coach (AC): Oh and you haven’t tried BDD!

Me: Yea, I am still learning. But I do know GDD (winking)

AC: And what is that? Never mind, are you SAFe certified?

Me: Umm, I thought it is fine to be unsafe... You know, running experiments, validating hypotheses, failing fast. All that kind of stuff.

AC: No I meant, are you Scaled Agile Framework certified? I am especially interested in v4.6.

Me: (coughing) No sir, I like being unsafe. Just kidding! I attended a couple of talks around SAFe, and I couldn't relate to it. So I left it at that.

AC: Do you know extreme programming?

Me: What about XP?”

AC: Can you tell me the 4 XP values, its 5 principles and 4 core activities?

Me: No

AC: I saw some stuff you’ve done around User Story mapping and Impact mapping.

Me: Yes, I find those techniques quite useful in ironing out a product roadmap and doing prioritisation.

AC: Those techniques are flawed. Have you tried feature injection?

Me: I’ve read some blog posts around it, but I haven’t really tried it yet. Happy to learn.

AC: In your paper, you say you’d do less when you have more time. Don’t you know the business would give you more work when you have more time. Scope will increase when you have more time.

Me: What I meant was, sometimes you can achieve better outcome and impact sometimes by doing less. And finding things to remove in a product than to add. I put a popular quote in my paper in that context “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away”. I also shared some examples of the products that are doing that, so I meant it in that context. 

AC: You have mentioned a technique of using business sliders.

Me: Yes. I use that to find the glass balls of my project that I need to take care of.

AC: I haven’t read any ‘Agile’ book that talks about such sliders. Also, the budget is always negotiable so I can’t really understand the usefulness of using sliders.

My hypothesis is that we need to go back to focusing on strengthening the foundations of agile rather than getting drowned in specific implementations of Agile. The foundations that have been written very simply in the agile manifesto.

I liked to relate my hypothesis to the following quote: “In times of life crisis, whether wildfires or smoldering stress, the first thing I do is go back to basics... am I eating right, am I getting enough sleep, am I getting some physical and mental exercise everyday.” - Edward Albert

In the context of agile software development, paid certifications and dogmatism to fit software delivery in certain agile frameworks is what I would call crisis and wildfires. And the basics of the agile manifesto is what I would choose to be referred more often so that we can interpret them to understand what they would mean in our individual environments or for the outcomes that we ought to achieve.

Can we go back to the agile manifesto, look at the principles and evaluate our work in those aspects rather than trying to fit our processes to certain implementations of agile methodologies. For instance this 'may' mean emerging with something like OKRs that can be attempted to apply to that particular software delivery organisation. Or going a step further is there a way that those OKRs can be attempted to apply to most software delivery organisations? As an example, if our objective is to value working software over comprehensive documentation, then what would that mean in our individual environment? Is there a way that we can interpret and apply this to most software delivery organisations, irrespective of the specific flavour of agile that they adopt?

For instance, I find the work done by Jez Humble and Nicole Forsgren very inspiring, to measure software delivery performance of organisations through four key metrics as specified in the book ‘Accelerate’. Can we do something similar when it comes to the process aspect? Can we find ways in which we can simplify the implementation of agile through measurements that can make sense to most software delivery organisations?

Another way to experiment this could be through real stories. How some companies across the world could be implementing agile in a simple and pragmatic form, focussing on the basic values and principles without getting too prescriptive about it and without getting themselves attached to doing things in a framework oriented manner.

These could be a couple of experiments to look into.

I am keen on learning how the community has been introducing change in big organisations that are operating like startups. Organisations that are still pathological and bureaucratic in their culture, yet are fast moving in their business goals and have a tendency to disrupt the market. 

As a coach I was called to support people, teams, and businesses on the  path toward a more sustainable, collaborative, Agile organisation. I often observed a huge tension between the intention and the reality of the behaviors.  Scale transformation are are seldom lasting ; some people change and they are more likely to leave the organisation that continue. I am very interested and passionate on bridging the gap between the true aspiration in a better work place and the power of the system in place and its collection of self-defensive beliefs that are part of what we sometimes call  “enterprise culture »

My hypothesis is that we Strive reassurance, Therefore we plan. There are situations, mainly in our personal life when we recognise that our plans are just wishful thinking. Sometimes we are so sadly sceptic about our bold plans that we cut ourselves from our dreams. Then comes the professional life. Here, on the opposite, we often push ourselves in an extreme state of denial and believe that our wishful thinking plan is the only acceptable reality. As a little inner voice tell us that the universe may care little about what our view of acceptable reality is, we seek ways to obtain some extra-reassurance via extra-plans: risk management, time to complete tasks estimations... and other complex expert analysis about everything-that-could-happen-in-the-future. Al these task the help us reassure ourselves of being right about the future to have a cost. I call it the cost of fear. i

I’d like to explore  a model that looks at an organisation as a system and discover our relationship to complexity, using the Cynefin model from a threat perspective.

I would like to have a deep dive on our relationship to fear as individuals, pairs, and group and relate this relationship with the Theory U change model. 

I’d like to make a link between our relationship to fear, TheoryU and the Cynefin complexity model

I’m sure there is emerging inspiration to be experienced.

After having worked with Agile teams for over a decade, it is my belief that you cannot force agility on anyone or any team. Some teams might think that this is some kind of coerced ritual that is a waste of time, there are others who are in awe of the Agile methodologies and in many ways, happier. How then can you ensure spontaneity or rather uncoerced change?

Success in bringing about change could be a daunting task but in reality it depends on one key point: acceptance. Acceptance of change comes naturally to a few but not all. In such situations, it is important to understand what you as a leader can do, to ensure change, willingly, without forcing an acceptance for change. It is imperative for leaders to understand what makes people tick. Here are a few aspects of leadership which can help introspect on what kind of leader you are and what YOU can do, to bring about change in an unforced way in your organisation or team.

Consider 2 teams, with people of varied levels of experience in each team. 

TEAM ONE:

-Give them the mandate that they have to change their ways of working and adopt the agile ways

-Tell them that they need to have scrum meetings every morning, have retrospectives, demos, reviews etc etc. and that you would like to see this happening like clockwork because this is what Agile is about

-Also, ask for progress reports, updated dashboards etc

-You also need to appoint a scrum master

-Give them piece of work to work. E.g: develop a feature you picked out for them

TEAM TWO:

-Explain to them, that we want to bring about a change:

• to improve productivity
• to get things done faster
• bring about accountability, and happiness (both can co-exist you know ;) )

Give them a few tips:

-They identify what problems can be solved or worth solving and what can be changed. 

- How can they contribute towards this change?

-Are there some ceremonies that they do not value and why? E.g: I have nothing valuable to provide in a retrospective meeting. Brainstorm alternatives, and come to a conclusion on what is agreeable to all. How can they come up with a workable solution?

-They pick a feature from the backlog (business need, of course) which they can deliver

-More importantly, convey this: "YOU trust them"

Over a period of time, who do you think, not only changed but also got the job done?

Team 2 (in all probability), and why is that?

-You let them decide, what has to be changed because they are adults and capable of decision making (even if it is not always the best)

-You let them make the decisions, while you steer the way. E.g: who the scrum master could be or what feature to pick (hopefully they have a few choices). 

-You let them fail sometimes

-Last but not the least, you do not breath down their neck but "You trust them!" 

Retrospect on what kind of leader you are: Are you dictatorial or do you empower?

Of course, you don't want anarchy and you might feel the need to control, but sometimes letting go can make all the difference between forced and spontaneous change!

Agile in large cross site teams

Having operated in a VUCA environment for 25 years as a counter-terrorist specialist and combat helicopter pilot, I have been witness to the emergence of leadership where ordinary people performed extraordinary results. I have been witness to live instances where a seemingly ordinary man performed extra ordinary work. What they performed was from what they were 'Being' and not 'Doing'.

I have questioned the prevailing presupposition in the corporate mindset that a leader has to have certain prerequisite traits to be an effective leader. Imbibed either through an elaborate certification process or through industry-specific skill sets. My inquiry is to invalidate the perception in the Agile environment that it takes special skill sets to be a leader, that can only be harnessed through programs,workshops and training. Through my personal experience and emperical data, i wish to support my hypothesis that Agile Leardership is more an ontological phenomena that has great relevance in a VUCA environment.

Leadership is an inborn characteristic of every human. It has an evolutionary existence for survival. Leadership is not about leading others to execute a task, but how to lead oneself along with others towards mission accomplishment. My hypothesis is that Agile Leadership is an ontological phenomenon that occurs in one's Beign and not in one's attitude, character or personality.

 Leadership is a natural expression of 'Being' and not special traits to be demonstrated. Leadership is just not about leading the way and getting things done.

  The constraints of the past, impinge this natural ability. Once, they are free from the constraints of the past, they are free to explore into new realms of possibilities. I wish to validate my hypothesis by proving how effective coaching conversations from an ontological perspective can effectively make a person become more self-aware of his or her existing 'blind spots' and how he or she can become more self-regulated and self-controlled thereby becoming a natural expression of their inborn leadership.

I would wish to know how critical are coaching conversations in Agile transformation from an ontological point of view. Why, How and What are the essentials to create coaching conversations as part of organisational culture. How such conversations and interactions reveal the natural leadership ability of a human from a 'Being'perspective, thereby making them more self-expressive, socially adaptable and free.

Sachin Ramesh Tendulkar, widely regarded as the greatest batsman who ever played the game, scored 9000 runs in 105 test matches he played between 1998-2002 hitting 31 tons at an average run-rate of 57. During the Australian tour of 2003, his scores read 8, 7, 55, 1, 0, 1, 37, 0, 44 totaling 153 runs at an average of 17. The whole world reacted "Yes, that's a slump." Of course, Sachin pulled himself out the slump quickly and went on to play for another 10 years for India scoring 7000 runs in 90 odd tests hitting 20 more centuries.

The term 'Performance slump' is generally associated with Sportspersons. But, doesn't this phenomenon sound familiar in other professions? Haven't we, as software professionals experienced a similar slump in performance in our career which at times was difficult to understand and unexplainable.  The slump is a period of decline or deterioration, during which a person performs below his /her performance levels.

Many times we have read or heard the expression - "Lack of form" associated with a sportsperson but without a pinpoint reason for the same. Experts believe that most of the time slump is caused by psychological factors, which may be triggered by a poor performance. And, the pressure of recovering from that bad performance leads to increased anxiety and reduced confidence. The lack of a support system (from family, friends, coaches or administrative setup) further aggravates the situation and the individual gets caught in the quicksand.  The downtrend continues.

My hypothesis is that the psychological factor is also the key factor for performance slump in other professions including software engineering. It gets triggered by an event either at work or in personal life. At work, it could be a performance appraisal or negative feedback by the manager or recognition of a peer. Sometimes, it is the monotony of job - mundane activities, routine tasks, lack of creativity, absence of accomplishment that reduces the interest in the job and pulls down one's performance.  Regorganization in the company, uncertainty, and insecurity of the job are other significant factors impacting the performance. In personal life,  negative thoughts caused by the vacuum created by the loss of a loved one or dissatisfaction caused by unrealistic expectations for oneself or one's children are factors that may adversly impact the performance. If these triggers are not contained in a timely fashion, the cycle of slump begins and very soon the person finds himself in a spiral dive.

As a team leader,  I have experienced top performers going through a performance slump. Upon probing, I found factors beyond skill and competence to be the cause of the deterioration in theire performance. Usually, I have used one-on-one counseling to help the person in this situation. The counseling spans over 3-4 weeks and focuses on the following basics:

1. Being aware and mindful about what is going on at present - Getting to stop the  mental time traveling
2. Staying Positive - It is critical to stop being pitiful and start believing in oneself. Talking to oneself and remembering the WOW moments. 
3. Having patience - Being patient is critical to slump busting because impatience may lead to pressuring oneself. Pressure, whether self-imposed or coming from the manager, always makes the slumps worse. 
4. Seeking Help - Many of us have inhibitions to share our problems with others. Seeking counseling from a coach or a shrink is very common in the western world but it is almost a taboo in Indian culture. This inhibition is not helpful.  One should share one's problems, situation, thoughts with others and seek counseling from the manager, peers, friends, and family members.
5. Taking time out - Work-life imbalance is also a fuel for Slump. Slumps are signs that we are running low on internal fuel and you need to pause and relax.  Taking a short break from work and doing something that one enjoys helps. 
6. Stopping the blame game - Many times, we accuse our managers to be biased. We take their feedback negatively. We blame the organization and its policy to be unsupportive. All these negative thoughts only push us further in the quicksand.

I have used the above approach informally with several of my team members (direct as well as indirect reportee) and have seen positive results. I have also coached my direct reportee on slumpbusting and some of them have practices it successfully.

I believe performance slump is a critical but unaddressed challenge in corporate life. I reckon that coaches can play an important role in helping individuals overcome performance slumps. I would like to share my experience with fellow coaches and validate my hypothesis and experiments by hearing their feedback and thoughts. Agile coaches are expected to coach teams on the mindset and happiness quotient. I think it would be a great idea to extend the responsibility matrix of Agile coaches to  include slumpbusting. The approach could be further refined to include measurement of the effort spent and results achieved.

On one side, we usually hear “change is hard”, “people are not ready”, “it takes too long”,” “the management doesn’t get it”, “there are too many silos,” “it won’t work here,” “people are not engaged,” “there is no buy-in.”   On the other side, coaches and no coaches always say that Agile transformations imply a cultural change, which means changing collective believes and behaviors.

We all know that cultures and mindsets do not change by talking about ethics, injecting rules of conduct or codes of behavior, or fixing a list of values along the walls. They do not change either by bringing frameworks or methodologies. In fact, each year more and more management leaders and instructors self-called “coaches” realize that certifying tons of people in Scrum or scaled frameworks does not produce the desired change (certainly it is easier to sell heavily-marketed certifications and workshops than helping organizations become more Agile).

For a couple of years, every time I think about “driving change,” four thoughts come to my mind:

1)  I’ve heard twice someone saying, “stop selling frameworks and teach people what Agile means.” Each time I wanted to say, “let’s start a movement.”

2)  By talking with a number of psychologists, dating a couple, reading medical papers, and looking at my own personal and professional failures, I finally accepted a fact: believing that you can change someone’s beliefs, habits and behaviors –whether kids, parents, friends, partners or co-workers– is a very long, frustrating and disappointing odyssey.  I wonder if that was what my mother tried to teach me when I was a child: “stop trying to change your dad. You’ll lose that battle. Just become his friend and you will win.”

3)  One of the best definitions of culture I have seen is “the stories we can tell ourselves about ourselves.”  I wonder if we should forget about culture, behavior, or change itself, and instead focus on “changing the stories we can tell”?  Since different behaviors and habits necessary lead to different stories, this would be like reversing engineering.

4)  Every time coaches address topics such as collaboration, psychological safety, high-performance, healthy conflict, and respect, we landed on the same word: trust. And I always say/answer, “I can hold your back, if I know you will hold mine. But how am I going to hold your back if I don’t know you? The only thing I know about you is that we work in the same company/project.” The stronger the foundation, the stronger the relationship  --which in turn increases trust exponentially.

"Focusing on forming relationships might produce more effective and faster results than focusing on rolling out frameworks, changing behaviors, fostering cultural changes, or cultivating new mindsets."

"If we make relationships our focus point, a (the) new culture might evolve by itself."

"Focusing on developing relationships –like a spider net inside an organization– might produce the change we are looking for:  changing the stories we tell about ourselves = strength relationships at different levels = increase trust exponentially = foster partnerships quickly = change collective beliefs = modify behaviors = create habits = evolve the culture by default."

Two years working with a financial institution, starting from scratch, banning words such as change and transformation, and avoiding terms and descriptive roles from frameworks.   Instead, I focused on building as many strong relationships among people as possible, taking advantage of every opportunity to make anyone get to know deeply each other in a personal and professional way –not only as individuals but also as a group (dynamics and collective interactions).  So far, it has been one of the most amazing and rewarding jobs I’ve ever had, with surprising and very effective results. From zero Agile to a completely different organization, with clear strategy, visible goals and a nice culture.

CLEAN LANGUAGE: the main source of conflicts is the belief that we are always right –which is the result of our own assumptions, bias, experiences, thoughts, presuppositions and opinions. When judgment –whether conscious or unconscious– comes into play, relationships become unleveled and trust does not emerge easily.

POWERFUL QUESTIONS: the usefulness of the knowledge we acquire and the effectiveness of the actions we take depend on the quality of questions we ask.

Actionable TOOLS AND ACTIVITIES to foster deeper relationships: anything that set the right stage to understand each other, the way we and others think and feel, our and their emotions, passions, frustrations, challenges and dreams.

As an agilist, we always speak and advocate/ promotes about the transparency within the team as well as with management or the leadership.

But do that really exist? Do we really have the transparency where team can talk about what they feel and management/leadership is receptive of that?

Creating a real transparent environment where people can affirm of a flat hierarchy and people are not intimidated by management and can speak of their mind.

Last couple of years , I have been observing on this struggle faced by everyone . Once such implementation which I had used or recommend the usage of "Smell-O-meter" on daily basis. Using this in physical boards  had improved a lot of transparency  within the team as well as  with the leadership team  .

Also I had run a couple of anonymous surveys  "What I thinks about you" has help the team and the leadership to understand each other and expectation. 

I would like to understand how others have achieve this where there is total transparency between leadership and team. 

Last year agile coach camp was an eye opener for me. It was so enriched experience to meet and learn from the stalwarts from the industry. I believe it will be the same case this year as well.

Like last year, I am keen to meet and learn from others "what's new" in the ever-evolving agile world.

In today's industry era, we always talk about "Agility" and "Transparency" in the Transformation Journey, but we definitely need to analyse whether transformation journey would be successful without "Collaboration" and "Teamwork" and how "Coaching Community" can make the transformation journey effective with bringing the people together, inspire the achievement of shared goals and provoke win-win solutions.

Also, the responsibility of Coaching CoP to bring awareness among the people, generate desire, apply relevant knowledge and ability to transform them into new vision and focus on sustainability in long-run.

Key Mindset Shift and Behavioral changes can play important role for working as a team with self-organized and collaborative way to deliver the value to the organization. 

Now, how to bring Mindset Shift and Behavioral Changes ? 

• Think big, but Start small
• Ask questions to audience "Why" and "Why Not"
• Don't provide any upfront Suggestions, help them for "Improve Thinking"
• Test Quick and Scale to Size.
• "GROW Model" on Coaching Assignment/Roadmap  to measure the success.

* GROW (G - Goal Setting, R - Reality Check, O - Options Discovered, W - Way Forward)

Few ingredients of collaboration and teamwork :

• Focus on strengths of the team (individual and collective)
• Commitment to teamwork
• Respect each other in team
• Courage to take decision together
• Openness to say "No" and ready for "Productive Conflict"
• Alignment to a common goal and shared vision
• Cumulative results that are measured and published

I would like to explore different coaching models and hear from other Agile Evangelists which can definitely bring value to the organization to transfer into Agility.

• Value Creation (Building bonds and connections)
• Resolving and negotiating to create optimal solutions in situations of conflict.
• Inspiring, guiding the people towards the vision and goal by using the "Golden Circle" (WHAT-HOW-WHY)
• Removing Organizational Level Impediments with Leadership Coaching Strategy

There are almost 40 million Google search results about the phrase “why does Agile fail?”  There is a wide variety of perspectives about what the causes are. Some of the cases cited in various articles include:

• Agile is pushed from the top-down and the people don’t understand why
• The organization adopts “agile-in-name-only” which means they use agile terms to describe their existing processes
• Failure to change the mindset and/or culture
• Failure to adopt technical practices

There’s no shortage of theories about the importance of organizational alignment. Here is a process that we can use in creating alignment.

Lean Change Canvas combines Lean Stack thinking with Kotter's 8 Leading Steps for Change. It's a tool to realize organizational change fast and effectively by continuously proving small, minimum viable change increments with measurable experiments.

Think Visually When Building an Agile Enterprise Change Plan. 

A picture is definitely worth 1000 words when trying to articulate the true north for an organization undergoing massive change. 

The Lean Change Canvas relates the typical canvas elements to organizational change context; maps each canvas element to one of Kotter's leading steps identifies risk classes and proposes a certain work order for the quadrants.

In Lean product development, we regularly inspect and adapt by

1. building prototypes ("hypothesis").
2. testing them on the intended focus group ("measurement" = "inspect").
3. improving your product/hypothesis ("adapt")

The "Lean Change Iteration Meta Pattern" reflects Kotter's 8 steps of leading change. This pattern must be an integral part of every minimal viable change, we plan to deliver.

It´s important to select and develop your own change process that best suits to your organization. There are 4 main components to developing your own change management process:

1.Developing your Strategic Lean Change Canvas
2.Aligning your organization
3.Developing your Change Agent Network
4.Executing the Lean Change Management Cycle

How to use Visual Metaphors more effectively

Number of organisations move towards Agile Way of working which is preliminary focused around the development and delivery practices. Strategies and Objectives are set to move towards new ways of working, which is the need of an hour for the organisations. In such situations, there is a tendency to ignore service management despite of strategy being explicit about it. Customer wants faster and valuable service but most importantly the stability of it.

We need to embed service management best practices (such as ITIL) as norms. There should be wide spread understanding of the Business, Customer and Regulatory impact due to service stability issues. Data is the key - measure service stability data and present in a meaningful way to take proactive decisions. The business value should be assigned and showcased on the service stability data. Injecting service management practices as part of team's DNA is the key for the sustenance.

Have been working with some of such teams under one business unit. Embedding a culture of ownership of Service management and developing Data driven organisation are the keys. Embedding service management best practices, Measuring and Presenting meaningful service stability data, monitoring on real time basis, daily stand-ups as checkpoints to take proactive actions and showcasing the service stability to the customer. Once the service stability reaches to acceptable level for the business, it will be done with the rest of te organisation in a phased manner.

Keen to know how transforming organisation are handling service stability and overall service management. How DevOps practices are applied and made a difference? How do the organisations sustain the service stability?

Understanding the level of freedom of your coachee for you to approach the coachee for the coaching conversation. This will help to understand the situation /context of the coachee for my probe

How to understand the level of freedom of each employee in an organization and how managers can:

• Train employees to become self-reliant rather than boss-reliant

• Free up time for personal and professional relationships

• Attend properly to planning, organizing, and leadership—making sure things stay on time, on track, and under budget

• Confront the belief that "If you want something done right, you've got to do it yourself"

FREEDOM SCALE

Like most employees, managers want to make their boss happy. They don't want to step out of line but often don't know where that line is drawn. Managers working under a cloud of anxiety will not perform as well as they should. They will often bother their boss with minor details in order to save themselves from doing something wrong. Bosses need to free managers from this complication. William Oncken Jr., author of Managing Management Time, created a  "management freedom scale" to help managers understand how to make decisions. 

CONSIDER THIS: If a person does not know what is expected, he cannot effectively make progress in an organization. Tell your employees what you expect of them.

want to explore this five-point scale which lists the most common ways in which managers approach the decision-making process:

1. WAIT until being told.
2. ASK what to do.
3. Recommend, then ACT.
4. ACT, but advise at once.
5. ACT on your own, routine reporting only.

Option one should never be allowed. In ordinary situations, managers should not pester their boss by asking what they are supposed to do. Managers are supposed to think for themselves. Managers should be told they must operate under options three, four, or five. This frees the boss from having to make unnecessary decisions and frees the manager to devise methods of leadership that work well with his or her personality.

Just to contextualize a bit, this is about Agile Coaching teams working in a regulatory compliance environment; who have no standard way of working and with innate anti-patterns. While it appeared that senior Leadership bought in the need for an Agile transformation, middle-level management, and team members exhibited huge indifference and did not get involved. While there were few bright spots to cause the change ripples, largely it was hard to set foot in.

Any team working in a highly regulated environment that resists change and not up for Coaching can also be coached

Through establishing a periodic feedback mechanism, a Coach could help teams embrace change and utilize coaching better.

1. Facilitate effectively to build a sustained feedback loop(solution focus would be a huge plus!)

This meant designing coaching interventions to facilitate good retrospective sessions

2. This helps psychological safety in due course with good facilitation

3. This creates trust and self-organized teams when they are rewarded and noticed for their actions.

4.Design all coaching interventions based on the evolving mindset shift of the team(Saw the team evolve through Shu-Haa-Ri stages, owned their reflections and backlog items emanating from retrospectives)

5. Add fun element in retrospectives, catch-ups and offsite events based on the team member's appetite

Coach the scrum master and change agents to run and sustain regular feedback loop

Try a solution focus based, Hero's journey retrospectives along with carefully curated game activities during each retrospective session.

Solution-focused coaching.

One thing that I am keen would be on Effective Facilitation techniques, specifically remote facilitation.

In my day-to-day life, when it comes to implement an agile framework or to sustain with agile in VUCA world ACE helped me in all the ways. At the team level, enterprise level, project delivery and at program level alignment, communication and engagement are the keys of success.

Being a mentor, coach and change agent, I am dealing with the process and people. As an agile practitioner always believes in four values of agile and would like to see people around me follow it religiously. These three keys Alignment, Communication and Engagement help them to be focused towards their successful achievement of goal in VUCA world.  

Alignment in agile enterprises is not limited to people and skills, but we can see it at each level from all the aspects:

• Alignment at product level
• Alignment at process level
• Alignment at technical level

Agile encourages a casual and direct form of quality communication that provide environment to the client and development team to work more closely together and always be in sync and on the same page.  Frequent communication helps agile teams in better performance, which results into a satisfied customer and a much better final product.

Agile influences improvement in team members Engagement through values and ceremonies. Agile Team members know better:

• What they have to work upon?
• They know what skills and equipment required to deliver work better.
• Clear vision towards set goal
• Their opinion matters and can share failure/success as a team.
• They have the opportunity to learn and grow

Whatever I am sharing here is not an experiment but an experience.

Alignment helps enabling autonomy, agile teams need to be self-organized to be efficient whereas, enterprise needs to be efficient by maintaining alignment among across teams.

Agile is based on openness and feedback. Effective communication helps in building a better culture within the enterprise whereas frequent feedback/communication in agile team’s results in better performance of the teams what helps them deliver better product.

The Engagement approach empowers people across enterprise seek feedback in such a ways that helps on a shift in the cultural mindset. It improves collaboration among teams, business and customer easier and more focused.

This will be my first experience with the coach camp, looking forward to exploring new techniques of coaching and agile way of working with knowledge sharing with the agile practitioners.

In a rapidly changing technology world, it becomes of paramount importance for every knowledge worker to stay abreast of the changes and updates. As individuals we are guided by our own interests to specific types of technology and management studies. In the past few years, I have been researching on the entire concept of stakeholder engagement in project management. As much as managing the team and the resources is necessary, so is, managing all the stakeholders. Yet there are no specific frameworks across industries and sectors which can help guide middle level project managers to engage with stakeholders effectively. Coaching therefore is perceived as an important tool to guide and direct the project leaders/managers to navigate their way through the complex ways of engaging with stakeholders. As the demand for large scale implementations rises, complexity of the engagement increases. There is a need to understand and analyze the specifics of stakeholder engagement through the eyes of a coach. The coach is at the center of the agile project universe, which is a paradigm shift from the project manager being at the center in the predictive methods.

H1 - Effective engagement of stakeholders contributes to project success
H2 - Enhanced interpersonal skills are directly related to better engagement of stakeholders
H3 - Coaching can help improve the interpersonal skills of project managers and scrum masters

Create a qualitative survey to tap into the experiences of project managers and scrum masters
Probe into the benefits derived from coaching
Categorize skills into seven out of nine different skills refer the SHRM competency model

Understand the various inputs received by the two groups
Compare results and establish the hypotheses

https://www.shrm.org/learningandcareer/career/pages/shrm-competency-model.aspx

I would like to understand how my research study will be beneficial to the coaches. I would like to understand from the coaches to refine the parameters of the study and focus on those which are essential to the effective engagement of stakeholders. I would like to hear from the coaches on their experiences with the two groups and suggest how questions can be different or similar for the two groups.

If you try hard and look around without any bias, you would agree that Agile Methodologies are today no more than a Mangalwar Puja Tradition.

You do the puja even though you know that it is not working for you and anyone else around you. And if that weren't enough, you compulsively look out for newer Mangalwar Puja experts who don't waste time telling you that your product is doomed until you follow the rules prescribed in the True Agile™ Mangalwar Puja tradition.

Blaming Agile is not the point We must ask, how did Agile, which was originally intended to emphasize uncertainty and learning, become synonymous with high-frequency water fall? Have we eulogized iteration without understanding its trade-offs? My hypothesis is that

1)You can't build better products if you don't shape them actively

2) "Shape Up" methodology pioneered by Basecamp provides a strong foundational position to challenge the Agile Mangalwar Puja tradition

2) You can't shape your product actively without thinking like a storyteller. The easiest way to understand shaping your product is to start seeing your product as a story which happens in the arrow of time. How do you unpack your product as a series of causal chain loop right right from the moment your product is conceived to onboarded to experienced?

3) When you think of your product as a story, you affect everything about your product - its comprehension, utility, perception of usability, memory and choice

I have been coaching my clients on building software products using Shape Up methodology and it has become a strong foundation in which my critique of Agile Mangalwar Puja tradition is placed. I am happy to share some of my learnings in the trenches of Shape Up methodology

I would like to learn more about on-ground technical challenges in coaching clients. 

Vendor Agile and Cycle of adaptability. Services Agile is not the same a Product Agile and the same principles do not apply. Agile transformation, agile adoption and agile maturity are not the same when dealing with a highly volatile services market. How do we then ensure we make agility stick and what changes in culture and mindset is required to make Agile work in a constrained environment.

People and teams make or break Agility

Dynamics of Learning and Safety will decide the outcome of agility

Pre-Agile recipes that help the team understand the why and how.

Intermediate stage where Agile is run more for the sake of doing Agile

Continuous Adaptability as a process and Continuous Improvement as an aspiration

How Quality of hiring and the dynamics of high performing teams intersect and what is the middle ground we can look at to make small changes to self organising autonomous teams.

We have 3,000 people in Chennai and Bangalore who work for CommBank via our technology partners HCL and TCS. Over the years I have been connected with our colleagues in India, but when I started working closer with them and travelled a few times to visit, I realised that I was somewhat ignorant of the cultural challenges they have with feeling included as part of CommBank and feeling safe to speak up.

In Oct 2017 I travelled to India for the first time with my colleagues Tony and Simon. We talked to people from many different teams, some working with CommBank and some from other companies who had also established a model with people working in different countries and cultures. It was interesting to listen to their experiences and how the happiest and highest performing ones were where the barrier between the organisations had been fully knocked down and they felt as one team regardless of who works for who formally.

Many other people based in Sydney seemed to share my ignorance of the challenges our colleagues in India faced. There is a fear of speaking up and resistance to being fully open and transparent, which has come from the mindset that they work for a supplier (HCL or TCS) and that we work for the client or customer (CommBank).  This is the barrier or wall that I wanted to tear down.

On my visits I made connections with many coaches, scrum masters and leaders based in India. When I returned to Sydney, I invested time to connect fortnightly with them, and to switch on my Skype camera to re-create the power of face to face contact, which is so important in maintaining and growing a distance relationship. In these connections I made the space for them to speak up and share equally and encouraged them to try new things in their workplace that they thought would make a difference. I also made an effort to change my language and they did the same. We no longer used words like ‘onshore’ and ‘offshore’ to describe where we are located, and instead use the more inclusive terms like ‘Sydney office’ and ‘Chennai office’….a small step but one brick at a time the wall started to fall.

2 years on and we still connect fortnightly and still see each other’s smiling faces. We check in and share how we are going at home and at work, and problem solve issues that they need help with. The creativity and ideas I have seen come from our colleagues in Chennai and Bangalore have blown me away, and all I did was create a safe space for them to contribute, to be themselves and to have fun. This is what true inclusion can give, where the walls between organisations are knocked down and people feel they have a genuine equality of voice regardless of who they work for or where they work

Just keen to meet and learn anything and everything from the people who attend

Competency based distributed matrix organizations lead to silo-ed way of working

Creating "One-Team" mindset, Strategically change the systems in a phased manner with a road map

End to End ALM Tool,Collaboration tools, Telepresence/Video Presence, Group chats, Fun events, Sharing more success stories

Enterprise Business Agility and any End to End Scaled Agile frameworks

Large scale enterprises struggle today have a desperate need to change the ways of working and their operating culture, courtesy the legacy nature of products built over years.

My hypothesis - "Could Technology and Empowerment come together" in creating a fluid culture of communication flow and connect the broader vision with an Engineer's code.

G2G (Governance to Guidance) is an experiment that took shape with a definite scope in mind. 

The experiment could be validated if a connect can be established between strategic and tactical priorities. Awareness of broader organization vision to an Engineer and visbility to Engineers work upto the leadership ladder.

The coach camp is my favourite format to engage and learn with practitioners and leaders. I am keen to walkaway with - 

1. Insights from coaches driving organisation changes

2. Tackling the challenge of leaders v/s mindset

3. Discuss with a open-mind on patterns observed coaches

As more and more organizations are adopting the Product organisation structure, and DevOps teams, as a service organizations we are often faced with this question on how this change will impact utilization and efficiencies. Will there be an adverse impact, especially if we let go of the efficiencies of scale we derive when doing operations as a horizontal service.  As we are embarking on enabling such a change to a Product oriented organization for a large client, these are pertinent questions that we are facing.  When there is a legacy portfolio which needs to be maintained, and we are now organizing teams around products, how much should we verticalise, vs what should be horizontalised ? In one case we have seen that client wanted to move back to horizontal operations from DevOps teams as the amount of maintenance work was too high and teams could not focus on feature development.  While there is enough said in Kanban on resource efficiency vs flow efficiency, in the context of end to end verticalization of teams with dev, ops and infra aligned, how do we find the balance ?

When we focus on end to end value, the benefits far outweigh the benefits of utilization. While cost efficiencies is an important factor, it should not be looked at in isolation as efficiencies for certain services, but from an end to end product TCO perspective. Also, automation plays an important role in such a transformation. However, these benefits take time to materialize. 

Would like to understand from fellow coaches on how they have navigated this issue and resolved the efficiency paradox.

Is it possible to do a cost benefit analysis, using key metrics like lead time, velocity, business value, automation index, TCO that would help us arrive at a better understanding on when it makes economic sense to move to product teams.  

Driving and sustaining pace of change, and keeping up the motivation levels of teams during the transformation journey, in the face of roadblocks and setbacks. 

Every organization comes across complex problems and with an approach of breaking those complex problems into small chunks and then addressing them one by one is always a go-to approach. In general terms, there ain’t any flaw with this approach infact it has always turned out to be one of the efficient way of tackling the complex problem.

Embracing design thinking helps create new products that adapt to changing market conditions. It’s also realistic: All businesses must become more service-oriented and offer a stronger “customer experience.” As the distinction between products and services blurs, so does the distinction between consumer and producer.

One of the complex came on our way too when we were given a task to build “Peer Review Solution” application used for helping editors throughout their journey which begins from finding peer reviewers for the paper/submission they have got for their journals till finally providing the final decision to publish or not to and not to forget the key part of journey of getting and consolidating the reviews received.

When seen from the lens of another agile approach, it's evident that feasible results are obtained when customer trust is there in knowing that you have identified his/her problem statement and he/she is part of all the stages of SDLC and not kept isolated.With the above background its clear that we were in greenfield project approach where nothing was known to us about the product hence, it was important to select some approach to start of with and involve end user in every step to understand and learn the where about's as and when we progress.

I propose using the ‘Cognitive approach - Design thinking ’ which aligns the customer requirements and also makes you not only empathize with your end users but ideate with them and showcase them with something tangible early in the period and get continous feedback and thus creating the "WoW" factor.

To validate this hypothesis, we kicked off with cognitive approach i.e. design thinking by bringing every singe stakeholder from end user to technical architect to developers in one room for two weeks and conducted a workshop and post which we had something to know about the problem statement and MVP and then we met once every sprint to get regular feedback and keep showing our progress thus resulting out giving the end users with MVP product to kick off their tasks in six months.

Ways how other organisations are working on making themselves involved more with their end user and creating a "WOW" factor for them and hence creating a culture of learning and innovation.Would like to understand how they are able to sustain on the actions they are taking.

As change agents/coaches, we are also impacted, hence how can we make sure that teams are getting the environment and transparency and courage to be visible to their end users and working with them.

In my professional experience, I have noticed organizations trying to push a change from top and fail miserably! One of the key reasons in my opinion, is poor communication of the 'purpose/vision' for the change and what benefits it will bring to the organization. Unless everyone has some inputs for their 'What's in it for me?' question, they won't on-board the journey of change. It will be hard to communicate a difficult decision/change, but it will help the organization to retain their employees' trust and brand value.

My hypothesis is, if an organization values it's relationship with its employees they can execute even a difficult change (eg: headcount reduction) very smoothly. For sure there will be difficult emotions, but if the employees are compensated fairly and supported to find their alternate source of earnings, the brand value of the organization can be retained. Also the employees who are leaving now can re-join in future! Else if not done with empathy, it can have a very nasty ripple effect for the brand value in the industry.

Experiment which I would like to run:

Round 1: Communicate a difficult change (that can be done with in the room) to only a few members in the group and ask them to make the change in the room with out announcing it to everyone.

Round 2: Communicate a difficult change (that can be done with in the room) to only a few members in the group and ask them to make the change in the room. This time they can announce the change to everyone.

Measure the time taken in both the rounds.

At the end of both rounds gather feedback from the group about their experience in both the rounds. Also gather feedback from the selected people who were tasked with making the change happen. 

How to EMPATHIZE with your employees is the concept which I would like to explore during the coach camp. I have applied Design Thinking techniques in my career and would like to bring my experience to the table.

During my academic & professional experience, I have aspired to go after high and lofty goals. And overtime, achieved (most of) them. What I didn't realize was that I was constantly adapting to small changes through my behavior (again small) that helped me achieve those goals and where I failed was where I didn't quite follow this paradigm.

My proposition is that even though teams align to a common vision and work towards them, in an increasingly VUCA world, having the ability to adapt continuously can get you (and the team) to succeed. When you adapt, you're inherently changing certain behavioral traits in responding to the changes that fire different neurons in your brain. Essentially, it is improving your experience and making your presence fully engaging. This improves learning, morale and guides you toward a self-sustaining group.

There are a few things you can experiment with your own habits in your daily life as a precursor to trying them out in the professional context.

The experiment I'd like to run is to outline a couple of habitual changes that participants can try. After that introspect on the feedback coming to oneself on the accomplishments (or otherwise). This can validate by extension the behavioral changes, if tiny and practiced over some time consciously, can lead to small group behavioral changes that helps in sustaining and driving change.

A couple of exercises which we encounter in our daily lives can be explored - initially as an individual and subsequently in a group setting (or in pairs). This is to demonstrate the power of tiny changes

It is quite common to observe behavior change after a triggering event or a Sentinel Event. Common examples include smoking cessation after a cardiac-related health problem, reduced alcohol consumption after an intoxicated driving collision. Well documented in healthcare, these events open a window of opportunity for the individual to embrace change due to amplified receptiveness referred to as teachable moments resulting in Sentinel Event Effect.

The Sentinel Event Effect concept can be extended beyond one’s health to the workplace to drive positive change. (Here, the sentinel event itself need not be negative in nature as is the case in healthcare.) This can be done by creating/identifying events that increase perception of risk, elicits a response, and/or represents an experiential change either at individual or organizational level.

I have not carried out any experiments and therefore would like to list teachable moments and the subsequent effects hearing from Agile exponents. Pick the top 3 such events and determine indicators that can measure the change.  

I am keen to have a discussion on my hypothesis and build on the group’s collective experience.

As the organization grows, Silo naturally exists.

The word “silo” today is thus not just a noun, but can be employed as a verb (to silo) and adjective (silo-ized). And the crucial point to note is that the word “silo” does not just refer to a physical structure or organization (such as a department). It can also be a state of mind. Silos exist in structures. But they exist in our minds and social groups too.

In terms of collaboration and getting things done, people oftenly sees Silo as a disadvantage.
But there are times that people failed to understand: Silo naturally exists, as the organization grows

In team, department or organization level: knowing the history, purpose, advantage, and disadvantage are helpful to observe, diagnose and master it (Silo).

In addition, keeping these factors in check:

• Boundaries in a big organization flexible and fluid
• Reward and Incentives
• Information Flow
• Re-taxonomy how we organize / works
• Use “Technology” to challenge our Silos
• Thinking as an insider & outsider of the Silo

Is beneficial to master Silo

There are approaches that can be selected - situational based

• Innovation (Week, Day, Hackathon)
• Change your formation regularly
• Change your word (re-taxonomy)
• Understanding power dynamics
• Opening Information to all member / transparency
• Keep improving the organization’s Performance Management System
• Make people think as an Insider and Outsider
• Help different teams to collide and bond
• Create unplanned constant interactions

Try doing experiment based on your own context

Keen to explore other Silo pattern, and techniques to master Silo

• How do you turn Silo to the organization’s advantage?
• How to turn teams to be more collaborative?
• How to drive more change, from the grass root level?

Agile transformations happen in a certain context. with two very critical parameters. One is the orientation of the coach who is guiding the transformation. The second is the leaders’ who are key stakeholders and decision makers in the organization being transformed. Depending on this, different results have been observed in programs. This is an attempt to capture the same in a model. It looks at the combination of those parameters and possible outcomes. In the ideal world we would expect an agile coach to have a balanced approach focusing on both practices as well as mindset change. However in reality often a bias is observed, orienting the coach and the leader towards a particular disposition.

The VUCA world is not linear. These are definitely not just the two parameters that are involved and more importantly people are not black or white. These are complex systems. A systems model based approach looking at their major dispositions allows us a thinking tool. It can be leveraged for better discussions and probing solutions.

The diagram below represents the hypothesis in the proposed model. The X axis represents the coach disposition and Y axis the Leaders’ disposition. It leads to a 3 x 2 grid that describes the possible transformation outcomes with the combinations. The hypothesis is further elaborated in the blog given below

http://hrishikeshkarekar.com/2020/01/influence-of-coach-leaders-bias-on-agile-transformation-outcomes/

The model described above is a conceptual model. It is primarily based on personal observations and discussions with many coaches who have been involved in large scale agile transformations. Like all models, its a thinking model. It can aid in understanding a context and taking corrective actions it’s still a hypothesis.

I would like to run a survey that will provide empirical data that validates or invalidates the hypothesis. Survey results from seasoned practitioners would definitely throw more insghts that validate and can help to refine the model further.

Advanced system modelling techniques or a real life example that uses causal loop would be very interesting to experience.

In today's organizational world, almost every organization wants to go through an agile transformation on the ground. But the reality stays that though this desire is formally implemented by the organization's leadership through their vision and strategy but the efforts to change the situation on the ground do not match up and the transformation only becomes a very superficial effort. I would like to understand how to drive such transformation from a bottom-up perspective. 

1. Trying to implement agile frameworks and methodologies for the ground level implementation
2. This has not worked well probably because there is a lack of understanding of the benefits of using agile approach in R&D/innovation space and in the execution of projects in this area

I would like to understand how other organizations and/or agile coaches manage this and reach a desirable end state. Further like to get help on what kinds of tools could help in achieving this.

Discovering the appropriate tool kit to be applied for the purpose

Driving change needs self discovery of what practices can work/are working and the teams need to imbibe an agile mindset to be successful in this regard

A coach might be viewed as an 'outsider' and so may not be accepted. Instead, a small group of internal change agents in each team might help drive change better

I ran an experiment in a couple of teams wherein I first recruited volunteers to drive the change to agile. There were certain behaviors expected from these volunteers and were listed as ground rules: Early adopters of agile with following behaviors
• Highly enthusiastic and believers in agile/change for better
• Responsiveness to emails/communication (don’t want people who say they
are too busy)
• Devote personal time, including weekends, for learning
• Reading habit is a must; should be able to read articles/books, watch
recommended videos and discuss takeaways
• Be able to run scrum for adoption of agile in the department
Scrum teams for deployment of each improvement strategy: Kanban, TDD, Test
Automation etc...

Based off this experiment, I found that acceptance was much better. I, as a coach, watch from the sidelines giving the authority and hence ownership to the internal change agents and guide them towards the path of learning and reiteration of the values and principles of agile

I would like to hear from other people about how they worked to remove organizational level constraints that impeded the change to agile

Most of the work we were doing in the last couple of increments required us to re-skill. From working on legacy apps, we needed to develop proficiency in new scripting languages and tools (workflows, reports, rule engines and so on).

To ensure we learnt these new tools efficiently - and build reliable solutions, collaboration was not an option - it was a compulsion. The question we were trying to answer was - 'How can we change the way we work  - such that collaboration is not an option - but is rather a way of working?'

Sure, we've always collaborated as a team - we've swarmed on stories, we've collaborated when we encounter problems, but if we are to learn new skills efficiently we needed to collaborate upfront, rather than collaborate as an afterthought.

The answer to this, in our view was Pair Programming. To be sure we were heading in the right direction we consulted with chapter lead, squad lead, agile coaches before taking the plunge.

We chose a sprint to try this out, and during sprint planning we floated this idea and went through a short video on pair programming 101, thereafter we agreed to work this way for a few sprints. Team members chose their pairs -  generally people who get along with each other tend to pair-up.

Some other desirable side-effects of pair programming we observed during our experiment:

• Fewer discrepancies of skills across team.
• Fosters a greater sense of team camaraderie.
• Better quality, more reliable outcomes, lesser re-work, just-in-time code review.
• Better throughput - as team works sequentially on stories vs concurrently.

Some considerations while deciding on pairing:

• Deciding on pairs is tricky. Needs a great deal of trust with the pair.
• Since we are learners we were novice - novice pairing, however with a new hire, we may experiment with novice - expert pairs.
• It is believed this doubles cost, however we disagree!
• Requires a high level of team maturity. It’s a challenge pairing when one is working from home!

What's next? As we evolve in our journey as a squad, we plan to continue with this experiment and maybe it just becomes the way we work.

This is a case study of product where the very first thing which I observed was unclear roles and responsibilities within QA’s  of an organization. There was a low test coverage as there was no clear testing strategy to follow. Getting deployed to production was “Push and Pray” method which led to high risk for production

It was also causing inefficient use of QA timing. There was the pain felt throughout the organization in a smaller group and folks kind of accepted this pain. We started with noting down the pain points of producer and consumer teams within an organization and even a third party team to come up with an effective test strategy of the product. 

  Participate in this talk to learn how we formed a core team to define the external and internal strategy. How did we apply recursive feedback and updated the strategy when and required after a production release? Internal Test Strategy: A strategy within a Team of same vertical like checkout api and ui. External Test Strategy: An end to end test strategy of a product. How did it help in getting away from “Push and Pray” deployment to “Continuous and Confident” deployment to production? We got the motivated QA’s across the organization and better quality product with a Test Strategy across an organization. It had also helped in mapping a QA learning curve with a test strategy within an organization. Example: As a QA if you would like to learn some tools and techniques of testing you could volunteer to help the other team which are using those tools and techniques and in long term, you could switch the team if it matches

Agile methodologies are one of the most effective approach nowadays in implementing software in the industry. While implementing these processes, the constraints experienced by major stakeholders are analyzed. In this paper,two major stakeholders are considered-The stakeholders who are benefitted through this approach and the Team members who have implemented the system.The team members are having different opinions with different levels of efficiency hanging onto traditional practices and unable to consume innovative practices of agile. They are having fear about the effectiveness of team involvement and having a sense of insecurity about the benefits of work. Through this paper, an attempt has been made to identify the constraints as well as attempted to remove the constraints experienced by teams in shifting towards agile.

We have identified and consolidated the list of measures which needs to be ensured proactively for a smoother transition to Agile. Based on our experience it is recommended that organizations implement these practices in order to achieve the benefits of Agile for greater success.

A survey was conducted among 20 employees of different organizations in various designation engaged in Agile methodologies through different set of questionnaire for different kinds of people.We hope this will definitely quench the thirst of agile enthusiast. 

I would like to connect to different kinds of people interact,share our learnings with each other and contribute to the testing community as a whole.I would like to learn more about agile,leadership skills,training and coaching teams.

Leaders today are not considering the mindset and behavioural shifts that are necessary to make transformational changes and lack setting a clear road-map for a cultural change, without considering the disruption and deficiency in productivity gains. In today's UVCA world, a more flexible, innovative and risk-taking mindset is required. 

Change will lead to some form of disruption. The appetite for disruption should be considered. How leaders should be able to measure this and set a baseline for absorbing the disruption without serious implications. 

Case study of two leaders, one with an agile mindset and another with the traditional mindset. How they bring about cultural change in a current context, how one fails and the other succeeds.

Creative thinking will lead to innovation. Building an appetite for risk absorption and being decisive in the #VUCA world. Also to consider having an environment of experimentation and exploration, to fail fast or fail forward. Quickly learning from mistakes and considering #pivoting when things don't go as per plan. Leadership coaching executed well will solve many of these issues.