Simon Sinek is well-known as a writer and commentator on Inspirational Leadership. In this article, we look at how Sinek’s ideas can be applied to Agile and Scrum and look at how we, as Agile leaders, can become more inspirational. Sinek is highly visible on social media and has written five books. An excellent overview of his ideas can be found in his TED video. For this article, I will be drawing on ideas from his 2009 book Start with Why.
Sinek’s argument can be summarised as follows: Inspirational leaders have, and communicate, a clear sense of WHY they do things, a clear belief. It is critical to also understand HOW and WHAT you are doing, but they should be guided by the WHY.
One of many examples in the book is Apple who, he argues, has a strong and well-communicated WHY: They want everything they build to challenge the status quo. And it is this that inspires people to queue for hours outside shops to get the latest version of an Apple product. Managers, engineers, salespeople, etc. are employed to deal with HOW and WHAT, but they are always guided by WHY. He argues that other computer and electronics companies tend to focus on the What: products, features, pricing, quality, etc. While they may be successful, without a strong sense of WHY they are not inspirational.
Another example he gives is that of Martin Luther King, who inspired the world with his “I Have a Dream” speech; it was not an “I have a Twelve-Point Plan” speech. Sinek points out that Dr. King was surrounded by people to help with the HOW and the WHAT, otherwise, his dream would have remained a dream
WHY is not about making money, Sinek argues; that is simply an outcome. A true WHY is more about, “Purpose, cause or belief.” According to this logic, I bet almost all of the projects we have ever worked on have no clear sense of Why. Project value cases mostly center around increasing sales revenue, increasing productivity, reducing time to market, or reducing operating costs. Essentially, making more money. These projects could be more inspirational if they had a clear Why.
Goals in Scrum
Goals have always been an important motivational and guiding tool in Scrum, specifically the Sprint Goal. The 2020 version of the Scrum Guide introduced the concept of the Product Goal. But what are these Product Goals?
Conventional wisdom, and many writers on the subject, have stated that these goals should be measurable and quantifiable, which makes perfect sense. The problem is the more quantifiable, the less inspirational. As an example, Salesforce states on their website that their customers see an average 44% increase in Lead Volume, 37% increase in Win Rate, 37% increase in Sales Revenue, etc. Sounds great, but is it inspirational?
What happens when we lead with the WHY?
“This CRM package aims to make all your customers feel like old friends.”
“We want all your customers to feel like your number one priority.”
“This CRM helps you build relationships, build trust and build loyalty.”
But, you might be thinking, these goals are not quantifiable so how will we ever know if they have been achieved? The answer is it doesn’t matter. This is the WHY. From here we can figure HOW we are going to do it and WHAT we need to do to make it happen. It is typically the WHATs that are quantifiable.
Perhaps we should all sit down with our Product Owners and work on Product Goals that lead with the WHY.
WHY Statement and the Backlog
A strong WHY statement for our Product Goal is a powerful tool to drive the developing, ordering, and refining of the Backlog. As an example, let’s take the CRM Why statement mentioned above. We want our CRM to enable all customers to feel like old friends.
Now let’s take a look at a backlog item:
We want to ensure that customers go through self-help pages before they can contact the service-desk so as to reduce call volumes.
It’s a very common requirement in Service Desk CRMs, but is this how we treat our friends? Do we try to avoid talking to them for as long as possible and only agree after putting them to some considerable inconvenience? Perhaps those that do would not keep them for long. To be more consistent with our WHY statement, our backlog items could be changed to the following:
We want to give all our customers the option of both self-help material and contacting a service agent directly.
Many of our other backlog items could be checked against our WHY Product goal. For example, sending out newsletters to our customers or sending out automated emails to customers who have not bought from us in a while. We all know that we don’t send newsletters and automated emails to our friends.
One of the banks I have an account with uses voice recognition software on incoming Service Desk calls. The other bank I have an account with does not. The one that does not normally greet me with requests for information, such as account number and name, followed by a string of security questions. The one using voice recognition software greets me with, “Hello Mr. Baker, how are you today?” I think we can all agree that we don’t normally ask our friends for their date of birth and mother’s maiden name.
So the requirement to use voice recognition software would be consistent with our WHY statement. Of course, we would then have to figure out HOW to use it, WHAT are the security risks, WHAT are the costs, etc.
There is no complex prioritization process required here; we just know whether these backlog items fit with the WHY statement. A Product Goal containing a Why statement can be so much more powerful than a long list of WHAT and HOW phrases.
Sprint Planning
I remember in the early 2000s when offshoring and outsourcing were the new big thing. The thinking went something like this: Anyone with reasonable coding skills can convert requirement specifications into lines of code. It doesn’t matter where they are or in what time zone. They should be able to do the job. And of course, developers in most offshore locations were a fraction of the cost of on-shore developers. So, during the following years, millions of lines of code were written by hundreds of thousands of off-shore developers who hopefully had some idea of WHAT they were doing but not the faintest clue WHY.
Much has been written about the advantages and failings of off-shore development, but in my case, I went from two on-shore developers to seven off-shore, and my productivity went down. I was discouraged from even speaking to the developers or holding team meetings because, after all, we were paying for a service not for resources. We were completely focused on the WHAT; the WHY was absent.
Contrast this with Scrum, where the entire Scrum team attends the Sprint Planning and gains an understanding of WHY we are doing the work. An interesting addition to the 2020 Scrum Guide is a Why statement in Sprint Planning. Previous versions only mentioned WHAT and HOW. The 2020 guide specifies three sections to the Sprint Planning:
One: Why is this Sprint valuable?
Two: What can be done with this Sprint?
Three: How will the chosen work get done?
Commenting on the changes, Jeff Sutherland states, “Discussion of the why gives the Scrum Team the context that may otherwise have been lacking. We’ve found that Scrum Teams who understand the intent of the Product Owner deliver better results and higher quality.”
The Scrum Guide is now encouraging us to lead with the WHY.
So the PO can inspire the team with a WHY, a goal, an aspiration, and a sense of purpose. And, of course, the entire team attends this event, not just the leads. We have come a long way from the days of developers slavishly converting specs into a code with no sense of Why.
Inspirational Scrum Master
We all know that the Scrum Guide is concise and to the point. It tells us step-by-step what to do to deliver projects within the Scrum framework. It doesn’t mention that this short prescriptive guide is built on decades of fascinating research, inspirational writing, and ground-breaking ideas. As a Scrum Master myself, I believe passionately that we have a duty to bring this guide to life and explain not just WHAT to do but WHY we are doing it.
Sinek also talks about the criticality of honesty if we want to inspire people. I think some of us in IT and business have, at certain points, pretended to understand things that we didn’t. These days I am favoring being totally honest about my shortcomings for several compelling reasons. Whenever I start work with a new Scrum team, I make it clear from the outset that they are all my technical experts. “I am not a developer,” I will say. “I have never worked as a developer and all of you know way more about writing code than I do.”
And the theme continues throughout the project:
- “Can you dumb it down a bit; remember who you are talking to.”
- “Well, even I understand that.”
So why do I do this? Why don’t I just bluff my way through it?
Firstly, a bit of self-deprecating humor often helps people feel more at ease. But more importantly. I am building trust. I am building an environment where it is ok to not know or not to understanding something and where it is ok to ask questions.
Most importantly, I am building a sense of mastery within the team. I am acknowledging that not only do they know more than I do, but their skills and expertise are critical to getting the work done and building our product. This is a huge factor in building motivation.
Inspirational Agile Transformation
Many Agile transformations are driven by a desire to increase productivity, or at least not be left behind by their competitors who may be benefitting from productivity gains due to increased Agility.
A typical business case for Agile transformation could look something like this:
Our overarching objective is to increase year-over-year profits by 10%. We plan to achieve this by both an increase in sales revenue and a reduction in operating costs. Through adopting Agile, we believe we can reduce time-to-market, allowing us to be more competitive and increase sales. With the increased Agile productivity, we believe we will be able to reduce our FTEs in both IT and Operations.
We have all heard statements like this. They sound quite reasonable — logical, analytical, and based on some empirical evidence. But are they inspirational? I think we all know the answer to that. They are a string of outcomes, WHATs and HOWs. There is no real WHY.
How about if our Agile transformation business case was more like the following:
We want every employee to come to work with a smile, to feel they are doing the best work they have ever done, and to feel like this is the best company they have ever worked for.
Hard-nosed businessmen and women may well argue that smiles and feelings will not satisfy the shareholders, increase the share price, or pay our salaries. But what if they are wrong? What if this WHY statement wins hearts and minds, dissolves resistance to Agile transformation, results in individuals who work tirelessly to build excellent quality and teams who can move mountains? Would that impact the share price?
WHAT and HOW statements can be convincing. Yes, we can deliver incrementally so that users get value from the product earlier. Yes, we can adapt to changing requirements. And yes, we can detect defects and deviations from requirements early through regular Sprint Reviews. But instead of starting with WHAT statements, why not start with the WHY?
