FUZA

Author: fuzapost

  • Agile research needs help

    Reading some academic papers on Agile recently, there is a huge misunderstanding about what Agile means.

    In particular, some academics use the word Agile when really they mean Scrum. There are papers (for example this one) which say “agile teams” and continue on to describe how long their iterations (or even worse, Sprints) are. Sprints are a feature of Scrum alone, of all the Agile frameworks: the Agile framework of Kanban for example does not have iterations. Maybe this is an accidental slip-up, but I would hope for more accuracy from academics.

    There are also lots of really great articles by people who helped come up with the very idea of Agile. The reason I am worried about even a few dodgy papers is that one experiment (or research paper) can easily be cited out of context or generalised by another paper, leading to huge misconceptions and ultimately a misleading (but popular) HBR or linkedin article without the right context.

    Having said this, it is great that academics are starting to look at Agile: some claim the “research lags years behind of the practice” [1]. For me in particular, I am interested in whether the motivation experiments (which we rely upon for incentivising software developers and trying to keep them motivated) truly apply to software development tasks. This BBC article summarises some of the studies, on playing computer games, maths tests, and repetitive-key pressing. But there are none that I can find which examine software development motivation.

    In some disciplines, generalising and abstracting is necessarily bread-and-butter: in Physics this makes loads of sense, but in Psychology given how complex and counter-intuitive some human decision making can be (eg “it was found that everyday hassles and uplifts were a better predictor of concurrent and subsequent psychological symptoms than were the life events scores” [2]). I’d love to share more of these things in a subsequent post, though I am by no means an expert in Behavioural Economics.

    2014 most common jobs
    The most common job in each US State (2014)

    The most common job in several US states is now Software Developer (rather than Secretary or Farmer, as it once was) [3]. Given the huge numbers of people now employed as software developers throughout the world, it would be great to be sure that we are interacting and incentivising them properly.

    I hope this post inspires some academics to get more involved in fieldwork and talking with industry, and also inspires some Agile evangelists working in organisations to take a bit more of a rigourous and self-critical perspective when it comes to documenting and sharing what they are learning.

  • Working with international teams

    I thought it might be good to share some of the things I’ve learned from my five years working in international teams. This is purely based on my experience, so feel free to share any differing opinions.

    Firstly, I’d like to point out that multi-country collaboration can work! I’ve worked in teams and had many meetings with one person in Brazil, France, Spain, and the UK. The most challenging part is the very few hours of shared time together (if across multiple timezones) so make the most of those hours together. I’ll be focusing on video-calls as I found these essential for international working.

    Videocall setup tips:

    • Make sure the camera can see everyone (a lot of communication is nonverbal).
    • Power imbalances make communication hard, so try to switch “hosting”.
    • Everyone being in the same social situation helps eg evenly sized groups or all individually dialling in (yes, even if in the same office go to different spaces).
    • Having a constant Hangout/Skype on can help, depending on the amount of collaboration required. If you don’t need to collaborate, I find it distracting.
    • Arrive on time LIKE IT IS A NORMAL MEETING.

    Improving videocall quality:

    • Background noise adds up and interrupts others: put yourself on mute if not talking.
    • Using headphones stops Skype’s auto-cut-out and allows you both to speak and listen at the same time.
    • Plug in the ethernet (not just wifi).

    Building team connections in other ways:

    • It is very much worth (early on in the relationship) visiting each other’s locations for at least 2 weeks. 2 weeks because it gives a weekend to relax and understand the culture better, as well as to know the people you will be working with.
    • Go to the pub, sportsbar, or culture-appropriate-alternative together.
    • Don’t forget you can do 1:1’s and other small meetings over videocalls too. I’d recommend building these confidential meetings into your rituals where possible, as it helps build trust. Also 1 to 1 video calls are actually pretty good.
    • If you’re coding, agree your coding standards together. Lots of collaborative software exists (Slack, Jira, Trello, Google, Github,…). I can’t advise what will be best for you: simply explore and see what works best for your needs.

    So those are my tips. As ever I’d suggest Inspect and Adapt! For example in retrospectives it might be helpful to add in an activity to talk about how you collaborate and any experiments you might like to try.

     

  • Deep dive: Planning

    In this post, we’ll discuss different ways of planning. When I talk about planning, I mean deciding what to do or what objective to achieve.

    As such, estimation and other timeline-related activities will be out of scope here ;-).

    When do we plan?

    In Waterfall, we start with a planning phase: deciding all the work to be done, up front. It looks a little something like this:

    waterfall
    Waterfall Planning

    In Scrum, we have iterations (sprints) which have a Sprint Planning meeting at the start of each. So our picture looks a little bit like this:

    scrum
    Scrum Planning

    In kanban, teams can do as they wish. Often this results in doing planning when it is needed (eg once all the “in progress” work is done) so it is more sporadic:

    kanban
    Kanban Planning

    Overall, the proportion of time spent on planning might be about the same: Agile evangelists would say that because of the pivoting this repeated planning allows, the value they deliver overall over the same time period will be much higher. (I agree with them!)

    One of the things I find interesting as thought experiments is applying these concepts to life. As a child, many of us have some dream of what we would like to do. As time progresses, perhaps this dream changes: in some sense perhaps this is a bit like a failed waterfall project… I hope though that we can instead see it as more like kanban planning: if you wanted to be married by the time you were 25, but didn’t meet the right person, it doesn’t feel fair to call that a “failure”.

    Who does Planning?

    In Waterfall, it is often a Project Manager, with the help of a few trusted Business Analysts. Perhaps the rest of the team have not even been assembled at this point.

    In Scrum, the Product Owner sets the direction (and if they are a “good” team the rest of the team will be very involved too). Often the developers are involved in estimation, and in a good team they will also be involved in creating some of the stories, with the Product Owner having an overall accountability for it.

    In Kanban, it can be anyone, though it is common to have someone fulfilling a kind of Product Owner role, to engage with stakeholders and understand what work will add value and be the best return on investment. Importantly, it is often those doing the work who will trigger the planning sessions (eg when they have no more work to do).

    Psychology of Planning

    It seems clear from Self-determination theory that those doing the work being involved in planning will lead to more intrinsically motivated workers, who actually want to work. This is particularly true in creative work. If you are interested, I would really encourage you to read up on Self-determination theory and see how you can apply it to your team to help them be more fired-up about their work.

     

     

  • Our language, our worldview

    Language shapes the way we view the world, as George Orwell points out in 1984 through the genius of Newspeak: part of the idea being that by replacing the word for “bad” with “ungood” for example, we limit our ability to conceptualise “bad”.

    Spicy?

    As you may have noticed by the (Chinese inspired) name of my company, I’m interested in language. One of my favourite mind-opening discoveries is that Mandarin Chinese has many different words for “spicy” including:

    • 辣: general word for “spicy”.
    • 干辣: literally “Dry spicy”
    • 香辣: literally “Fragrant spicy”
    • 麻辣: literally “Numbing spicy”

    Since this realisation, I have noticed much more the different types of “spicy”, and I find myself wanting to refer to different types of spiciness. As for many Chinese people, the blanket term of “spicy” often doesn’t do enough to describe the different tastes.

    spicy
    Numbing spice from Sichuan. This is for breakfast…

    Tense

    Tense (indicating past, present or future) is also not as well defined as I had imagined before learning Mandarin Chinese. In Chinese, Past and Present are the same. WHOA. There is a nice article from The Guardian on this topic.

    Chen’s argument is that the more you think of the future as a radically different thing, the easier it is not to worry about how too many cigarettes – or too little money – might cause problems in that future.

    Coming from the other angle, apparently Sicilian dialect has no future tense (interesting video source).

    Why is this useful?

    Language matters. Different words can have hugely different connotations to different people. We need to be really careful in Agile about our use of metaphor. Some I would argue are anti-agile:

    • Describing the company or organisation as a “machine”
    • Describing managers in a hierarchy as being “above” others

    By anti-agile, I mean in the sense that they don’t put individuals and interactions over processes and tools, and can be demotivating for creative workers.

     

  • Guy’s favourite Agile links

    I thought I’d share with you some of my favourite tools and resources I use as an agile coach. I find all these topics to be essential for being a coach.

    Retrospectives

    I love helping teams do retros, so they can reflect and improve the ways they work. But better is getting them to lead their own retros. To help, I often share my favourite retrospective idea sites:

    Scrum

    I try to use only the scrum guide here. Too often I hear people say things like “We must have User Stories because we are doing Scrum”, which is not only untrue by the definition of Scrum, but also may stop the team from doing something smarter (though I do like user stories in general, to ensure the team have a value focus).

    Kanban

    David Anderson’s “blue book Kanban” suggests a fairly rigid approach, which is worth considering and learning from. I would argue it runs counter to the philosophy of empowerment evangelised by the Agile movement.

    I like the “primary sources” for this, such as this from Toyota.

    Agile

    Clearly the Agile Manifesto is the source of truth on this.

    Lean

    I can’t help but recommend Mateusz Gajdzik’s simulator tool. Don Reinertsen’s book Principles of Product Development: Flow is also of interest here.

    Psychology

    I tend to use coursera to expand my horizons in Psychology (as well as in other areas such as gamification or mathematical techniques), as books get out of date very quickly. I very much enjoyed “foundational neuroscience for perception and action”, “social psychology” and “inspiring leadership through emotional intelligence”. These change all the time and many of the above are no longer available, so have a browse yourself.

    I also love the following videos (which I am sure to have mentioned before):

    • Dan Pink on motivation
    • Nudge (and I like many other RSA videos too)

    Management and Leadership

    The distinction between management and leadership is critical. For some “agile appropriate” tools, I like Jurgen Appelo’s work, particularly Management 3.0 #Workout.

    For leadership theory, I’d recommend reading some summaries to broaden your perspective, such as this.

    Coaching skills

    Lyssa Atkins’ book Coaching Agile Teams I found a helpful and well-thought-through guide. Overall though, I’d suggest that in coaching there is no substitute for practice. Inspect and adapt.

    I’d love to hear about your favourite resources, and any feedback or suggestions for better resources.

  • Thoughts on Quantum Computing and engaging people into science

    Recently, the Prime Minister of Canada Justin Trudeau amazed journalists by giving a short explanation of quantum computing. In the weeks after, many articles about quantum computing were written commending the president for explaining so eloquently this impenetrable new science. And while it is very exciting to have so many people engage with what is considered the next great frontier of computing, some of the explanations were rather disappointing, and because of the (perceived) complexity of quantum computing it is very easy to give the impression that it is even more magical and mysterious than it really is.

    The biggest misconception that propagated was that the miracle of quantum computing is down to the wave-particle duality of fundamental components such as the proton, neutron, electron etc. The key to quantum computing in fact relies on the superposition of states: taking for example a proton, this has a property (which we don’t need to go into but you can read all about) called spin, which when measured in a laboratory will always be “up” or “down”. The fact that a stream of protons can also act as a wave is not the most relevant fact here.

    So just quickly: what of the fact that spin is always measured as one of two states? It is that the only way of modelling mathematically the spin of a proton involves inherent randomness. It is possible to put the proton in an equal superposition of both up and down, with the binary result of an experiment only being resolved when actually measured, both up and down equally likely outcomes. Until then, the spin state is genuinely both up and down equally. But the very meaning of the word “quantum” implies the existence of distinct values and therefore no measurement can actually reveal the superposition we know is there. Rather,  in a sense, we force the universe into making a decision at the last possible moment!

    So Justin Trudeau and various journalists are right in saying that a bit is binary but a qubit (quantum bit) can hold multiple values at the same time, but it is not the wave-particle duality that underlies this phenomenon.

    Quantum computing is obviously far too complex a subject to go into further, but I strongly encourage you to do your own research. It is fantastic that this subject has been given more media attention, but any subject that captures your interest always deserves further research beyond journalistic simplifications. This post isn’t so much about quantum computing itself, but a reminder that initial engagement is just the first step!

    Written by William A. Lebreton.

  • More trees, please!

    A few weeks ago, I attended the Presidential Address at the Institute of Mathematics and it’s Applications (IMA). Using this, the IMA President Chris Linton argued the need for bridging the distinctions between “Pure” and “Applied” mathematics. Without giving too many spoilers, he also put the case that the “success path” for people at university is often seen as further academic study, eventually leading to professorship. Progressing into being a teacher, actuary, or any other job is culturally, perhaps, seen as a failure. In summary, I took Chris’ Address as a call for action: for changing the culture of success in mathematics to being more balanced across academic, industrial, educational, and other options. If you’re interested in mathematics, I would recommend going to one of the branch meetings where Chris will be repeating this talk.

    It is this same belief that led me to start full time working on Fuza a little over 3 months ago. You can see an example of maths applied to industry in this post. Indeed perhaps more broadly, I believe we should be using the science we already know:

    fields.jpg
    British greenery: Sunshine not often included (Letchworth Garden City)
    • It has been shown recently that 30 minutes of visits of green spaces reduces instances of depression and high blood pressure [source].
    • In another study, countryside walks were associated with reduced rumination (associated again with depression). [source]
    • There is a weight of science supporting the benefits of urban trees [source]

    To me, it seems logical and worthwhile that some city should conduct a practical experiment to see if we could reduce depression, perhaps by simply planting some trees. It seems sensible to conduct a small trial, in order to get some fast feedback. The alternative to a local trial is either to do nothing, or wait for a central government policy to implement it everywhere.

    In my town of Letchworth Garden City (UK), we are lucky to have a heritage foundation who do lots of good work, for example converting one of our 100-year-old houses into an eco-home [source]. Experiments do happen, but I would love to see more.

    morefields.jpg
    More countryside (Bristol – you can see the suspension bridge in the distance)

    As a society we are, according to me at least, not implementing enough of these experiments. I have written this blog in an attempt to inspire some of my local decision makers to try more things for the benefit of their fellow citizens.

    This is of course just one piece of science that I think it would be interesting to implement. Perhaps there are things you care about that we should be experimenting/implementing within our communities or businesses. I hope we can all do our bit to help get science used in reality. In the meantime, perhaps I will go out for a countryside walk.

     

  • Technical Debt

    According to wikipedia…

    Technical debt is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. I’d like to talk to you about something more physical instead:

    IMG_20160703_220615
    A Technical Debt Tree

    First, someone planted a hedge. Then the bushes grew into trees, weren’t good as a hedge any more, but they left anyway… and built a wall too. After some time, they wanted to keep sheep in, so added some barbed wire to stop them climbing over the wall. And now we have a (rather amusing looking) bodge: it would have been better to rip it all down and have a proper fence instead. I think you’ll agree that (whilst quite attractive with the greenery) it is a bit of a mess. Let’s translate this now into software development.

    How do you know if you have technical debt?

    Almost by definition:

    • New features are slow
    • Bug fixes are slow
    • Developers say the code is crap and messy
    • There is extensive documentation separate from the code itself
    • New starters take a long time getting up to speed

    What can I do about technical debt?

    Like other Agile Coaches, I’ve seen lots of ways teams can get better at this:

    • Realise as a team that there is a problem
    • Allow developers the time they want to get the code good, as part of each story
    • Add “technical debt” stories / work parcels
    • Write (and live by) coding standards
    • Write (and live by) definitions of done
    • Do code reviews
    • Consider trying pair programming

    There are lots of other things you can do too. I’d recommend avoiding a big rewrite and do improvement incrementally if you can, as this increases your feedback. Use your noggin: If you’re refactoring code, do the most-often-changed bits first. And if your stakeholders are hesitant to invest in this, measure your Lead Time and show them how it gets better on the parts of code you’ve improved.

    Any comments on this topic would be great! Do you have other ideas for removing technical debt?

  • Research in Agile

    This post is inspired by a question from one of our readers, Lukasz. I’m going to outline how I find and examine research on organisations, agile/lean, and culture. Hopefully this will inspire you to dig more into what stuff is true and what is just crap.

    Finding the genuine facts among the huge volume of opinion is hard. It’s hard in politics, it’s hard in management, and it’s hard in social science. As a mathematician, I come from a world things are either true or not, and I continue to find exploring ambiguous and opinion-rife research challenging.

    Finding an interesting topic

    First you need to know what you want to know. Inspiration for what to research can be found in case studies, papers, blogs, books, conversations, your own experience etc. I personally find my ways of thinking most easily challenged by experience, books, videos, and conferences (probably because these are accessible!).

    Finding the research

    Once you’ve something you want to know, and the vocabulary to describe it, I’d recommend googling with specific terms. For example, if you are interested in the impact of management on team members, I’d recommend something like: “role hierarchy team impact” or something similar. Stay away from buzzwords like “management” or “agile”.

    Google scholar is good for finding paper titles, but often due to publishers you will have to pay for them. Knowing the title, if you search again specifically for those papers/authors you can often find a free version on the author’s academic page, or at least some related content.

    Assessing research quality

    1. Be cynical. Assume everyone is lying and check their “facts”.
    2. Beware sweeping statements. It is hard to have good social science that is very general.
    3. Use your noggin. E.G. Is the sample size big enough? Have they got a control group?

    Beware research fashion

    Just because something is popular to talk about (or highly cited) doesn’t make it good. A good example is Myers Briggs Type Indicators. Yes it is popular, and arguably helpful to some, but that doesn’t make it true or “the way to classify people”. Similarly some leadership styles are more heavily researched than others. The weight of research can be tempting to give in to, but keep sifting through, especially when the research is about models to help understand a topic (rather than an absolute truth).

    Finally

    Once you’ve something you think looks solid, a good test is to try it yourself! Run an experiment relevant to your situation, and see if you get results in line with the theory. Then tell other people what you’ve learned. (Yes I’m ignoring confirmation bias etc.)

    If you have other techniques, or questions or suggested improvements to my ways of researching, please do share them in the comments!

     

  • Pretty maths

    Bear with this post as it goes through some equations at the beginning, but it is worth it. We’ll be doing some of the calculations to get this picture:

    Mandel_zoom_00_mandelbrot_set
    The Mandelbrot Set

    This is the set of numbers “c” such that {\displaystyle z_{n+1}=z_{n}^{2}+c} is bounded. These z are complex numbers, which we’ll ignore for now. It is much easier to understand if we look at some examples:

    Let’s say c = -1.

    We start with 

    This is repeating, and the numbers are bounded.

     

    Let’s now try c = 0.5.

    We start with 

    We can see that these numbers are getting bigger and bigger, and it is not bounded.

    One more: c=-1.9

    It bounces around a lot, never getting very big or very small, so it is bounded. It is kinda fun to sit with a calculator and try this.

    Mathematicians call this kind of system “chaos”, as it is very sensitive to the starting conditions. Sometimes this is called the butterfly effect. Note that chaotic is not the same as random: in chaotic systems if you know everything about the initial conditions you know what will happen, whereas in random systems even if you knew everything about the initial conditions you wouldn’t know what was going to happen.

    Benoit Mandelbrot was one of the first mathematicians to have access to a computer. Hopefully you can also see now why Benoit Mandelbrot needed a computer to work these out. He repeated this for lots of values of c. The pretty picture we started with is really a plot of the set of c (called the Mandelbrot set), where the colours indicate what happens to the sequence (eg how quickly it converges, if it does).

    Mandelbrot Set with Axes

     

    You can zoom into the colourised picture to see how complex this is here. Lots of people (me included) think it is pretty cool. It is really worth taking a look to appreciate the complexity.

    Other than being pretty, why does this matter?

    Stepping back: This picture is made from the formula {\displaystyle z_{n+1}=z_{n}^{2}+c}. This is so simple, and yet gives rise to infinite complexity. In the words of Jonathan Coulton,

    Infinite complexity can be defined by simple rules

    Benoit Mandelbrot went on to apply this to the behaviour of economic markets, among other things. Later people have applied this to fluid dynamics (video), medicine, engineering, and many other areas. Apparently there is even a Society for Chaos Theory in Psychology & Life Sciences..!

    Further reading

    This article is good for more explanation of the maths.

    Apologies to any Pure mathematicians for the simplifications in this article.