Wednesday 1 July 2015

Agile Culture - is it a thing? is it important?

In the last few posts I've covered a variety of aspects of agile, how the artifacts and practices associated with agile don't make you agile, the underlying concepts in a good agile team, how agile methodologies are just tools and the benefits that you will hopefully see with a fully agile team/business.

A couple of times I've mentioned agile culture but not tried to actually define it in any meaningful way or described what it is and why it is important, so this post I'm tackling just that.

What is an organisations culture?

Before trying to define what an agile culture is its worthwhile defining what culture means in this context.

I looked around the internet and found a few different definitions about what culture is (such as here and here) and I believe you can generalise the various definitions and say that:

Culture is the combination of the values, beliefs, practices, etc that people in a company adhere to.

Some of these may be explicit e.g. a mission statement and others may be implied e.g. social norms in the company.

Whilst a company may have the same values and beliefs as another company, the implementation of those values, beliefs & social norms may well differ resulting in a different culture even though at their core they are based on the same things.

Agile Culture

Having defined what a culture is, and understanding that every companies culture is going to be different, what values, beliefs & practices could we reasonably expect to see within an agile culture?

Embracing agile principles and practices

Unsurprisingly an agile culture is one that embraces agile principles but not just within development teams but throughout all aspects of the business that are involved with project/products.

Not all agile practices are appropriate for people outside of the development team e.g. TDD, but practices such as sustainable pace, value stream mapping, limited work in progress, transparency, etc are suitable across the business so everybody can benefit from using them.

Focus on delivery

One of the tenets of agile is "stop starting and start finishing" it is about delivering and people in an agile culture do just that across the business in relation to whatever work they perform.

Value of a piece of work is understood

Agile talks a lot about value (I wrote a post about this a while back) and wanting to focus on delivering value for the business. In an agile culture this idea is understood across the organization which can make decisions about prioritisation and delivery easier since when people have to make a decision they do so with the common understanding of the value that they believe a piece of work will provide for the business.

Actively seeks feedback

How do people know if what they are delivering is the right thing? they seek feedback.

When it comes to feedback a development team is spoilt by all the different forms of feedback they have available to them - unit tests, continuous integration, product owner/champion, users, etc. For other parts of the business the form and type of feedback will depend on what is being delivered, and who it is delivered to, but that doesn't stop them seeking feedback be it from a person, team, department or company.

Learning

Many organisations want to promote a culture of learning due to the benefits that it brings, an agile culture has an advantage with the feedback mechanisms providing information about what is delivered and what may need improving.

The other advantage is that agile methodologies have built in practices such as "Inspect & Adapt" from Scrum or "Continuous Improvement" in Kanban which actively encourage teams to look at what they are doing to enable them to improve how they work.

Good companies don't just stop at looking to improve processes but also encourage individuals to learn, understanding that if people learn they bring that knowledge into the organization and the business ultimately benefits from that.

Do companies with an agile culture actually exist?

So is this an actual thing? When people hear this description they frequently comment that this "sounds great in theory, doesn't work in practice" or they say it seems like an agile nirvana or fantasy, and I understand that for a lot of people it seems that this way of working is a million miles away from how their own businesses work day-to-day.

Probably the most well known company that you could point to as appearing to works this way is Spotify (checkout these blog posts for more detail Part 1 and Part 2).

I have myself worked for companies that came very close to what I have described, they may not have implemented everything I've outlined but they focused on ensuring the team could build & deliver the software without putting any unnecessary roadblocks in the way.

Is this important?

I believe that working this way is very important, it helps companies understand that although the development team are the people producing the software they are only one part of a larger process which involves everybody upstream & downstream of the developers; companies need to understand that this larger process is what generates the companies income and the true cost of any project/product is related to everybody involved in the process, rather than just one part of it.

More explicit knowledge of how the various parts of an organisation interact helps to identify where any bottle necks exist slowing the delivery down, allowing a company to focus on the problem area rather than just presuming they know which part is causing the problem, often incorrectly.

Possibly the biggest advantage is having people in an organisation understand the larger process, it may not change the work that they do day-to-day but it can mean they understand their impact on other peoples work in the company, plus they are able to weigh decisions they need to make based on feedback received, perceived value and what needs to be delivered, rather than simply "doing what they are told to do" people hopefully become engaged, active participants rather than sheeple.

No comments:

Post a Comment