Are your Agile workshops for problem solving not bringing the desired value?

It is impossible to live without failing at something, unless you live so cautiously that you might as well not have lived at all, in which case, you fail by default. — J. K. Rowling

With this thought after failing multiple times I realized the “guru mantra” how coach can enable the team to fail. In last one year, I got opportunity to be part of multiple "Agile Workshops” with few more coaches. 

Problem Solving Agile Workshops can lead to out of box solution of real problem statements, trigger the mindset change & enable participants to get acquainted with Agile way of working but it can do long term damage than good if not facilitated well.

Reason being, it can not only lead to no solution at end of workshop but also to generation of myths which can get propagated to larger teams since participants will carry their learning’s to their respective workplaces. With all my failures, I also got some wisdom what should be avoided, so here I wanted to share few coaching anti-patterns observed during these agile workshops.

1) Being a coach I need to keep every team member happy Though taking care of team happiness is one of our major responsibilities & has to make sure team stays focused & motivated but if team is going wrong it’s our responsibility to show them the right path.

Challenging team status quo and reveal to them what you have seen from your different viewpoint is also one of our major responsibility. If all team members not participating in scrum events, lot of dysfunctions/toxins are observed in scrum events, we should be honest and transparent in presenting both the opportunities and the threats since our responsibility is also about helping the team get quality interactions enabling collaboration.

If coach is not doing that, he may be suffering from “Too Soft” syndrome. Too soft syndrome is about Unwillingness to Tell the Team What to do even when team directly asks for help & asking question is not helping. It is also about not having the courage to Step In and Say “Stop It”.

2) Fail Fast First Team tends to experiment freely when trying to reach the desired outcomes, but they are also quick to abandon the development lines that do not bring the desired results.That is fail fast approach. Failure is definitely an opportunity for learning and improvement, Also if failing is inevitable, then it is better to fail early than late.

But one thing we are missing here is cost of failure & did we even try to enable the team to see the writing on the wall? In these agile workshops where we generally have 3-4 sprints if we let the team fail for one sprint, cost can be very high. Secondly we cannot end up sitting ducks during sprint planning meetings or other scrum events, if team is going wrong, making them realize through effective questions is also one of the coach major responsibility.

Meta view is one thing which generally helps in this case, Meta-view presents the big picture and opens up room for perspective. It presents a panoramic view of the journey.  Coach can ask, “What do you see from up here? What’s the truth you can see from this point that you couldn’t see down there?” 

3) Facilitation is only about time boxing Well everyone is aware of the importance of keeping watch on time & restricting the meetings/discussions if going off the focus. I did not have an iota of doubt over the fact that time-boxing creates a sense of urgency, improves focus & even helps team in rejuvenating. But coach should also do some root causal analysis why team meetings are going off track. It can also mean they are not facilitating the meetings effectively.

So approach should be to enable the team by effective facilitation to come to common understanding of the problem statement/story & if team don’t have the minimum required inputs to take just-in-time decision-making, sprint is not going to be successful.

So use your facilitation skills to not only time box but also stop team wandering tangentially through story after story by starting with bottom-lining which is the skill of getting to the point and asking the team to get to the point.

4) Agile is only about set of practices Sometimes we try to implement an agile operating model by only following the book and without understanding the transformation complexity, but no wonder end up failing since understanding agile is not something that can be achieved by simply reading a book or attending a session.

Reading book is good but it cannot replace the practical experience that is essential to enable agile mindset and successfully transforming the team to become agile. Remember Agile is not about set of practices, it is all about values & principles. Talking about agile practices but not the fundamentals underlying the practices will not work.

Question arises “How do we learn”? Practice, Practice & more Practice Also courage to say “I don’t know”, and ask another coach for help can be really helpful here. Why? Change begins with self and teams will emulate what we are 'doing' rather than what we are preaching.

5) Coach only needs to be patient & have good listening skills Listening skill is must for a coach but the second important aspect is what we do with our listening. 

If we are not doing anything, it can lead to stonewalling where one team member starts dominating others by repeating one’s own idea over and over again and not listening to other members. No need to say it needs to be corrected.(Coaching is not about your experience but rather the ability to ask powerful questions.)

Facilitating relationships and collaboration both within the team and the teams environment is must to enable team to be successful. Helping the team make decisions and reach consensus is another key job of coach. Coaching is also about helping the team get quality interactions & making team realize about the dysfunctions.

6) Team is aware about few agile frameworks , they know everything Sometimes, have seen in some sessions where participants carry  some myths around agile since they never worked in agile. 

That times I feel reinforcing previously learned practices or information would be more impactful than letting a team struggle through a situation. Transferring some agile knowledge and experience will not do any harm. 

There is a tendency in our community to lean heavily to the self-discovery and self-direction side but I feel there should balance of both prescription & & self.

?