The Forgotten Agile Principles

Posted By Duncs ~ 28th June 2013

I recently watched a great TED talk from Simon Sinek titled “How great leaders inspire action”

The main point that Simon makes in the talk is:

“People don’t buy what you do, they buy why you do it”

He was coming from a marketing perspective, but the talk resonated for me because of its application to “Agile”.

The majority of this post focuses on Simons model “The Golden Circle”. The second part of the talk moves on to the “Law of diffusion of innovation” which I don’t cover here. For a testing focus on on law of diffusion of innovation, I’ll refer you to Johanna Rothman’s Lets Test 2013 keynote “How to be a Kick Ass Manager“.

In the talk Simon describes his model of “The Golden Circle”:

goldenCircle1

The model consists of 3 concentric circles:

Outer circle = What

Everyone knows what they do

Middle circle = How

Some people know how they do it. E.g. USP

Inner circle = Why

Few people know why they do what they do E.g. purpose, cause, belief

Golden Circle Applied

In the marketing context, most marketeers work from the outside-in (red arrow), from the clearest thing to the fuzziest thing. But inspired leaders & organisations think from the inside-out (green arrow).

goldenCircle2

From the inspired leaders & organisation examples Simon gives in the talk (e.g. Martin Luther King, Wright Brothers, Apple) the inspired have more belief in their product than the “uninspired”.

This belief gives the inspired greater passion & deeper understanding of their product which is evident when they are “selling” that product

Which brings Simon back to the quote:

“People don’t buy what you do, they buy why you do it”

This related to Agile, how exactly?

The way I see it, the signatories of Manifesto were focused on the “Why” of Agile - they knew why they were together & what they had to achieve

They created the 12 principles & the Manifesto itself is a digest of those principles.

For me, the principles form the “Why” inner circle & Scrum & Lean are examples of the “What” outer circle.

goldenCircle3

The signatories - the inspirational? - were working from the inside out when they created the manifesto.

So what’s the problem?

It appears to me that too many people have brought into the “Agile” product without fully understanding the reasoning behind buying the “product”.

They understand what the product offers & to a certain extent how to adopt the processes of the product, but they miss why they opted for the product in the first place.

They are working from the outside in & missing the principles behind the processes & the product.

This impacts the way they adopt the product & its associated processes. The product drives the process, not the principles behind the processes.

This is also applicable for some of those less scrupulous selling Agile consultancy - the sellers don’t need to know why, the customer already thinks they know why.

Have you heard the joke about the medical students who find studying to be a doctor too hard, so they rip out the page which talks about teeth & study to be a dentist instead? This joke makes me think of all the people who rip out page 1 of the manifesto & disregard page 2 (principles)

What about me?

My experience of Agile is very, very limited but I have been fortunate enough to be around people less ignorant than me about the topic. One tip I received in my very early days on my 1st Agile gig was (para-phrased)

“…its about the principles. Once you understand those, the rest makes much more sense.”

That has stuck with me ever since & I use it as my heuristic when talking about anything remotely related to creating a more agile & adaptable process.

I love the agile principles & some of the processes - they have reinvigorated my interest in testing. This includes manual testing for all you XP fanatics out there. I’ve written more about my approach to testing in this post. That was in 2011 - its slightly different now as I am in a different organisation, but the approach still serves as a heuristic I use to help me test.

For me, words like “Scrum”, “Lean” & “Kanban” are less important than the way we work.

Call our process what you want, so long as we all understand what the process is & why we are following it.

In my opinion, the “Agile” buzzwords by themselves won’t help improve software development, it is the meaning behind those buzzwords which are important.

  • Tony Bruce

    Good post Duncan. I had a similar kind of post: http://dancedwiththetester.blogspot.co.uk/2012/03/agile-schmagile.html

    I totally agree, it seems people are attempting (what they think are) agile practices and not understanding the principles. Essentially going through (what they think are) the motions.

    @tumma72 gave a talk titled ‘Why practices are not as important as principles?’ at #agiledevprac which I think you might like. It was on this very topic. Slides are here: http://www.slideshare.net/tumma72/why-practices-are-not-as-important-as-principles

    • DuncanNisbet

      Thanks for stopping by Tony & I appreciate your feedback.

      Thanks for the link to your post - I’ve commented. How have you tried to overcome the issues you’ve observed?

      Also - thanks for the link to Andrea’s slide deck. I’m going to have a proper read of the slides later. It appears he has gone into much greater depth than I have.

      Duncs

    • DuncanNisbet

      Here’s the associated blog post to the slides:

      http://www.agile42.com/en/blog/2013/03/05/why-principles-are-more-important-practices/

  • Mohinder Khosla

    Your model of golden circle as applied to Agile is partially incorrect. To re-iterate what Simon Sinek meant with why, how and what is: why defines the vision that comes from non-verbal part of limbic brain. How is the mission (actions) whereas what is the result of mission. When mapped to Agile: the why is to deliver high quality software to budget and on time that meets customer requirements. Hows are the guiding principles to deliver the software. What is the result ie practices such Scrum, lean, XP or BDD chosen dependent on the context to deliver the software. In other words WHY provides Clarity to your vision that enforces WHY you do WHAT you do. HOWs guide you through Discipline (values and principles) to bring the vision a reality. WHAT provides Consistency to achieve end results of vision through actions of HOWs.

    Messages:

    A Why needs a How = Mission

    Skip Why at Your Own Peril

    Even Organisation following inside-out approach get struck at the What stage. They make the mistake of not revising their whys when they do instead carry on regardless . As they carry on with the What, they suffer a split that results in Why going fuzzy.
    There is more interesting stuff in Simon Sinek book Start With Why.

    Mohinder

    • Johan Jonasson

      I’m confused. Why should someone revise their “Why” when getting to the “What” stage? Wouldn’t that mean (at least partially) giving back the lead to the “What” instead of the “Why”, making it an outside-in approach all over? If The the solution/product/practice isn’t implementing the vision then change the solution, not the other way around, right?

      Also, if the “Why” of agile is to deliver high quality software to budget, on time, meeting customer requirements, then I see no real differentiator to any other software development approach.

      • Mohinder Khosla

        Can you describe your vision accurately? People who can are
        very articulate I would say. Most Organisations have vision but they do not know what they really want. That’s why we use visual aids such as impact mapping, mindmaps to model the system. The fact is that vision comes from limbic brain that has no language. We use imagery, metaphors, analogy etc to describe it. Vision passed to Neocortex (language part), that works in a linear fashion , work out details that is generally incomplete. I would say some of the vision is lost in translation. Because vision is your mystery that you are trying to solve, you resort to analytical techniques to find solutions.

        In many cases, when you have a problem to solve you do the brain brainstorming, come up with a list of possible alternatives and select the one that would work for the business. You, then, use develop heuristics that guide us towards a perfect solution by way of organised exploration of possibilities and becomes our Hows. Once you established this you develop algorithm that fits the solution. That’s where most Organisations tend to stay, re-running the algorithm or keep on tweaking and running it. If you are not making further advances or the solution is not fit the business anymore or market has moved on, you should revisit the vision and re-align and pick another possibility from previously discarded list that may
        give you improved better solution or think of a better way of doing things to keep going. Change is inevitable and revising your vision is a necessary evil to survive in the market place. Vision is part of the system and you shouldn’t work on parts without whole in mind.

        Why companies resort to outside-in approach: 1. it is hard to describe vision 2. It is easy to pick up established practices and get the job done. Company bosses are after reward and are not worried how they get there.

        The main difference between Agile and Waterfall is that it continuous
        delivers increment value with the customer participation throughout the development lifecycle. All development processes are sequential no matter how they draw it on the paper like Deming PDCA cycle.

        The

        I hope it helps

        • DuncanNisbet

          Thanks for keeping the conversation going, its greatly appreciated Mohinder.

          You’re taking my use of the model to a level I hadn’t even considered!

          Just to reiterate, my focus was on Agile adoption & peoples/companies perception of Agile.

          Is it hard to describe vision? IMO no, if you believe strongly in & understand that vision / belief.

          I agree change is inevitable, but I don’t believe that change stretches to beliefs. For example, I will not wake up tomorrow & go to the beach as I need to provide for my family.

          As for why organisations resorting to outside-in approach - I would see that as part of the problem of Agile adoption I described.
          People don’t want to make the effort to dig that little deeper & persist with a challenge which by no means is easy.

          Who said Waterfall can not deliver incremental value without Customer participation?
          I’m not sure that that (?) is the main difference between Agile & Waterfall & its certainly not what I am trying to cover in this post.

          Duncs

        • Johan Jonasson

          Still a bit confused 🙂

          I wanted to focus more on the vision of agile, i.e. why should I try to implement an agile process/framework in my organization, and why should I do this from a “Why” perspective rather than a “What” perspective. (A “What” reason would be: “Scrum is a well-defined, proven model for software development. It works great for many other companies. Would you like to use it too?”)

          And about describing the vision. Yes, I do think I’m able to describe my vision(s) rather accurately. I do it every time I apply for a new job or contract, or each time I’m trying to convince somebody that my company is different from other software testing services companies. I pretty much have to, because I can’t very well say that “I’m ISTQB certified and cheap”, because 1. I’m not. 2. That’s not a differentiator from 100.000 other software testers.

          So if I was selling Agile, I would need to think about what the vision of Agile is, and then come up with a whole inside-out approach to convincing customers that I’m better at implementing that vision that anybody else is. Sort of a Double Why Proposition - trademark! 😉

          • Mohinder Khosla

            Agile is no silver bullet but a buzzword that is mis-sold.
            Agile has been around longer than the Manifesto and the principles therefore agile vision has not changed. You can read history of Agile Manifesto here http://agilemanifesto.org/history.html . DSDM (http://en.wikipedia.org/wiki/Dynamic_systems_development_method)
            launched in 1994 is the probably the longest running agile methodology around. What the agile movement has done is to highlight the fact that removing waste and make people accountable in the development process would lead to better and cheaper solutions that are timely delivered and customer focused.

            Agile comprises of a set of practices that projects adopt but may not be the right for them but are selected on the basis of experience in the team or hiring an untried consultant. Many projects fail as a result of this choice. It does not work for every project or Organisation. For Agile to be successful, it has to be engrained within the Organisation at all levels.
            You should not call yourself Agile if you succeed once on an agile project, it has to be repeated every time for every project to get to retain the title agile.

            The manifesto was drawn up more than 12 years ago and things are very moved on and business pressure and priorities are not the same. Your vision for product delivery may be different and you may choose to adopt some
            of the agile principles to deliver the project. Agile are not only guiding principles around. There is CDT manifesto and Cynefin framework and so on. You should consider all those to come up with the right solution for a given context. Some companies work in a regulatory environment and agile principles are unworkable. I have met a consultant, who is written a book on Agile and practice agile but he convinced that agile is not the right and the only way of delivering software solutions.

            Simon Sinek says that great companies hire people who are
            motivated and inspire them. They want to do business with people who believe what they believe in. If your beliefs do not match with the Organisation you work for then you should leave. People who buy Apple products believe in whys behind their products irrespective of price tag.

            In reply to your vision perspective, you describe your vision
            through values you offer and that may not be completely true. If we can write down everything we visualise then we will get perfect requirements from the customers but it is very hard to put down everything on the paper. I thing if
            you want to sell your skills then you need to find your niche. I would recommend Hedgehog Model (http://en.wikipedia.org/wiki/Good_to_Great)
            to do that.

            I don’t want to pour all my wisdom here but you probably would have figured out where I am coming from. Don’t hung up on the idea of agile, there are better ways of delivery software a. Find your niche, articulate your own guiding principles and hard sell.

            I hope that help clarify some of the points you raised here

            Regards

            Mohinder

          • Johan Jonasson

            About the vision perspective: I don’t necessarily mean to focus on skills (even if I might have implied that). I’m thinking of a higher level of abstraction. Why me/my services/my company? What are the /principles/ that distinguish us from others? If we’re talking about skills then I think we’re likely down on the “How” layer of the model.

            Re: Don’t get hung up on agile. Yeah, I agree. But I also think that Duncan’s post is a relevant perspective on agile and why people like myself have sort of become bored with the idea of agile (i.e, to me, there’s too much focus on what, too little on why when implementing the principles, or _any_ principles).

            The model is relevant for agile as well as any other set of principles, we’re just using agile as an example here. Why I think it’s relevant is because whenever you try to sell a principle, you lose a number of people who don’t have either the attention span or fundamental ability to grasp concepts on that level. There’s a risk that we place too much focus on process and tools, that end up changing nothing in the end, because we’re letting the organization or team lose sight of the principles that triggered the change. Or worse, the change was triggered by someone looking at someone else’s implementation of a frameworks and only heard the “+300% productivity!!” bit, which caused a silver bullet to go off in their head and, voila, the focus is stuck on the “What” without them never even bothering with the “Why”.

            So never mind Agile, I just like the model. It may be flawed, but I think it’s a good way to strike up a conversation. And agile is an easy thing to apply it to, because we’ve all seen both success stories and failures with agile that I think the model can at least partially help us explain the reason for both success and failures.

      • DuncanNisbet

        Interesting point Johan. Personally, I don’t think the “Why” should change.

        You inadvertently pose a good question as well: what does the “Why” of Agile mean to me? I have the high level answer, but I need to understand what my beliefs are.

        Tony Bruce asked a similar question on Twitter - Think I’ll try & work out a reply…

        Duncs

        • Johan Jonasson

          I think the “Why” of agile is in the principles, like your post suggest. Here’s s quick stab at it:

          Why Agile: Whatever project we’re working on, we believe in putting customer satisfaction first and deliver a continuous stream of high value software. We view changing requirements as a natural part of the creative process and believe in collaborating and communicating with the customer to harness that change for their competitive advantage.

          How Agile: We make this possible by building capable, autonomous teams of motivated and empowered individuals and by promoting a sustainable development pace that allows us to deliver at a consistent and predictable rate without compromising on quality.

          What Agile: In our context, the Scrum development framework is the best tools we’ve found so far to realize our goals. Want to hire us?

          Now… to go back a bit to the “changing of why” question… If Scrum turns out to be difficult for your organization, would that mean you should modify your vision as stated here? Probably not, right? You’d try to modify the process or pick a different framework.

          • DuncanNisbet

            Nice reply Johan. I particularly like the “How” - I had skirted over that in the post. From reading your view of “How”, I can see several potential reasons why Agile adoption may fail.

            Good point on change - changing the “What” makes more sense to me & is probably easier.

          • Johan Jonasson

            Well, changing the Why might be easy too, but then you’d have to start all over. 🙂 (at least if you still want to work from the inside-out)

            Changing the Why is to make it fit the What sounds very much like having the “solution” control the “problem”. (e.g. I will redefine your vision/model/organisation/context so that it conforms with my best practice/tool/process/standard!)

    • DuncanNisbet

      I see your point Mohinder, I’m now thinking I didn’t make the context clear.

      I wrote this post from the perspective of the Agile Manifesto signatories & how their idea of Agile had been bastardised by the sometimes bizarre implementations of their manifesto.

      The “Why” for me was the signatories beliefs & purpose for being together in that location at that time.

      Did the signatories put forward any of the suggestions for implementing the Agile principles there & then? I have no idea. Do I think the “product” would have turned out differently if they did? Possibly.

      Would the “Why” of an organisation ever change? Is the “Why” something that should change?

      For example, I have deep beliefs & purpose, like providing for my family & treating others as I expect to be treated.
      If I find myself not making money, or being ignorant of other people, it is my behaviour that I would want to change, not my beliefs.

      Thanks for the link to the book Mohinder - It sounds like it should really help my understanding of this topic.

  • Simon Morley

    Interesting post Duncan. I hadn’t seen the TED talk before, thanks!

    I’m not totally convinced about the golden circle - the examples for and against it might be a convenient fit - maybe I need more data. But the concept of acting and behaving true to your beliefs/values is acting congruently (to me) - ref Satir & Weinberg

    Starting with WHY as opposed to WHAT is something I’ve been looking at in the last year - and I used a couple of models to illustrate the problem of focussing on HOW/WHAT instead of starting with WHY, here: http://testers-headache.blogspot.se/2012/12/mapping-information-value-in-testing.html

    I started looking at this from a testing communication viewpoint -> i.e. focussing on WHY we use WHAT information rather than HOW (test case counts are a typical HOW).

    The move from How to Why also reminds me of Design Thinking: http://en.wikipedia.org/wiki/Design_thinking

    I agree with you on the “Agile adoption” problem -> people focussing on an activity (WHAT) and then asking, “are we Agile now???” -> missing (or not seeing) the point.

    • DuncanNisbet

      Thanks for adding your comment Simon, greatly appreciated!

      Agreed, it might not be a perfect translation for Agile adoption, but it really helped frame the problem for me & enable me to communicate that problem.

      I’ve been having some valuable lessons in congruency recently - knowing about congruency has really helped me understand how I feel (confused, fustrated, angry) when someone’s behaviour does not match what they’re saying.

      Thanks for the link to your post & the link on design thinking - I’ll have a look later.

      I definitely agree with understanding the “Why” - I tried explaining it in this post: http://www.duncannisbet.co.uk/less-than-three-there-there-should-never-be

      Reading back on it now, I should the post to include the Business Stakeholder & the Programmer knowing “Why” - that seems like an obvious omission.

      “Are we Agile now???” love that! Swiftly followed by “No, we tried Agile, it didn’t work”…