Agile and Scrum – A metaphor that works

Geert Bossuyt

Scrum and Agile are not synonyms. Scrum describes a process ( a set of activities) but its only Agile when you do this activities in an Agile mindset.
You can easily be Agile without using Scrum, and it’s definitely possible to do Scrum in a way that is not Agile.

Having a good metaphor can help speed up the understanding.

If Scrum is like riding a bike, then Agile would be the sense of balance.

In riding a bike you have to move your feet in a certain way to go forward, you move your arms to steer and use your left thumb to get rid of annoying granny’s driving in front of you. This is easy. A simple set of rules to follow. Just like Scrum.
However without a good feeling of balance, you can never become a good biker. Agile thinking in Scrum is like this feeling of balance on a bike.

Small kids that learn how to ride a bike, get to do all the activities themselves even from the very first day. They move their feet, experiment with the steering wheel and try out the bell. But because the feeling of good balance is not yet there, the parent runs after them with his hands on the kids shoulders to prevent them falling.
After that, little wheels are added, so the kid can experiment further in a more independent way. Only after a while, the extra help is no longer necessary and the little biker can ride a bike on his own.
None of this extra support is aimed at helping the newbie to move his legs or arms. Performing the right activities is not the issue. That’s easy. All the support is focused on helping him to find this feeling of balance.
Later, after riding the bike for a good period of time, the little biker might like riding a bike so much that he wants to become really really good at it. Balance is no longer an issue, so now a trainer can improve his position on the bike, the way he moves his legs, … Improve the activities to excel the performance.

Learning Scrum and Agile is exactly the same.

The activities ( process) you need to do to work Scrum are simple. Standups, retrospectives, planning poker, delivering working software … these are the easy things. Every member of a Scrum Team can do this. However the Team and every individual needs to feel the balance, needs to think Agile. First with support and then on their own.

Only when thinking Agile has become a second nature to the Team, it’s worth the effort to improve the actual things they do.

<< You want us to focus on Individuals & Interactions instead of Processes and Tools, but even with the best feeling of balance, I will never win the Tour de France on a crappy bike >> a manager once said during a training.
That’s true off course, nobody can win the Tour de France without a very good bike. But even with the best bike in the world, if your balance is not 100%, you will fall.
Tools can help but it’s the individual that makes the difference. When I get to compete using Armstrongs bike and Armstrong using my grandfathers bike, I'm pretty sure he’ll still be faster than I am.

Comments (14)

  1. Patrick Verheij - Reply

    November 28, 2010 at 9:52 pm

    Nice metaphor, balancing on a bike. Personally I would think the 'agile' part of riding a bike would be being able to break when a truck shows up from the left. In that sense it is like traffic: you can anticipate, but you never know what actually shows up on your way to your destination. 'balance' in itself would be the competence to ride the bike at all. In software terms, that would be the ability to develop working software in a decent way.

    Funny you say that agile practices are easy. My experience is that they just look easy, but are hard as stone in reality. A couple of weeks ago, I experienced a Scrum Master explain planning poker in a way that was just dead wrong.

    Ans then the need to think agile. That comes from thoroughly understanding both the practices you perform and the ability to think in tms of flow and value. People will only start thinking agile when they actually see what effect their actions and those of others have in practice. You you will have to improve those practices first and then guide the people to see the effects that spawn from them. If you wait to improve until people are able to think agile, you can wait for eternity.

    Nevertheless, I really like the metaphore. Bikes have been used as a metaphore in IT commissioning once too. Keep up the good thinking.

  2. Geert Bossuyt - Reply

    November 29, 2010 at 10:26 am

    I like the addition of the unexpected events in Traffic. If you know how to ride a bike, and you've developed
    a strong sense of balance, you will be able to break when a truck shows up unexpectedly. While breaking is just an activity, and in itself very easy it will only be effective if you stay on your bike instead of panicking and falling

    Developing software in a decent way is not new. That has been done for ages. I believe this is definitely not one of the basics for Agile. THe basics are in collaboration, interaction and feedback.

    You don't have to wait improving until people think Agile, you have to start improving right away, and focus your first improvements on the Agile thinking. Don't start improving the process or whatever tools because that can never become a success unless their used in an Agile way.

    Fun to read you like the metaphor !

  3. [...] This post was mentioned on Twitter by Todd, Eike Lang. Eike Lang said: Some comparisons work (for me, tm), after all: http://blog.xebia.com/2010/11/28/agile-and-scrum-%e2%80%93-a-metaphor-that-works/ [...]

  4. Patrick Verheij - Reply

    November 29, 2010 at 11:03 pm

    When you put it that way, the balancing really adds something: you are agile enough to move out of the truck's way and not taken off guard so you stay upright and quickly get on with your quest to reach your goal.

    However, I kindly object to your statement that developing decent software is nohing new and that it is not one of the basics. Developing software IS hard and there are huge differences in productivity between programmers. Besides that, technical excellence is considered a cornerstone of agile practices and methods. I might go as far to state that you will have a hard time catching up with an agile team if you cannot develop software decently. Self organizing teams will quickly identify their weakest members.

    I agree with your statement that one should not start improving processes and use of tools. Instead, focus on practices and make their effects visible to open people's eyes for true added value. Or maybe by cating a story about bikes and balance 😉

  5. Bossuyt Geert - Reply

    November 30, 2010 at 9:18 am

    Completely agreed that generating good feedback is crucial to start improving. Implementing Agile best practices is a good thing to do.
    Practices like 'work story by story' or 'respect your timebox' can help a lot to maximize feedback opportunities.

    Other Agile best practices are focussed on interaction and collaboration. This is great and can help people to understand the way we want to work. Examples here could be 'pair programming', 'get your customer in the Team' and 'meet daily on impediments and progress'.

    Some Agile best practices are focussed purely on technical excellence. Examples : 'Test automation', 'continuous integration' and 'transport optimization'. In my opinion these are not the urgent ones to implement because they only focus on technicallity and not on the interaction part. You will deliver more software without already knowing what to build. Or with the metaphor : It will make you go faster, but without a thorough sense of balance you will crash into that truck if one comes along.

  6. Patrick Verheij - Reply

    November 30, 2010 at 10:15 am

    Yes, the way you state it shows that we have to balance our efforts to bring agility to an organisation.

    For example, in several organisations I have witnessed a very open culture with already a lot of communication, transparency, empowerment and even customer involvement. Alas, the technical not-so-competent people kept discussing requirements and their priorities in such details that hardly any results were delivered at all. The technical part was continuously being postponed.

    When you looked under the hood of all this communication, you could see that not all of it was effective, but the technical lag endangered the project. So what to improve in this case? We chose for the technical part by making the teams deliver some quality results. In the end that also improved communication.

    But anyway, personally I agree with the interaction-and-collaboration-first-approach. That's exactly what I am doing right now for a customer who is truly stuck with a supplier that is in significant technical debt. First we need to get them become friends again and after that we need to work on the technical part straight away.

    I assume Xebia has embedded a certain "roadmap" in her agile maturity model? I haven't seen it so far, but would very much like to experience it. Is it publicly available?

  7. Vincent Partington - Reply

    December 1, 2010 at 12:03 pm

    Hi Geert,

    You say "Developing software in a decent way is not new. That has been done for ages."

    While decent software has been developed in the past, it is certainly not a given that all software developed nowadays is developed in a decent way. The thinking that good process will lead to good content is wrong and that is why I am happy with the software craftmanship movement now popping up. You can be agile as hell and still deliver bad software/cars (Toyota anyone?)/etc.

  8. Patrick Verheij - Reply

    December 1, 2010 at 12:17 pm

    Vincent, I agree with you. Keep in mind however that the recent issues at Toyota have everything to do with the fact that Toyota failed to adhere to its own lean principles (as I have overheard, not witnessed). So be careful to dismiss their approach and remember that it helped them become the biggest and best car manufacturer before.

    One of the philosopies of TPS is "The right process will lead to the right result". I think you have to see that in Toyota's context to be able to value that.

    Nevertheless, you can never rely on process if competency is lacking.

    By the way, I hope Geert doesn't mind us going off topic a bit. I always love to see where discussions end up eventually.

    And I am still most interested in creating a decent parabel that involves bikes and trucks 😉

  9. Geert Bossuyt - Reply

    December 7, 2010 at 1:50 pm

    Vincient,

    As said, "The basics are in collaboration, interaction and feedback." Nothing about the a process here ...

    Sure, you can deliver bad software in all circumstances. However, the better the feedbackloops and the better the interaction, the more you really have to try to get bad software come out of it 🙂

  10. Geert Bossuyt - Reply

    December 7, 2010 at 2:01 pm

    In discussing this metaphor with several people, a nice extra addon came along :

    Agile is also about the choices you make. E.g. a little girl sees something happening on the street and she immediately hits the breaks. That's not Agile. Agile would be to quickly respond to the change of events.
    (Thanks Jarl)

  11. Patrick Verheij - Reply

    December 7, 2010 at 2:50 pm

    The little girl hitting the break without any further information has in itself nothing to do with agililty indeed. Agility has to be considered in a certain context AND in relation to certain goals or intentions. That is 'being able to quickly respond to a changing event'. However, the metaphor ends here because we never discussed little girls in that situation yet.

    In order to prevent us from beng followed by the US government, I suggest we drop that metaphor and start talking about a fat butcher on a bike instead. Or anything of your own imagination that does not relate to children dictly.

  12. Geert Bossuyt - Reply

    December 9, 2010 at 9:58 am

    Another nice metaphor ( thanks Rini ) : Scrum is to Agile like Barcelona is to soccer.

  13. Geert Bossuyt - Reply

    December 9, 2010 at 10:09 am

    Dot Net metaphor ( thanks Fernix )

    If a Sprint were a .net Framework type it would be System.String type because it is immutable.
    If the ScrumMaster were a .net Framework component it will be the CLR because it is the supervisor and responsible for the correct implementation of the Scrum process just as the CLR is the supervisor of all .net programs, guaranteeing certain properties and behaviors.

  14. Patrick Verheij - Reply

    December 9, 2010 at 10:22 pm

    System.String.Concat(String, String, String, String) would be a valid anti-pattern, as would be System.String.CopyTo(), System.String.EndsWith("Disaster") and System.String.Equals("Previous sprint").

    The only real valuable pattern would be System.String.Trim(), which would be a really lean version of Scrum.

    But the bottom end is: if a sprint would be a .net Framework, it should become depricated as soon as possible 😉

Add a Comment