Hey Coach! My Kind of Commitment
|Philippe Sauve in Agile Tuesday, June 21, 2016|
Before we start this new article of "Hey Coach!", let me discuss a few points from my first article “How do I Get People to Do What I Want”. In writing that first article, I knew that it was a bit controversial to discuss the topic, but I did anyway.
As benign or controversial as it may seem, I was in no way saying that a coach should tell people what to do, but was acknowledging the fact that this topic keeps coming back again and again. Lastly, when referring to a "coach's agenda", personally I am talking about the best interest of the people that a coach engages with and their success which they can achieve.
Now, on with the show and in this article, we will be discussing the love affair that Organizations have with the word "Commitment". Yes folks, this is not your Grandma's commitment, but something else entirely.
Let us start by defining the meaning of "Commitment":
1. The state or quality of being dedicated to a cause, activity, etc.
2. An engagement or obligation that restricts freedom of action.
Interesting how, like most English words, the meaning can be on the one hand positive and the other negative. When working with Teams, this word is constantly used in regards to their productivity. They are bombarded from many different sources that talk of "commitment", you will hear "commit to the Sprint!", "can you commit to that?", "commit to the Release" and so on. The likely source of such communication can often be found in their manager and the scenario goes a little like, "Team, we need this in 2 months, we need your commitment to deliver it?".
I am pretty sure that you have heard a version or two of the above scenario. In this particular case, we find ourselves within the boundaries of the second definition which "restricts". [Side Note: I am well aware that the managers’ intention is good, this is not a good vs. evil story, rather an attempt at improving collaboration and communication.]
Organizations and their representatives, the managers, are constantly thrust into different dilemmas and work to keep the "boat afloat". I believe that we are all in agreement that this is necessary in order to provide for ourselves and our loved ones. These pressures are often at fault when it comes time to communicate to Teams on how to achieve the GOAL, "make money".
As a coach, one of many challenges is that our potential mandate does not include management and the like. If you're like me, it is more often than not about working with a Team or Teams to create a setting where they can achieve better results.
When addressing commitment with a Team, I talk about it as it is defined in #1 (see definition above) by working with the group or individuals so that they may become a Team or of if that is already the case then simply have them work on aspects of dedicating their Team's capabilities to it's cause, aka producing functional software that delivers great value.
One of my favorite expressions relates to giving someone or a group "a lot of rope", I might be caught also using "showing the system to itself". Why might you ask, do I use these expressions?
Because once people have "hanged themselves" (with the said rope), this is where you can truly start to work. A coach, unfortunately, is often a last resort and comes in when an organization feels there is a problem, rather than proactively work with a coach to continuously explore "possibilities". Having said that, it is one thing to see a problem from the outside, the key is having the "whole" see it from the inside and especially, see it for what it truly is.
Here is an example case:
The Team is asked to deliver a functional feature by a given deadline which coincides with a major public event. The news comes as a total surprise, yet the Team responds to the call because they are well aware of the great opportunity it represents to have the product showcased during such an event. This leads to the Team being asked to "commit" to deliver on time for the event. Let us fast forward, the Team has delivered and all is right, or is it?
The underlying issue that I want to illustrate with this case is that while the Team "committed" to deliver the feature, they on the other hand, working with "restrictions", forgot to adhere to some of their standards and slowly slid into "debt". Being constantly asked to "commit", they develop a habit of jumping from one thing to the next and then are left looking at the pieces once the dust settles.
The importance is in recognizing this and together, we worked on improving their accountability toward their releases and explored ways for them to better communicate to stakeholders to mitigate such impacts.
Once that is achieved [WARNING! This is not easy and can fail multiple times. :P], then working with the Team's self realization we get them to build a solid foundation of actions that will (eventually) become new standards within their structure. Their new found dedication can then lead to new and improved perceptions (manager, Org, etc.) which will dampen the effects of the earlier scenario of asking for "commitment" in the form of a "restriction".
In conclusion, commitment is a symptom and rarely is it the root cause of the issues plaguing an organization or Team(s). Working to have them realize this and finding purpose will inadvertently change the course of the how the word is interpreted and communicated.
Thank you and hope you have enjoyed it as much as I liked to write it.
If you would like to learn more about Scrum, find Scrum training or take a Professional Scrum certification assessment you can visit Scrum.org.
If you liked this edition of “Hey, Coach!” feel free to reach out to me @scrumandme or scrumandme.wordpress.com for other articles.
Read more: https://scrumandme.wordpress.com/about/
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.