top of page

Sharmon Noel

I coach awesome development teams in ways to Trust the Process and create speed to value with their products. As a previous developer, leader, and now consultant I provide value from my experience of being in the shoes of your team members, understanding their need for business agility. I utilize my expertise to create better teams, organizations, and achieve better business results. 

  • Writer's pictureSharmon Noel

Poor Metrics = "Cots and Coffee"

Some coaches love to measure their teams successes with beautiful, fancy, big and visible graphs and charts. Sometimes we pull out our nice and fancy charts to say "Hey we completed Product A under time and budget" Kudos for everyone, right? However, if those metrics were on the not so favorable side of the spectrum we would probably be having a different conversation.

As a coach it is vital that we remember the true reason for capturing metrics. Metrics should be used to promote or revisit our values, not to measure how good or bad that we are. If we are using the latter as our reasoning for using metrics this would create confusion amongst our environment, especially some leaders that may not be as versed of the daily insights of our teams progress or struggles.

Some leaders sometimes fall into what I call "The Realm of Comparison". When this happens it is saying "Hey, if Team A can do it, then so can you". Or here is a better example: Let's say you are part of team that is comprised of a department that has multiple teams working on different projects. Team A is high performing, they are always firing on all cylinders, and they are crushing expectations for product delivery, release timelines, etc.

However, Team B is not as productive as Team A. They are working a product that is new to the organization, some great ground breaking stuff, however they are not achieving the great successes that the other teams are producing with the expected speed to value. So what do you do for this team to make them create their product at a faster pace?


It's really that simple. The reason is this: Many developers love doing great work. They have a process that they follow that allows them to push out good, clean, functioning code. With great requirements and a clear vision would make this process a lot easier, but stating to someone I want you to work faster? Nope, nada, nein, not going to happen. To be honest, if it were to happen then many times it can only hurt the situation with more defects, emotional distress, and shortcuts that may ultimately catch up with the team later.

Do not be mistaken, there are factors that you can change. You can provide a more in-depth analysis of your Minimum Viable Product (MVP), you can add clearer priorities, you can maybe change up the dynamic of the team by adding a resource, coach, or product manager that will help with the vision and thus help get the ball rolling with more momentum. However, can you realistically think that a team will work so hard, or type so fast that you are seeing smoke come from your keyboard?

Some of the expectations that come from leaders are somewhat a misunderstanding of the productivity of the team in alignment of the work that we are planning. For example, years ago I coached a team where an expectation came from a leader that based his decision from the metrics I provided. His misunderstanding of the MVP, the number of features, and the timeline brought him to the conclusion that the team was not working fast enough and that he would have to invest in some "Cots and Coffee" until we get it done.

Yes you got it, the team was just threatened to work faster or we will be sleeping on cots at work and drinking coffee to stay at work longer because of poor metrics.

Teachable Moment: I was using poor metrics as a guide to understand the level of execution of our team values and agile behaviors. The teachable part that I missed was that I also should have been doing this type of coaching with the organization leaders as well. Many times during organizational transformations we are great at coaching our teams the values of being agile but we do not do the same for our leaders. When an organization is executing a true transformation under the Scaled Agile Framework (SAFe) methodology then this action would be very difficult to miss. Not sure why SAFe was not utilized however, the fact remains that the values and expectations were not in alignment of our teams thus causing the disconnect.

As coaches, we need to spend a great amount of time with our leaders as much as we do with our teams. They too, need to be in alignment with the agile mindset and not create their own expectations. The constant contact and coaching instead of the routine use of metrics to describe what your team is doing will provide more context into the progress of your team and the execution of the goal.

There was a great talk at a conference that I attended, where a senior leader stated that his teams were Agile-ish when he first joined them. During the talk he discussed how Product Managers were disconnected from the team, leadership did not have a great understanding of what the metrics were telling them, and the ceremonies were being done for the sake of being "Agile". Many organizations believe that the opening up communication and executing agile ceremonies make them agile. Forgetting that the result for doing all these things were to create value that you were not once getting before. As a coach, we should always move towards being value driven and not just Agile-ish.

One of my favorite teams that I coached for another employer would always record some of the things I would say and call them "Sharmon-isms". One of the "Sharmon-isms" that come to mind is "You gotta let it soak in." The same must be done with coaching. No one is going to understand the method to your madness unless you are coaching them from the beginning on your mindset. In regards to my teachable moment, it allowed me to be a better coach for both teams and leaders and constantly invoking principles and methods until "it soaked in". Additionally, it taught me how to be uncomfortable and not allow fancy graphs and charts do the talking for me but to always add value by working with my leaders one on one.

I am pretty sure that there are many "Cots and Coffee" types of leaders out there. However, the question that we as coaches should ask ourselves is: "What am I not doing as a coach that would allow this state of thinking within my team?" If an organization is truly committed to having a problem solved and being agile, then as a coach we will need to coach all levels of the organization and not just the team. Guide the team to understanding the methodology, mindset and behaviors. Guide the leaders to understanding the same and also creating the expectation of your team producing speed to value and not just speed. We can easily have teams that are pushing out code, completing User Stories, and ultimately producing good metrics. But, would it be valuable?

Stay focused, stay firm, and remember that the agile mindset goes beyond just working on the team that you execute your ceremonies with on the daily. The real work begins when you are working with your team and your leaders to push the boulder of momentum uphill. The boulder will eventually tip the peak and start producing the speed that we ultimately are looking for over time.

51 views0 comments

Recent Posts

See All


bottom of page