How do you apply the Scrum values or agile values in your work?

Agile Interview Questions Series:

How do you apply the Scrum values or agile values in your work?

A good topic to talk about in interviews is Scrum values or agile values. We can all learn the mechanics of a framework or a process but internalising the values and applying them to different contexts is a sign of mastery. 

If I was interviewing a candidate then I would be keen to see how they tackle situations from a values-perspective. There is rarely one correct ‘best practice’ option so evaluating options would show me a creative, flexible, values-based mindset; someone who could cope with the unknown and unpredictable.

If I was the candidate interviewing a potential employer then I would be keen to hear stories of how the organisational culture has embraced agile values and Scrum values and which ones the current structure and culture is finding difficult to support. It’s unlikely that the organisational culture is perfectly aligned to them so being aware of where there is conflict and how people are supported through that conflict would be important for me to learn.

As for how I would answer the question…it’s much easier to talk about Scrum values than agile values because Scrum is very explicit about what its values are whereas there isn’t really a definitive list of agile values as such. 

While there are many differing opinions as to what the core values of agile are, there is at least clarity about what the authors of the agile manifesto considered to be the core agile values so I will start there. 

Agile Values

The Manifesto for Agile Software Development states:

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

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

Personally I find this one the most natural and easy because I’m a people person. I’m not great at learning new tools and generally I find processes to be too stifling and I have an urge to break them or find reasons not to use them. Sorry 🙂

The essence of this value is that no matter how good your processes or tools are, it’s the people who get the work done and add the value and great people can trump even the crappiest process.

Working software over comprehensive documentation

As with processes I’m not a massive fan of huge documents. I don’t read the instruction manuals and I hate writing up what I’ve done. I find it increasingly valuable the older I get and the more complicated things get but, given the choice, I would rather have something that works than some documentation that tells me how it should work. Equally I would rather have an interaction with an individual to help me understand something than read a big document.

Customer collaboration over contract negotiation

Now in principle I love this one because I hate the idea of contracts. I hate the idea that we need contracts. In my naïve view of the world surely people can be trusted to do the right thing and work things out if things go wrong. Personally I’ve never been a big one for lengthy terms and conditions with my clients (though I do have them they are as minimal as I can get away with) but there have been a few times when I’m glad contracts have been in place.

One of my first forays into the world of agile focuses on how a customer and I found loopholes in the contract between our two parties in order to deliver something valuable instead of what had been contractually agreed. While this may come a little easier to me than most, this is still a big issue for many so I would say that, on the whole this is the hardest of the four agile values to put into practice.

Responding to change over following a plan

Again, for me this is not too challenging because I don’t tend to plan too heavily. When planning a vacation, I like the ability to react to the opportunities I discover when I am there rather than researching and planning out the itinerary completely. Sure I will think about what things I may need to book in advance and ensure some key sights get seen but I want enough room to inspect and adapt in the moment.

And while, in general, human beings prefer certainty over accuracy, I have seen a growing acceptance that responding to change is necessary and so organisational processes and culture has changed to tolerate and, in some cases, encourage that flexibility.

While each of these values can be a little difficult at times to put into practice, most people tend to find that they are relatively common sense in a complex environment such as software development. Sure we all like to close ourselves off and be on our own now again rather than interacting with others all the time and it’s very comforting every so often to just follow the plan and look for the documentation that gives us that feeling of certainty. But generally speaking they aren’t that challenging. The Scrum values, however, are potentially a little more stretching.

Scrum Values

Scrum as a framework has its own set of five values.

Openness

The heart of Scrum for me is that we should accept uncertainty, do the best we can then inspect and adapt based on feedback. Scrum is an empirical framework and empiricism only works if we have transparency. We can’t inspect what we can’t see. So openness is essential. Openness about what we are doing and why. Openness about what we are capable of and what our progress is. Openness with the feedback we give and receive. None of that is easy because it affects our delicate egos.

I was told many years ago that there is nowhere to hide in Scrum. If we suck at something then this will become very visible very quickly until we work out how to get better at it. This is great from a growth and development perspective but from a vulnerability and insecurity perspective it’s tough. It is not easy to realise (and know that everyone else realises) that we are not good at something so we can subconsciously avoid openness even if we know logically it’s a good thing.

Focus

I have yet to be at an organisation where they have not been doing too much stuff simultaneously. Focus seems to be a huge problem for our companies and for us as individuals. I’m no different. Despite preaching limiting our work in progress I always seem to have multiple things going on which keep me over-busy and at risk of burnout.

I can present the logical rationalisation and even an economic business case of “doing less stuff in order to get more stuff done” and everyone in the room will agree with me but when a new opportunity comes up or another fire breaks out, rarely do we stop something we are currently working on to focus on that instead.

Respect

I would probably say that this is easiest of the five Scrum values for me personally. One of my greatest strengths (and weaknesses in a way) is my ability to see multiple perspectives of the same issue; I can empathise with different people’s perspectives and challenges. I tend to see the possibility of a positive intention behind most acts and those where I can’t, I can see the cry for help that is driving it.

Sure, over the years I have been called a “tree-hugger”, a “hippie”, “naïve” and many other things but even if I didn’t find it easy to see a positive interpretation I would rather be someone who was wrong having thought the best of someone than be someone who was proven correct in thinking the worst of someone.

Commitment

This is a really interesting one for me. Scrum teams need to be committed to one another, the product, the organisation and their customers and users. Personally I’ve not been a member of a Scrum team for a long time. Outside of work, I have a very strong sense of commitment – to my family, to my friends, to my sporting affiliations. Yet from a work perspective I don’t stay working with teams or organisations for long. However I rationalise this as being my role to develop self-sufficiency; to help people, teams and organisations grow and then leave. If I were to be too committed then I wouldn’t be doing my job well; I would be creating a dependency. And I am committed to the servant-leadership aspect of my job.

Martin Lambert has a specific post on Commitment. Check it out.

Courage

Personally I think this is the most difficult of the Scrum values for the individuals, teams and organisations I have worked with over the years. Scrum is relatively simple but for it to work it requires large movements outside of people’s comfort zones. To begin with developers need to be more proactive and self-managing, product owners need to make decisions with incomplete information and Scrum Masters need to speak truth to power to create a new “way we do things around here”. 

There are many studies that prove how we would prefer to not stick our heads above the parapet and expose ourselves. We are full of insecurities and anxieties about taking courageous action – will people dislike us? Will we get sacked? Will I be judged incompetent? Yet change doesn’t happen without bravery.

People call me brave because they see things I have done in the past. They often assume I have no fear but bravery isn’t the absence of fear; it’s the willingness to act in the face of fear. And after a while you realise that a lot of the fears we have aren’t as big as we thought or even real. This realisation makes it easier to be courageous again and it becomes a virtuous cycle.

I absolutely get why people don’t feel courageous and I don’t judge them for it – it’s completely natural behaviour to not put ourselves at risk. I think the biggest service I can provide – to an individual, to a team or to an organisation – is to help them be more courageous.

Which of the agile values or Scrum values do you find most difficult?