Following on from recent international experience, I will be speaking at Agile Manchester on “How to make multicultural agility work“.
The blurb: “People are different, and when you add country and culture into the mix, a complicated collaboration problem becomes even more complex. In order to lead an organisational change, you need to understand how different cultures behave and work. Whilst agile has many prescribed methodologies, such as scrum, things need to be tweaked: It’s not one size-fits-all.
In this session, I will share my recent experience of working with teams in Poland and Iceland, across retail, betting and shipping technology industries.”
Agile is an almost management-philosophical idea that is about getting better at delivering valuable working software. There are people calling themselves agile coaches who try and help do this. In this short article we’ll go through one aspect of the agile coach role, inspired by a recent experience. Thanks to those who were involved in this journey, you know who you are!
Agile Coaches aren’t Project Managers
A lot of “agile” is around motivational leadership techniques that you may be familiar with, for example Stephen Covey’s “The Seven Habits of Highly Effective People” or Dan Pink’s “Drive”. If you get a good agile coach, they will help your other leaders and managers to shape and grow a motivated and capable team. Because coaches operate without the rank of a people-manager, changes can be deep cultural changes (if we use the definition of culture to be “what happens when no-one is looking”). The general focus you might expect from an agile coach is one of delivering value quickly and incrementally, failing often and cheaply, learning quickly, working creatively, collaboratively and transparently. With an experienced and capable agile coach or scrum master, you would also expect the capability and delivery of your team to measurably improve – something you may not expect from a Project Manager. That’s all well and good, but there are things you expect of a Project Manager that no one seems to be doing…
You want a Project plan
There are two separate points here, the first about Projects and the second around plans.
A Project can perhaps be considered a resource bucket (time/cost/quality/scope) which work takes place within. The “agile” way of thinking involves considering not fixed time Projects, but rather continually living Products. Instead of having the wrong thing delivered late and over budget, instead agile relies on the ability to have transparency and change direction quickly, resulting in less wasted time, money and effort. Despite what some evangelists may say, I’d argue there is no inherent problem with constructing things as projects, though it may be slightly misleading in that it can create an expectation that the product development will be “done”. There is often new work to do to make the customer happy and to remain competitive, and it’s fine to spin those up as new Projects or as new Product Epics. The language matters, but perhaps is not as important as the underlying sentiment of iteratively satisfying or delighting the customer. If the format of Projects works better for your business, keep with it, though please do try to make the projects small.
When thinking about plans, I find it helpful to think about what we are trying to achieve through having a plan. Often the thing executives want from a plan is transparency and dependability. As people-centric agile practitioners, we want to help provide what you (and the business) need. There are a few well established techniques for achieving this that are part of the standard agile toolkit, for example using story points, and articulating outcomes through a Product Roadmap. Arguably the smartest planning techniques rely on lean (from Toyota Production System), and more recently Monte Carlo simulations. It takes a while to implement lean forecasting, since the usefulness of any of these measures relies on having a reasonable amount of historical data to work with. For this data to be meaningful, it needs to be the same team, similar work, etc. As a rule of thumb, I’d say 3 months is possible, provided the team are stable and get good at breaking things down small (which gives even more data points). The required time depends on how variable the team’s work is, and additionally requires someone like a coach, scrum master or project manager to help support the team, Product Owner, and/or Business Analyst breaking down of work into small chunks. For a plan, we also need to know and articulate what we want to do and why, even if it is just a best guess. In my experience, it is helpful to have one person deciding what-to-do-in-what-order, and they are likely to naturally lead the planning efforts with the support of a Scrum Master or Agile Coach.
From any of these we can get a visual way to show historical and expected progress, with an understanding that we encourage change if it helps deliver more value. “Plans are useless but planning is indispensable” and “No battle was ever won according to plan, but no battle was ever one without one” come to mind. A final message to the executive reading: If you are open to trying new ideas of what plans look like, that is great!
Why doesn’t this article mention “sprints” or “velocity”?
Sprints (the idea of delivering a fixed scope over a short time) is a metaphor taken from Scrum, a very popular agile framework. Scrum is one of many agile frameworks, and an agile coach is often not constrained by approach, technique or framework. As such, nor is this article.
Velocity is another idea often implemented in Scrum environments, which is “Average Story Points completed per Sprint”. Often this is used for planning, though for some technical reasons I personally prefer not to use this in most cases. I recommend lean and customer-focused metrics for performance self-assessment and future planning.
The Agile Manifesto was created for software development, but there are many lessons we can use outside of IT. This is not to say I think we should “be Agile” in everything.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Individuals and interactions over processes and tools
Careers such as counselling and caring are starting to do this more. There is more of a focus on patient-centred leadership. In Nordic countries, there is a great company with 19,000 employees called Attendo, which focuses on empowering the individual in order that:
Every individual feels participatory and listened to.
Every individual feels they are met with respect and warmth.
Every individual feels supported in achieving independence.
Every individual feels safe and secure.
Every individual perceives that their quality of life is positively affected.
This one is only literally applicable to software, but the focus on value delivery is relevant as part of Lean Startup, for example. This is a way of running startups to help them be successful and less wasteful. Also notably, the value focus of agile can be seen in manufacturing (eg lean, kanban).
Customer collaboration over contract negotiation
Again Lean Startup advocates this. Big companies are trying to do this more too. For example, Diagio (the drinks company) have a “Customer Collaboration Centre” where they involve customers in their strategies.
Responding to change over following a plan
This area is one where I feel there is a lot of benefit. The world still works on a plan-based mechanism. We vote our governments in for fixed lengths of time, we demand financial plans, and we expect deadlines to be delivered to. Psychologically, embracing change can be hard. According to this random website I found, there are benefits of responding to change:
Staying current
New opportunities
Encouraging Innovation
Increased efficiency
Improved attitudes
The reality is that everything that survives must respond to changing environment. (Human) evolution is a great example of this. Medicine has always been “inspect and adapt”. Even the most conservative of organisations, the Vatican, responds to change, as demonstrated by their use of new latin translations during Mass. McCain Food, as one of innumerate corporate examples, responded to changing customer (and legislative) demands for healthier food by using sunflower oil, rather than vegetable oil. Creating a culture where we respond to change over following a plan will lead to better outcomes in almost any space.
If you can think of something where following a plan makes more sense than responding to change, or any other good counterexamples, please let me know in the comments below.
The average number of customers in a queuing system = ( the rate at which customers enter the system ) x (the average time spent in the system)
Typically this might be applied to things like shoppers in a supermarket, but here we will focus on the application to software development. In a software development world, we often write it the same statement with different words, thinking about tasks:
Average Work in Progress = Average Throughput x Average Leadtime
Little’s law is beautifully general. It is “not influenced by the arrival process distribution, the service distribution, the service order, or practically anything else”[1]. This almost makes it self-evident, and since it is a mathematical theorem perhaps this is correct, since it is true in and of itself. Despite being so simple to describe, the simplest generalised proof that I have been able to find (and which we will not tackle here) is however trickier, since a solid grasp on limits and infinitesimals is required. Instead, we will consider a restricted case, suitable for most practical and management purposes, which is the same equation, with the condition that every task starts and finishes within the same finite time window. The mathematical way of saying this is that the system is empty at time t = 0 and time t = T, where 0<T<∞. A diagram to show this system might look something like this:
Tasks all starting and finishing between t=0 and t=T
Proof
For our proof, we start with some definitions
n(t) = the number of items in the system at time t
N = the number of items that arrive between t = 0 and t = T
λ = the average arrival rate of items between t = 0 and t = T. The arrival rate is equal to the departure rate (sometimes called throughput), since the system is empty at the beginning and the end.
L = the average number of items in the system between t = 0 and t = T. This is sometimes called “average Work in Progress (WIP)”
W = the average time items spend in the system between t = 0 and t = T. This is called W as a shorthand for wait time, but in software development we might call this leadtime
A = area under n(t) between t = 0 and t =T. This is the sum of all the time every item has spent queuing.
Using this notation, Little’s law becomes
L = λ x W
which we will prove now. The following equations can be assembled from these definitions. We will need to use these to assemble Little’s Law.
L = A/T(average number of items in the system = sum of time spent / total time)
λ = N/T(average arrival rate = total number of items / total time, since every item leaves before t=T)
W = A/N(average time in system = sum of all time spent / number of items)
We can now use these three equations to prove Little’s Law:
L = A/Tfrom (1)
= (A/T)x(N/N) since N/N = 1
= (N/T)x(A/N)by rearranging fractions
= λ x Wfrom (2) and (3)
This is what we wanted, so the proof is complete.
What does this mean?
A trick to getting good outcomes from Little’s Law is understanding which system we want to understand.
If we consider our queuing system to be our software development team, our system is requirements coming in, then being worked on and finished. In this case, W is the development time, and each item is a feature or bug fix, say.
To have a quicker time to market, and to be able to respond to change more quickly, we would love for our so-called “cycle time” W to be lower. If the number of new features coming into our system is the same, then we can achieve that by lowering L, the average work in progress. This is part of why Kanban advocates “limiting work in progress”.
Alternatively, we can consider our queuing system to be the whole software requirement generation, delivery, testing and deployment cycle. In this case, we might have W being the time taken between a customer needing a software feature to it being used by them. By measuring this, we get a true picture of time to market (our new W, which is true measure of “lead time”), and we with some additional measurements we would be able to discover the true cost of the time spent delivering the feature (since our new A is means total time invested).
Outside of the development side of software, we can apply Little’s Law to support tickets. We can, for example, state how long a customer will on average have to wait for their query to be closed, by looking at the arrival rate of tickets and the number of items in the system. If there are on average 10 items in the queue and items arrive at 5 per hour, the average wait time will be 2 hours, since the rearrangement of Little’s Law to L/λ= W gives us 10 / 5 = 2.
I hope that was interesting, if you would like me to explain the proof in the general case, let me know in the comments. I think it would be about 10 pages for me to explain, so in the spirit of lean I will only do this if there is a demand for it.
Definition: “a formal meeting of people with a shared interest, typically one that takes place over several days.”
Agile On The Beach Conference (2013)
The features:
Topics shape the audience
Rigid program
You know what you are getting
Often high profile expert speakers
Accessible for old-school thinkers
Can be expensive for participants
Unconferences
Definition: “A loosely structured conference emphasizing the informal exchange of information and ideas between participants, rather than following a conventionally structured programme of events.”
Manchester BarCamp 7 (2016)
The features:
Audience shape the topics
Flexible (unknown) program
Lean
Not so much preparation for speakers
Law of two feet: If a session is not useful to someone they will leave, which is less wasteful
Variable quality speakers
Everyone participates, which is more effective for learning
Often cheap/free for participants
Which is more agile?
I will now attempt to show that agile conferences are a paradox. I know it may seem odd applying agile (for software development) to something like a group of people communicating, but let’s give it a go. Perhaps we can compare some traits of Conferences and Unconferences to the Agile Manifesto:
Individuals and interactions over processes and tools
Unconference is more agile, since unconferences are attendee-led
Working software over comprehensive documentation
Arguably both styles similar with an Unconference perhaps slightly better, since conferences often document lots in their preparation
Customer collaboration over contract negotiation
Unconference is certainly better here, since unconferences are attendee-led (and the law-of-two feet means that “customers” don’t get what they don’t want)
Responding to change over following a plan
Unconference is massively better here
I put it to you that as agile evangelists, we shouldn’t be encouraging traditional conferences, which are prescriptive, irresponsive, contractual and process-driven.
Instead, we should support unconferences, perhaps by organising, participating or sponsoring them.
I tried a Pilates video a few weeks ago. I know that might not be very manly, but I thought I would try something different to shake things up. I hoped it would be a bit like yoga, and help with my core strength.
It had an unexpected benefit… I discovered Lateral Breathing. This involves breathing deeply and engaging core muscles, in order to maximise oxygen exchange. I’d strongly recommend it, it feels great! There are apparently lots of benefits, and the main one I’ve noticed is to do with running. And it isn’t just in the way it feels (since I track everything I have data):
Over the same course…
My heart-rate is very similar…
In exchange for a 1% higher cadence…
And 30secs/mile faster speed.
This is much more than the improvement I usually see in a similar 2 weeks of training.
You might be wondering why I’m talking about this. Well, it feels like innovation. You might’ve read last week’s post about Active Procrastination: you never know what might help you approach a problem in a different way.
Innovation often occurs at the crossings between two disciplines. Some varied examples:
Descartes’ Meditations is between mathematics and theology.
Gaudi’s architecture is between engineering and biology.
I think this is one of the first times I’ve created something new in a psychology context. Let me first outline the problem. I struggle to relax and unwind, but sometimes (even/especially during the workday) I need to do something different to get away from stuff. I guess you’d call this procrastination. Often I would go for a walk or do some exercise, and my friends were saying why don’t you just watch TV / read the internet / play flash games. But I couldn’t. If I did, I just felt guilty and certainly didn’t get pleasure or relaxation from it.
Not all procrastination behaviors either are harmful or lead to negative consequences.
I wanted to be able to procrastinate, not least because of this cool research that can be seen in this wonderful article. Basically, people who were told a problem, then played minesweeper, then attempted to answer a creative problem, came out with many more answers. As mentioned in the article, this may not be strictly speaking procrastination, but what I can do is replicate this creativity study environment at home for myself in the hope of enjoying their reported 28% increased creativity.
Cue the world debut of the Active Procrastination Board:
Each card has something different on it, a little like Brian Eno’s Oblique Strategies. Unlike oblique strategies, they are all activities designed to:
Take me away from what I am doing
Take varying lengths of time (so I can choose what I need)
Be things I would like to do
Be playful
Be a large range of different types of thing
Be mostly “wholesome” activities
Not be too intellectually or physically taxing
When I first used this, I started having it with dice to pick the card, one for the row-number and one for the column-number. However, I found I wanted to use the board more if I picked one I wanted to do at that time instead. For example, “heading to the library to read a random book” in the rain is annoying and takes ages, but in dry weather is fine.
Please let me know your thoughts, and if you try creating your own I’d love to hear about it!
The term “retrospective” is prevalent for any of the Continual Improvement meetings, largely due to the popularity of Scrum. However, this post really refers to any meeting where a change to process is made. Whatever you might call this, it is very important, as I hope I will show in this post.
Why should the team do a Retrospective?
It allows them to talk about their feelings in a safe space (Social Connection/Relatedness)
It allows them to make small changes to their processes, to try to make their delivery better (Mastery/Competence)
It allows them to feel in control (Autonomy)
It allows them to step back and see what they’ve achieved (Purpose/Competence)
So a Retrospective gives a lot of the things that Self-Determination Theory holds are important for motivation (highlighted in bold in the list above). If you aren’t doing retrospectives in some form, then you are perhaps missing out on a chance to motivate and inspire the team, as well as not helping them to deliver more.
Who should run it?
There are a few options here:
An external (to the team) facilitator. This has the advantage of allowing each team member to equally participate. The disadvantage is that the team members may feel that the meeting is happening to them, rather than for them. And of course someone needs to arrange the facilitator.
A scrum master or similar. Advantages include that they are probably good at facilitating, and know how to help the team work well together, and that it is their role so they will make sure the meeting is organised. The main disadvantage is that it can dis-empower the team (as above).
A team member. This has the advantage of making team members feel engaged with the process (especially if they each take a turn). It has the disadvantage of needing meta-coordination, and can lead to variable quality.
A manager. I think this is a bad idea as it reinforces the hierarchical ideas, unless the manager is a very effective Servant-Leader and able to keep her/his opinions to a minimum!
Who should be there?
Everyone interested in the team performing well. So definitely the team including Product Owner (or equivalent), and anyone else who might having valuable insights to share.
What should the outcome be?
The outcome of a Retrospective should be a very small number of SMART actions. A small number since the team can be considered a Complex Adaptive System, and as such according to Cynefin (and common sense) should be conducting small experiments rather than many large changes. By SMART, I mean Specific, Measurable, Achievable, Relevant, and Time-based. Sometimes these actions will be about how the team work together, other times they might be about improving the working environment, software, tools, or interactions with others. Whatever is important to the team at the time.
It is also very important that a Retrospective is FUN! The desired outcome here is that the team want to do it again.
What should happen in a Retrospective?
I’d describe a good Retrospective as Serious play. By that I mean playful but about something serious, with serious outcomes. Tools like retromat give great ideas for how to construct these kind of playful sessions. In particular, using colourful postit-notes, images, memes and other creative tools can make the session feel more fun. For me the important parts are:
Set the scene and let people check in. It is important here to get the energy levels up and frame this positively.
Write down separately comments about the last Time Period in some form
Allow people to speak about them
Agree on important core issue
Get the team to come up with and commit to a SMART solution or experiment
Get feedback on the retrospective itself
I think it is important to allow people to separately write things down because it allows the less vocal in the team to say what they feel without interruption by the more extrovert. It also keeps the discussion wide initially, before narrowing. This intentionally mirrors the Explore-Exploit of “the bandit problem” which is often applied to innovation theory. Essentially with Retrospectives we are helping the team to innovate themselves.
How often should we do Retrospectives?
Scrum says once a Sprint, where a Sprint is usually between one and three weeks. However, the team should decide the frequency. More frequent Retrospectives give fast feedback, and shorter feedback loops, so if you are very “agile” then it is likely you will be doing this very regularly. I’ve worked in teams that have a Retrospective each week, and others that have a Retrospective only once month.And of course they can change the frequency whenever they need, through the Retrospective itself. It really depends on what the team wants (more often is better as it gives faster learning).
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.
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.
FUZA 