When we talk 'agile' there are a few big issues that I notice, especially from management and the executive within financial institutions. These are preconceptions, thoughts of what agile is, what agile means based on previous IT project type experiences
or from what they have picked up listening to podcasts, reading articles like this or what they have heard on the floor. However, the biggest issues are often subconscious mindsets and values, both of which can seriously damage even a successful agile engineering
environment.
It’s all about 'culture'
The first thing here is that agile is very much a cultural thing. In banking we talk a lot about culture, but often, that culture point, the culture we hope to cultivate is not about how we work effectively, or how we work best as a team moving towards a
common goal, rather it is about how our culture ensures good conduct. Now, there is nothing wrong with ensuring you have a culture that addresses and promotes good conduct, but simply focussing on this area does not mean you have a productive culture. Agile
is as much about culture as it is about delivery.
In order to implement agile successfully you have to have a culture that everyone buys into. I have always said, if you want a great engineering department then you need to define your culture, understand culture, share it with each other and believe 100%
in it, because if we all do that then not only can we preserve it, but we can also constantly improve it. If you have a great culture then you will find that your implementation of agile is highly effective and you will reap the rewards in terms of productivity,
flexibility and speed to market.
The issue with culture though is preserving it, especially if you are in an industry that is used to working in very specific ways, or, if you are experiencing rapid growth/expansion or a high turnover of people/contractors. People bring with them their
experiences, all highly valid, but also that means their pre-conceptions and ways of working. This can be highly dangerous to your engineering culture, making selecting the right candidates to join you unbelievably important and equally important, that “induction”
process being in-depth enough, and that they really stress the culture you have, the culture you are building. As I said earlier, everyone needs to understand your culture, share in it and believe in it for it to really be successful.
Underlying mindset and values
Typically, the way you work, especially at that 'departmental' and even organisational level, is brought about by a certain mindset and set of values. The executive typically set or frame this, either consciously or sub-consciously (which one depends on
their experiences). As a CIO/COO/CTO you have to become aware of underlying values and mindsets and ensure you have the right ones. The wrong ones, once they filter down can be highly damaging to your agile environment, and that is because these values drive
culture.
For me, there are 3 underlying mindsets that are very common, very dangerous and need to be changed.
The first is that 'people work in a department', a departmental mindset often leads to work being carried out and then passed on to another department for them to pick up and take forward. When you think of many BPM (Business Process Management)
tools, many of them even promote that kind of process thinking. This is something you really don’t want to find anywhere in your engineering culture, you want the complete opposite. If you have read the previous article within this series, you will understand
the importance of 'cohesion', making sure you have everything in that one component, in that one team, no departments or division of efforts. Unfortunately, many organisations have 'agile' development teams which are dependent on 'departments' for specific
knowledge. This departmental thinking typically leads to the department building specifications to hand over to engineering, this is not what you want ever.
The second is that often, we as the executive believe our 'teams can predict' how something is going to be built and how long it will take. I use the word 'believe' because that is essentially what is often asked for, the question goes 'a rough
estimate, when will that be ready?'. By asking this, you are essentially saying I believe you know what we are building, how we are building it and how long it will take. Unfortunately, as with any complex problem/scenario, you don’t have all the answers up
front, rather you have to learn as you go. The problem with predictability is that it leads to thinking in a 'project' type fashion, as in we start something, we build it, it ships we walk away. Again, if you have read the previous article in this series you
will understand that project mentality is not a productive one, rather we need to be thinking of product, and products get delivered, evolve and improve.
The third, and often one I see even in organisations that use agile well, is that
'we prescribe to a specific agile practice', right across all engineering efforts. For example, every engineering team must follow SCRUM and stick to the practices within SCRUM. Now, that is buying into specific
agile practices and not principles, ideally you want to acknowledge that team A, may perform better if it followed a different agile practice than say team B.
Set core values
I believe the foundation of agile and the success of your use of agile lay with setting core values. If you are able to boil these down to something very short, very easy and something that everyone buys into, then you are starting to be able to set that
good cultural environment.
Here are a two core values I almost always set:
- 'Value Delivery over Predictability'
- 'Value Principles more than Practices
Delivery over Predictability
I think this core value gets at the heart of agile. Essentially if we value delivery of product above all else, then we will work in a way that promotes understanding, learning, transparency and bringing product to market. This directly impacts our mindset
around understanding exactly what we are building. This one core value alone removes bad habits such as producing project plans and believing teams can predict the future.
Value Principles more than Practices
This core value kills the concept of a department, rather shared principles bring people together within a team. At the same time, this principle acknowledges that people are individuals, that what works well for one team doesn’t necessary work well for
another, so it gives them the freedom to implement the agile practices that best suit them. This core value has a real impact on productivity and team morale.
Summary
Setting core values and principles helps address those forces that can negatively impact a good agile engineering culture. Your values serve as the foundations on which your agile efforts will be based upon, shaping not only engineering efforts, but ideally
the mindset of management and the executive. If you can get buy in to these values, if everyone believes in them then you really will be creating the right environment in which a productive culture can grow.
In the next article within this agile series, I will take a look at applying your values and principles.