Its high time that we stop using Velocity

Velocity in an Agile environment is the most misused-used and misinterpreted word/metric.  The key issue is, teams and stakeholders interpret Velocity as a productivity measurement rather than capacity of the team.

I don’t blame the team or the managers. But the “word” itself. If we look at the synonyms for Velocity(see the screenshot below), all of them point to quickness, momentum, acceleration, which naturally encourages people to connect this with “productivity”.  

 

Google for Acceleration or Velocity and one would find following images… These images push people to think more of a competition, race and winning rather than a team work or a capacity.

I think we should stop using the word velocity and start using the word that creates some mental image to show the “team’s capacity”.

Do you think this is a fair call ?

Coaching intervention during a team conflict

Every team goes through some stages of conflict before they stabilize. Leaders need to be conscious of intervening during such conflicts.  The knee-jerk reaction of a typical leader observing a conflict is to jump immediately to “fix” the problem. It is highly recommended that they avoid it and take a step back to monitor the situation first.

The leaders need to find the appropriate time and context to intervene for coaching. Here are some examples and contexts.

1. Self-organizing teams are in the process of learning. They are trying to check the boundaries and positioning themselves in the team. Conflicts in such situations are imminent. The leader or a coach assigned to the team should avoid intervening in such contexts. 

These teams are like butterflies emerging from pupa. Yes, there is a bit of process, pain and time involved to emerge out of pupa, and one needs a bit of patience. Trying to expedite the process could actually kill the butterfly. 

2. Research suggests that creative and innovative work actually needs healthy debate and conflict. Intervention is needed to help the in understanding the differences. There are many times a person or a small group within a large group might be thinking tangentially. This could lead to conflicts and it does not mean that there is anything wrong here. In fact, such conflicts avoid groupthink.

For example, an engineer embedded in a marketing team obviously think differently. The engineer could be considered as a trouble maker as he/she is different than the rest of the marketing team. In contexts like this, the leadership or coach intervention is essential to assist the group.

As a leader one needs to drill down a little bit, get rid of the noise and study the type of work before intervening. The diversity of the team needs to be taken into account while dealing with a creative team as well.

3. If the team is working on a routine and repetitive kind of work, coaching intervention trying to facilitate discussions could backfire. Instead, a root-cause analysis with a management intervention is critical for smooth functioning.  

To conclude, if you see or hear a conflict, don’t jump to fix the problem. Try to understand the context first. Many a times, the conflict is actually good for the team, and the organization in the long run.

Overcoming the Obstacles to Achieving Agility and Delivering Business Value

I am  excited to say latest version of  Cutter IT Journal  has published my article “Overcoming the obstacles to achieving agility and delivering business value” .  I  authored this article exclusively for Cutter. 

In this article, I have articulated various issues that hinders agility in the organization. I am proposing the Systems thinking approach to solving the organizational and agile challenges.In order to achieve true agility, it is not sufficient to blindly follow the agile practices but to think beyond Agile. One should look at fixing the organization structure, focus on uplifting the relationship between business and IT and last but not least, fix the funding model.

I have shared some practical tips and solutions to achieve true agility beyond practicing Agile. The article is exclusively available for Cutter IT members and could be downloaded from here.

Here is the abstract of the article:

This months issue covers the following topics, including mine (highlighted)

IN THIS ISSUE

Vince Ryan and David Putman open the issue by exploring several common difficulties experienced by groups moving to an Agile approach. These range from cargo cult behavior -- blind adherence to the what of Agile without knowing the why -- to the technical abilities of people to work in an Agile environment. The authors delve into key issues such as empowering people to actually make the changes required to support Agile, as well as ensuring that they have the proper skills to be able to thrive. The authors explore such areas as training, the recruitment of new people, and offshoring/outsourcing with respect to the changes that may be needed for an organization to truly reap the promised rewards of an Agile approach.

Our second article, by Cutter Senior Consultant Lynn Winterboer, examines one of the less traveled paths of Agile -- the implementation of Agile approaches in the DW/BI space. Winterboer addresses the challenges of breaking this type of work down into small slices, when it has traditionally been an "all or nothing" deal. She describes what is perceived as technical inefficiency in the small slice approach and how that is balanced by the business efficiency. Winterboer shows not only the advantages gained by earlier delivery of value, but also the effort required and "instability" incurred during the transition. In the end, both organizations in her case studies found ways to deliver smaller aspects of the total solution, providing more value sooner to their stakeholders.

In "Overcoming the Obstacles to Achieving Agility and Delivering Business Value" Venkatesh Krishnamurthy dispels the myth that "Agile is a tool" that can be discarded when you're "done,"much as a hammer is put away once a construction project is completed. He asserts, correctly in my opinion, that simply following Agile practices does not make an organization Agile. The use of systems thinking to view the transition in the context of the whole organization shows how the organizational structure, funding models, and business/IT relationship must change in order to support true business agility.

Finally, Alan Shalloway speaks of how Agile and Lean have "lost their shine" as the result of misapplication. My experience certainly supports this assertion. Shalloway proposes the use of a Lean-Agile hybrid approach that leverages both the organization-wide strengths of Lean and the team-level strengths of Agile. Like Krishnamurthy, he recommends the use of systems thinking in order to take a more holistic view of the context in which the Lean-Agile transition is taking place. Shalloway describes this ecosystem and the unexpected effects that can result when you don't consider groups outside of the development teams.

Read more about this issue here

Do you have an Agile Testing mindset ?

Here is my recent guest post for Zephyr…

Performing Testing in Agile projects is not termed as Agile testing. Agile testing involves whole different mindset.  Then, how do you know your team has Agile testing mindset?  As a coach, I start this by asking testers the following few questions:

- Do have to wait until the development is done to start testing?

- Do testers feel there is a lack of time at the end of Sprint?

- Are testers blamed when defects are identified?

If testers answer “Yes” to some or all the questions above, then the team still has “Waterfall” mindset in guise of Agile. 

Another litmus test to try is to check the team’s wall which is popularly called “Kanban” wall. If you see a wall like the one below, where the “Test” ing is a separate column, then this is a smell.

Read the rest of the article on Zephyr

Need for dedicated testers in Agile environment

Here is a short article for Zephyr’s guest blog

Scrum recommends 3 roles, the Product Owner, Scrum Master and the team.  There is no dedicated role as a tester (or QA) if you are following pure Scrum.

Agile also recommends that the team members are expected to be cross functional with T-shaped skills popularly known as “Generalized Specialists”.

However, the challenge I have seen in many projects is how “generalized” one could be while performing the role. Most of the projects are, so budget and time constrained that everyone is part of the rat race. They just want to get things done, and there is hardly any time for the team members to learn from each other and building generalized skills.

Building cross-functional and T-shaped skills is not easy. It needs a dedicated attention, time, effort and $ is involved from the organization to enable this. One cannot ask a developer to sit with a tester for a few days and learn testing. Personally I believe that testers mindset is something that comes with passion. In addition, mindsets of developers and testers are different.

There is one more reason behind having dedicated testers, and this is due to “IKEA effect”. The Harvard article concludes that,

“When people use their labor to construct a particular product, they value it more than if they didn't put any effort into its creation, even if it is done poorly.”

In the context of this article, when developers create the code, they value their creation more than the testers. The developer doesn’t like someone finding fault with their creation. This is one of the reasons why one gets to hear all sorts of excuses from the developers.

Read rest of the article here

Melbourne: Upcoming Agile trainings and conferences

The Agile community is getting ready for a new and exciting year ahead.  Several interesting and fascinating Agile trainings, conferences and workshops have been scheduled.

Here is the first list:

February

1 - Advanced Agile Master Class with Alistair Cockburn. 17-19 February

2 - Certified LeSS (Large Scale Scrum) Practitioner with Bas Vodde. 24-26 February.

March

3 - 1st Conf, 16 March 2015. For people starting out with agile. Alistair Cockburn keynote.

4 - Workshops for 1st Conf, including Introduction to Kanban, and Management 3.0 … with more coming.

July

5 - LAST Conference 2015. Friday 24 July. Submissions open now.

NB - The code POBA will apply a discount to all of those events :)

Scrum Australia 2014 : Build great products with Scrum + Design Thinking + Lean Startup

I had the privilege of speaking at Scrum Australia 2014 conference couple of months ago. It was a fascinating experience to stand in front of such an energetic and knowledgeable audience and share ideas.  Scrum Australia team had put a lot of effort and energy in getting good speakers not only from Oceania but from abroad as well.  I enjoyed every bit of this conference for 2 days.

The title of my topic was “Building products that customers love by strengthening Scrum with Design Thinking and Lean Startup methods” .

I believe that we need to combine various methods, and use their strengths to build the products. Scrum has its own strengths, and similarly Design Thinking and Lean Startup as well.  However, none of these methods on their own can be used on their own to build great products.

First of all one needs to ensure that any new product idea is viable, desirable and technologically feasible.

It is very important that one has a good understanding of the problem one needs to solve.  Most of the products fail mostly because of lack of understanding of the problems.

Design Thinking comes handy in articulating the problems, and Lean startup could be applied with product testing, pivoting.

I would like to thank  Lynne Cazaly for beautifully depicting my session with the following “Visual Note”

I had put together this idea of bringing the 3 methods together (Scrum + Design Thinking + Lean Startup) long ago. This idea was published by Cutter as an Agile advisor.  Cutter was also gracious enough to make this article public. The entire article is available here if any one is interested in getting  into a detail a bit.

I have been attending Scrum Australia conference without fail since the last couple of years, and return with a load of new knowledge and experience. I am already looking forward for the 2015 conference :-)

Correlation does not imply causation

After every Agile conference, agilists return back to work with tons of new ideas.  They get excited about these new ideas and would be looking forward to roll them out sooner than later. However, based on my past experiences, I have realized that many ideas could do more harm than being helpful.  This is not because ideas we hear at conferences aren’t good, however, what we assume as the “idea” behind success may not be the “one” causing the success.

Popular ideas being borrowed in the Agile community include the Spotify’s  tribes/guilds, Google’s 20% innovation time and many more. In this advisor, I am challenging the readers to think before they act and understand the hidden secret’s of success.

Here is link to the complete article.

This advisor has been written to enable the Agile conferences attendees to look deeper about the “causation” aspect rather than the “correlation” .

How to make wall-related decisions in Distributed Agile projects

I authored the following article for Cutter which got published today. So, it is hot out of the press.

The subject that every distributed Agile team is questioning is the topic of setting up visual walls. Conflicts arise when purists argue in support of setting up visual boards across all locations, while the distributed teams consider it an inconvenience.

Many companies don't realize the importance of making the right decisions related to visual walls. Typically, wall setup is left to the ScrumMaster. These companies don't realize that this "single-handed" decision could result in loss of productivity, increased stress levels, and thousands of dollars in loss due to waste.

====  I am recommending a principle based approach for deciding if the information needs to be displayed on Physical wall or Digital wall. ===============

Wrong wall decisions or forcing wall decisions on a team could end up with stale walls and thousands of hours could be wasted in maintaining these walls. Be sure your organization considers the core principles during its exploration of walls.

Since this article is available only for Cutter Members, kindly continue reading rest of article on Cutter

If you are start up, think beyond one user

As I am coaching and mentoring a few start ups in Melbourne and elsewhere, I have noticed common pattern of issues across the board.

• All start up founders are really enthusiastic and dream of becoming rich –> Nothing wrong with it
• All start up founders have a strong idea in mind ---> Nothing wrong with it
• Most start up founders believe that their idea would take over the world, even though they have never tested beyond one user   ---> Something wrong with it

Recently read a story about startup failure “Patient Communicator”.   The founder built fantastic features applying iterative development method, however, it was never tested beyond his father’s medical center.

As the founder shares his experience, PC began as a product for my father’s medical practice.  Plain and simple, I never assessed the market need for a patient portal.  It’s extraordinarily difficult to take a product that was built perfectly for a particular user and commercialize that into a broader market.

If you are in start up journey, think beyond one particular user !  

Large Scale Scrum (LeSS)

Last week, I had the opportunity to speak about Large Scale Scrum (LeSS) at Agile PM meet up group  in Melbourne.  It was really an honor to speak with such an incredibly experienced, knowledgeable audience. At the end of the session, we had very engaging Q&A.

As part of the session, I shared some of the challenges of  scaling Agile and possible solutions as well. One of the solution being, applying the Large Scale Scrum(LeSS). 

Based on my experience of working on several large scale Agile projects, I have come to realize the following 4 types of challenges common across large enterprises.  They are People, Process, Tools/Technology and Org Structure/Culture. 

I have summarized the challenges into this diagram

Even though these challenges are common in small Agile projects but gets amplified while scaling Agile.

The popular  Scaling Frameworks are as follows:   Spotify,  XScale, SAFe, DAD (Disciplined Agile Delivery).

In addition to the above,  Large Scale Scrum(LeSS) by Craig Larman is popular as well.  I have personally applied this while working with Craig Larman during 2006 at Valtech India. LeSS and LeSS Huge are two variants for large scale projects.  LeSS huge can be depicted as shown in the diagram below:

LeSS is based on some of the proven principles around Queuing Theory,  Systems Thinking  and Empirical Process Control  as shown below.

If you want to learn more about  applying Large Scale Scrum on your projects, do drop me an email and happy to share the ideas.

What is Loyalty ?

No one plans to fall sick isn't it? Similarly, when I caught some flu couple of years ago, we were eager to see a doctor. Being new to our suburb, googled around to find a nearby medical center. Took an appointment with "any available GP," visited and got better.

After some time, it was my wife's turn. When she wasn't keeping well, she too called the medical center, took an appointment with "any available GP" and felt better.

Apparently she visited a different GP than mine. She recommended me to see him next. Over the course of time, we noted his name and started getting appointment specifically with him when needed. Suddenly one day we heard that he moved out of this medical center, and the receptionist wasn't eager to share his new coordinates.
We felt a bit sad as he knew us well, and we had a built a good rapport over the years and now we don’t know his whereabouts.

Later due to circumstances, we moved to a different suburb and once again started the search for "any available GP". We weren't so happy with the GPs we had seen compared to our earlier one. We used to remember our earlier GP once in a while.

One day we casually thought of searching our earlier GPs name on google, and some names came up. We called a few and one of them actually turned out to be our earlier GP. Everyone was elated, and we went and met him as well. He was not only surprised to see us but was beaming with a big smile.

I would call our selves as the loyal customers for this GP as we did everything we could do get the services only from him even when several options were available.

Loyalty is something when you chose a specific service inspite of having many options in available to you. Of course, a more formal definition from Wikipedia would be “Loyalty is faithfulness or a devotion to a person, country, group, or cause.”

On the other hand, repeat business is something where customers use existing service as they don't have an alternate option.

It is shameful to see that many companies measure "repeat business" rather than "loyalty." Loyalty is much more powerful than getting a repeat customer. Loyalty is something that will enable the company to grow during downturns and fierce competition. Repeat customer will leave you and go when they find better options.

Nowadays companies rollout the so-called "loyalty program." Big shopping malls and airlines have this loyalty program. I feel that this is a bit misnomer. People tend to go back to these companies not because they like the service, but because they get some discounts or redeemable reward points. I don't call such programs as a "loyalty programs", but as "carrot programs."

Couple of things I liked about our family GP has been his relationship building skills, his frankness, his specialty, customer service and respect for us.

Here is another personal example, while I moved to a new suburb, I was scouting for an electricity provider. I was calling each provider and gathering various details. As one could see, each one was tried their level best to sell a service by sharing their discount program, except one of them who explained their weaknesses as well. She not only suggested alternate but better options. I genuinely got connected with this company. Lesson learnt, being truthful and genuine breeds loyalty.

To conclude, It is very important for a business to evaluate if the returning customer is a loyal one or a repeat.

Even though we have tools like NPS, it won't clearly tell you the difference between loyalty and repeat. It partially helps to understand the situation though.

Always try to build a loyal customer base and work towards converting the repeat customers to loyal ones.

I have also posted this article on LinkedIn

Increase speed by incentives and sacrifice quality

Recently  I read an article in the news paper about improving the speed of passport delivery to citizens.  This is the news published in Times of India. It seems that passports are getting delayed as the police verification is taking a lot of time. In order to improve the speed, the passport office is planning to incentivize the police.  That is, if  the police completes their verification within 21 days, then would get more money else they are penalized by reducing the incentive.  I felt that this is one of the most dumbest idea ever implemented !!

Here is the quote from the news paper:

However, he said the delivery of passports has been expedited by incentivizing police. "We have reduced the time taken for delivery once the application is sent for processing. We are insisting that the police department send in police verification reports in 21 days. For each report sent before 21 days, cops are incentivized Rs 150 per report. If sent later, they get Rs 25 only. This will reduce the time taken to get the passport delivered. In some cases, the passport is delivered less than a week if verification report is sent fast,"

There are couple of issues with the above idea:

1. I don’t think any root cause analysis has been done to identify the delay in verification. There could be various reasons for the delay.

      For example, this passport verification may not be the top of police’s backlog list.  It is also possible that police force don’t have sufficient people to support this activity.

A root cause analysis could have helped to unearth the real cause of the delay and proper action could have been taken.

2. Going forward, I could see that the all police verification will complete within 21 days due to incentives. Question is, at the cost of  WHAT ?    I could see that the quality of verification will drop heavily as the possible root causes are never addressed. 

Being in the software industry, we keep hearing that external motivation causes more harm than the anything else.  The above story correlates to what we commonly see in the organizations. Employees are incentivized for ensuring on time delivery. But the companies pays for the cost of quality at a later stage, which no one really bothers or accounts for. 

Your understanding of Kaizen is wrong

Kaizen is popularly associated with continuous learning or continuous improvement.  However, where people get wrong is who should continuously improve ? 

Most Agilists and Leanists use Kaizen in the context of team improvement. That is, an agile team should continuously improve, and thus excluding the managers/leaders, rest of the company. 

This is exactly where the understanding goes wrong.   The true Kaizen involves continuous improvement across the organization starting from the CxOs, and involving HR department, Finance, PMOs, Sales and marketing. It is also about improving everyday and everywhere. 

So to conclude, you are not really following Kaizen if the expectation for improvement is only for the team(shopfloor) and rest are excluded !!!

Watch this video to hear directly from the master Masaaki Imai, founder of Kaizen Institute

https://www.youtube.com/watch?v=jRdTFis4-3Q

Secret recipe for building self organizing teams

I authored this short post for as part of Agile chronicles.

Some time back I noticed something odd with an agile team. Team temperature used to be 10 out of 10, and each team member expressed their happiness working on this project.  I was curious to find the secret behind an “always happy team.” A bit of interaction with the team and the ScrumMaster revealed some disturbing secrets.  Here are the key ones:

1. The team is self-organizing, and individuals can pick the story of their choice and deliver at their discretion!!
2. Team has neither time pressure nor delivery timelines

I thought to myself that this is not a self-organizing team, but a directionless team.

As Esther Derby points out, there are several myths and misconceptions about Self-Organizing teams.  I did cover a bit about these myths during my talk at Lean Agile Systems Thinking conference(LAST) in Melbourne, which is available on Youtube (toward the end at 1:03 minutes).

I understand it is not easy to build a self-organizing team, but there are principles enabling leaders in building such agile teams.

One of the best analogies that I have heard so far about self-organizing teams is from Joseph Pelrine.  As Joseph puts it, building self-organizing teams is like preparing soup.  I thought it would be easier for readers to understand the self-organizing concept if I map the soup preparation steps to the self-organizing steps. Yes, soup preparation involves many more steps, but the key ones below would give the clues to readers for further analysis.

Read rest of the article on  : Agile Chronicles

Photo courtesy : https://flic.kr/p/ayhjag

Measuring Business value in Agile projects

Because the first principle of the Agile Manifesto talks about delivering valuable software to the customer, many agile practitioners are constantly thoughtful of the value in each step of the software-development lifecycle.

At the thirty-thousand-foot level, value creation starts with gathering requirements and continues with backlog creation, backlog grooming, writing user stories, and development, finally ending with integration, deployment, and support. Even with knowledge of all these moving parts, it is common to see organizations only measuring value during development and ignoring the rest of the steps.

What’s the fix? During backlog creation, user stories need to be compared and contrasted in order to promote maximum value delivery. The product owner might need to use different techniques, such as T-shirt sizing, in order to better prioritize the project’s stories.

An alternate approach to measuring the business value of user stories is to use a three-dimensional metric that incorporates complexity, business value, and the ROI. Creating value can often require a change in perspective from the normal project’s tasks and functions. Thinking outside the box, identifying business value before writing the user stories is much better than writing and then trying to evaluate.

Read  the complete article about measuring business value on TechWell

Picture courtesy https://flic.kr/p/8E7Dr5

LAST (Lean Agile Systems Thinking) 2014 Conference

Last week I had the pleasure of speaking  at the LAST 2014 (Lean Agile Systems Thinking) conference. This is my second consecutive year of having opportunity to speak at this popular Melbournian event.I  have seen this event growing year after year. First year, we had 150 attendees, the second year 350 and third year is even more successful with 450 people. The event is highly affordable and run by the Melbourne community.  Some call this conference as  “Meet up on Steroids”. 

The two passionate people who are successfully managing this event are Craig Brown  and Ed Wong.  Organizing such a large scale event managing speakers, schedule, events and sponsors is not a simple thing. The event was such a smooth one, didn’t realize that the day had already passed.

This is a classic example of power of passion and network in the community.  You don’t need many people to make a positive difference to the society, you just need one or two passionate givers.

The session was organized by  TABAR 

I spoke about  10 Irrefutable laws of Agile Coaching.  The presentation slides are available on Slideshare as well. Feel free to download/share.  

My intent for sharing these ideas was to encourage Agile coaches to think beyond  Scrum, Lean, XP, etc.   Agile coaching involves a broader systems knowledge to succeed.

More details about my session:  Agile coaching is one of sought after skills in the IT industry and many experienced coaches are doing extremely well. However some change agents are struggling to make an impact, not because, they don't know Agile but because, they don't know some ground rules dealing with the coaching teams and leaders.

Whether you are a novice or an experienced coach, there are irrefutable laws governing Agile coaches. Based on my own personal experiences coaching teams/leaders since the last several years, I have come to realize the 10 secrets. Irrespective of where you are in the journey as an Agile coach, practicing these 10 laws will help you to become a successful Agile coach. These handy rules can help you anywhere in Agile coaching journey.

Upcoming Agile Project Management MasterClass at Swinburne – Aug 21st and 22nd

This two day Masterclass commences with an introduction to the foundation and history of the Agile movement. It then looks at common practices and frameworks used by teams including Scrum, Kanban, Lean Start-up and XP.

Day two drills into project management activities related to planning, monitoring and controlling projects highlighting the role of collaboration, developing appropriate feedback and quality systems, including elevating the focus from schedule and budget targets to delivering customer value.

This course introduces

• The background and history of Agile management
• Leading frameworks used in industry and their features and benefits
• Principles and practices to initiate and plan a project
• How Agile practices and techniques can be used to manage a project, with particular focus on dealing with a changing project scope

Check out here for more details.

Enterprise Agile Transformation through Centralized Agile Group – Benefits and Challenges

Authored the following article for Cutter Consortium as part of their Agile advisory series.  In this article, some analysis has been done detailing pros/cons of setting up centralized Agile excellence or group to promote Agile as part of Agile transformation in the enterprise.

Here is just a snippet and the complete article can be accessible by  Cutter members.

Read rest of the article on Cutter

Changing the mindset of Agile teams

Recently I penned a guest post for Version One  about the why people behave in the way they do and how to change them ?

Agile is not about practicing Scrum, XP or Kanban. It is a mindset that one needs to cultivate. It is not about doing a daily standup or retrospective but knowing the values/principles behind it. Most of the agile teams are interested in practices and very few are interested to learn the values/principles.

People resist adopting new values and principles as it expects a change in mindset of teams. Changing the mindset of agile teams is always a bit difficult. I have started believing that it is easier to change the people than their mind. The good news is, there are some tools and tips available to help in this journey of changing mindset.

Let me explain one of the tools with an example. A couple of weeks ago, I came across these two dustbins outside of our apartment complex.

As one could see, one of them a simple open cardboard box and the other one is a proper dustbin. Not sure why they had kept these two together. In the next few days, I noticed that people were throwing wastes mostly into the open box. However, the other one needed additional effort to open the lid to throw the wastes, which was left unused.

What I learned from this experience is, if you want people to follow ideas, make it easier for them to learn and use. Or else they will never change.

Another case study is from one of my agile projects. The teams were using an agile project management tool which was not so user-friendly. Teams diligently added all the user stories and tracked them on a regular basis. However, when the need came to extract the key metrics like Velocity and Cycle times, the team had to write queries manually and tweak it regularly. They always resisted this manual, cumbersome process, which was time consuming as well. The teams always used to fall behind sharing these critical agile metrics with the stakeholders.

I suggested an alternate approach, which involved adding a dot on the user story cards after their daily standup until it is complete. It looked something like the one shown in the picture below for measuring the cycle times.  They used a simple sketch pen to put the dots on the cards.  This was so much easier, and the team loved it.  After this little change, they never resisted sharing the metrics.

Conclusion: If you want to change the behavior or mindset of agile teams, create an environment that is easier to navigate and use. The non-intuitive tools and processes could be a major blocker in the change journey of your teams.